"Victor Mote" <[EMAIL PROTECTED]> wrote on 24.05.2004 18:12:36:
> One of the changes that will probably need to be made to FOP's font handling > is to parse AFM files instead of PFMs. I have assumed that for hardware > fonts, either the device manufacturer provides font metrics files or enough > information so that they can be built. Adobe, for example, provides metrics > for the base-35 PostScript device fonts here: > ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles/base35/ This is what did in my formatter. I have implemented an AFM reader (though I ignore the kerning infos so far) and use this to read the Adobe base fonts - for example. > So my *plan* has been that these fonts get treated pretty much like any > other font. The only thing about the hardware font is that it can't be > embedded -- it is already embedded all of the places that it can be. Depends. Every PDF compliant reader/printer has to support Adobe's standard Helvetica, Times Roman, Courier, Symbol and Zapf Dingbats fonts (metrics-compatible alternatives at least). So it makes sense for a PDF renderer to supply these fonts metrics to a formatter to say "hey, I can render these". > Are you suggesting that FOP / FOray needs to actually query the hardware > device and extract metrics information directly from it? Or is the plan I > have outlined above sufficient? Well, it really depends how far you want to go. Device fonts have certainly seen days of higher importance... But still, from time to time you stumble upon people who need (or want) to use fonts that they have no exact software equivalent for. Whether this means accessing the device directly or indirectly using a printer driver or by means of supplying metric files is a side issue, I think. Let's just say a renderer should be able to supply fonts (metric-only or complete) to the formatter. To give you an extreme example: In the high-volume output market, the format of choice is still AFP by IBM. This is (but today's standards) a rather obscure format that has ancient origins in the GKS system and is very similar to the metafile format in OS/2. Concerning fonts, however, you mostly use bitmap fonts in the AFP world. Imagine a renderer that has to support an output format that only allows (and supplies) bitmap fonts. Sure, it's debatable whether one want to support this kind of thing - at least by design. But, in any case, I think it highlights the extremes that can happen in the font handling world. Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH