"Victor Mote" <[EMAIL PROTECTED]> wrote on 25.05.2004 01:46:50:
> 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.
Yes, but the base-14 fonts for example are not defined for AWT renderers, since
*only* their metrics is publicly available. Still, in the case of the
base 14-fonts you can really argue that you want to extend the PDF model of
(these fonts are always there). Just note that on many systems you are out
of luck with - for example - the Zapf Dingbats fonts.
> 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.
In the case of an AFP renderer your model would suggest to the formatter
that the 4 faces of Helvetica, Times Roman and Courier are available which
they are not. At least, you would have to supply additional information
so that the formatter could decide which of the standard fonts is available
to which renderer.
> 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?
You would gain simplicity in another respect - you would exactly know
which font (and not only which *type* of font is available to which
renderer or device (in the latter case, think about output to different
printers from the same installation, which could have a differing set of
device fonts).
Arnd
--
Arnd Beißner
Cappelino Informationstechnologie GmbH
