Arnd Beißner wrote: > To all of that I entirely agree, but might want to add one > thing: a renderer should have a way to supply a font to the > formatter's font repository. > This > is needed when, for example, a print renderer can query and > use builtin printer fonts. The way to query and get these > (even if it's only a metrics-only > font) should be in the renderer, though. Sometimes, this is > an essential feature, for example for special OCR/OMR fonts > stored in printers for which you may not have a "screen" font.
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/ 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. 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? Victor Mote
