On Wed, Nov 26, 2003 at 08:21:33PM +1000, Peter B. West wrote:
> Simon Pepping wrote:
> >I have taken a look at the way this question is dealt with in LaTeX
> >(TeX does not have the notion of font families, LaTeX does). Here the
> >question what to use for small caps font is deferred to the font
> >setup. The font definition tables must define a small caps font. If
> >they do not do so, a fallback font is used; this should also be
> >defined in the fd tables. If they fail to do that as well, the system
> >uses its fallback font.
> >Like FOP's layout, LaTeX only uses the font metrics. The renderer
> >should locate the actual font. If such a font does not exist, but must
> >be emulated, then this should indicated in the font system
> >configuration for the renderers. For example, the fonts map for dvips
> >has these lines, which I believe tell it how to generate a small caps
> >pplr8rn Palatino-Roman ".82 ExtendFont TeXBase1Encoding ReEncodeFont"
> Correct me if I'm wrong here, but doesn't TeX have a full font system of
> it's own? Doesn't TeX guarantee to produce .dvi (device independent, I
> think) files? I assume it does this based on its own fonts and any
> METAFONT data. The matching of this .dvi to actual output is then the
> job of a dvi->? renderer. That is, there is a translation step between
> the dvi and the native input of the renderer, e.g. PDF, PS, H-P printer
> or X11.
TeX comes indeed with a font system of its own. Later type1 fonts have
been made accessible to TeX, in addition to its own bitmapped
fonts. But one can logically separate the layout system (the TeX
program) and the font system.
The procedure you describe above is correct. The dvi file is sort of
equivalent to the area tree: It has all layout and font information in
a format that can be used by renderers to generate output.
What I tried to say is that the layout program is only satisfied if it
finds the metric data of the font that the user requests. It does not
do anything smart about missing fonts. It is the responsibility of the
font system to do the smart things: provide the font requested, or
provide a replacement font for it, or provide a general fallback for
missing fonts. And it does so based on the information in its font
configuration files. These do the translation from a
font-family/shape/weight/size combination to an actual font file
This is also the place to specify if a small caps font exists or
should be mimicked by using a smaller font. That would be a major
trick, as Chris already noted. The notion of a virtual font might help
here. That is a font that consists of pointers to glyphs in other
fonts. It has its own metric file, so that the layout system does not
note any anomaly.
Typographically minded users like to buy lots of fonts and add them to
the system. The system is informed about this, and about its
shortcomings and the replacement fonts, by additional font
configuration files. In addition, one can instruct renderers to
generate glyphs by certain manipulations on the glyphs of existing
fonts, such as slanting, extending.
But perhaps I assume too easily that ideas from TeX can be copied to
> >So my basic belief is that FOP should not know anything about
> >this. It should all be configured in the font system. That is how the
> >user imposes his choice of fonts.
> If a user renders a given .fo file on two different systems, using the
> same renderer (say, PDF), and specifies a font family (say, Baskerville)
> that does not exist on the first system, but does on the second, what
> result should be expected?
Traditionally that depends on the renderer. Some produce a fallback
font family, e.g. PostScript viewers may use Courier. Others just
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl