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 > >font: > >pplr8rn Palatino-Roman ".82 ExtendFont TeXBase1Encoding ReEncodeFont" > ><8r.enc > > 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 name. 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 FOP. > >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 fail. Regards, Simon Pepping -- Simon Pepping email: [EMAIL PROTECTED] home page: http://www.leverkruid.nl
