[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] HTML fonts
From: |
Werner LEMBERG |
Subject: |
Re: [Groff] HTML fonts |
Date: |
Sun, 23 Jan 2000 22:56:19 GMT |
> > IMHO, HTML shouldn't use fonts at all. It should use entities only,
> > interspersed with markups. All glyphs available in `S' should *only*
> > be accessed via groff names and not directly with the char code --
> > otherwise it would fail on other output devices anyway.
>
> hopefully this is what is happening when eqn is run ie:
>
> ...
>
> eqn -Thtml eqn2.n | troff -Thtml -ms
>
> generates:
>
> ...
> Csr
> Cradicalex
>
> ^^^^^^^^^^
You can access both characters with troff directly: \[radicalex] and
\(sr, so eqn does the right thing. Of course, radicalex is defined
for devps only (-Tdvi doesn't need this character at all).
It might be a good idea to collect all available glyph names defined
for all devices in a single list for reference, specifying also
whether a given device can emulate it (e.g. radicalex).
> > As a consequence, `fonts' in devhtml should look similar to the
> > font descriptions in devutf8, i.e., all available entities should
> > be collected in a single R.proto file.
>
> I think this is very elegant. Will it still cope with equations
> and the special character set?
Why should it? I suggest that everything not representable with HTML
entities or macros will be handled by grops.
> > It makes no sense to mimic PS behavior for HTML output, I believe.
>
> I like the sound of this - but I'm slightly apprehensive about what
> will happen to png images.
I have a heretic solution to the image problem: My idea is to run
groff twice.
The first time, groff is called with -Thtml. An additional request in
the DESC file should cause groff to send the whole input file
literally to grohtml; this data is saved temporally.
The second time, the literally saved data is sent again to groff, but
this time with -Tps. grohtml can additionally modify/mark the data as
needed.
I see two advantages:
.) A clear separation between HTML and other devices, especially
fonts. I can e.g. imagine that a yet-to-be-written gropdf is used
instead of grops for various data on a HTML page.
.) Some higher-level information in the source code could be directly
analyzed by grohtml which would be lost otherwise. This will
improve HTML code.
> x X html:graphic-start
> some picture
> x X html:graphic-end
>
> to generate the picture it generates a troff output file which is
> given to grops. It does this by scaling the html glyph positions up
> by the postscript resolution/html resolution and faking a troff -Tps
> generated equation. I hear people stomachs turning as I write this
> :-). If roman chars/courier chars are given the same width there
> might be a mess :-)
I must admit that I also have a bad feeling...
> It could be I'm missing something here and you've got hold of a
> elegant solution which means we can delete lines of code and remove
> duplicated dev files. I like removing code... especially if the
> solution is better...
Well, my suggested solution above is probably simpler (at least
cleaner) but more time-consuming.
Werner
- [Groff] HTML fonts, Werner LEMBERG, 2000/01/22
- Re: [Groff] HTML fonts, Gaius Mulley, 2000/01/22
- Re: [Groff] HTML fonts, Werner LEMBERG, 2000/01/23
- Re: [Groff] HTML fonts, Gaius Mulley, 2000/01/23
- Re: [Groff] HTML fonts,
Werner LEMBERG <=
- Re: [Groff] new grohtml was (HTML fonts), Gaius Mulley, 2000/01/24
- Re: [Groff] new grohtml was (HTML fonts), Werner LEMBERG, 2000/01/24
- Re: [Groff] new grohtml was (HTML fonts), Gaius Mulley, 2000/01/25
- Re: [Groff] new grohtml was (HTML fonts), Werner LEMBERG, 2000/01/25
- Re: [Groff] HTML fonts, Gaius Mulley, 2000/01/23