Arnd Beißner wrote: > > 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".
However, since these same fonts could also be used by the PostScript renderer, or the Print or AWT renderers (assuming that the pfb is available as well), I don't see a need to duplicate their definitions, or metrics, or anything for each one of these environments, which is what it sounds like you might be suggesting. It should be sufficient for the Renderer (or RenderContext) to tell what it is *capable* of doing, without having to provide the actual detail. In the case of the Base-14 font metrics, we can and should and do embed them within FOP itself. If you don't mind the metrics themselves living somewhere else, and the PDF Renderer simply saying "I can render Base-14 fonts", then we are in agreement. > > 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. Why is this better than simply supplying the same font metrics at a global level, and letting the Renderer or RenderContext tell what it is/is not capable of processing? What would one get in return for giving up that simplicity? > 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. After you have a generic font definition scheme, like an AFM parser or FOP's metrics files, I think you can support any font, bitmap or otherwise. If the hardware vendors can't provide the metrics, then someone would have to sit down and either query the device or infer the metrics from output, or some other method to get it into the standard form expected. It might be worthwhile to add something in the font configuration that would identify the point size, so that at least a warning could be generated if someone tried to use, say, an 11-pt file at 9 points. Victor Mote
