Arnd Beißner wrote:
<Arnd>
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.
</Arnd>
<Victor>
I don’t work with the AWT renderer, but it *should* be able to use the
base-14 fonts, assuming that the user has installed the font (not just the
metrics) on their system. It is true that only the metrics for base-14 fonts
are *freely* available, but the outlines *can* be licensed. In fact, I am
pretty sure they are all included in Adobe's Type1 version of its Type
Basics:
http://www.adobe.com/type/browser/P/P_934.jhtml
Your point is well taken that not all fonts are usable everywhere, but I do
like the idea of letting the *user* decide what those limitations are. For
example, in the example you gave of the device using bitmapped fonts, a user
might want to build PDF files at client machines that get queued up for a
machine that drives the printer itself. I think it is a "good thing" for
them to be able to do this. It is true that the view from within Acrobat
Reader is going to look different from the printed output, but I want to be
careful about artificially limiting the possibilities.
</Victor>
<Arnd>
<Victor>
> 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.
</Victor>
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.
<Victor>
> 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?
</Victor>
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>
OK, but doesn't this mean that now the user has to write a subclass of some
Renderer in order to manage his fonts? It seems like a lot of this can be
handled in the font configuration side of things, which allows it to be more
easily accessible by the user.
In the example you give, the worst case scenario is that the AFP device gets
a document it can't handle or that looks awful when it is output. It is
totally within the user's ability to prevent and correct this. So really
what we are talking about is how to prevent the user from doing something
stupid. Even this can be prevented by forcing the user to use a font
configuration that only contains the fonts available.
Nevertheless, I have no objection in principle to giving the Renderer this
level of control if it needs or wants it. Here is what I propose -- the
forayFont API design has an interface for a FontConsumer, which the client
application must supply when it is accessing font services. We'll just add a
method, something like:
boolean canProcessFontFamily(String fontFamily)
/* or perhaps the following, which would allow
FontConsumer to query the Font in more detail
about itself before deciding */
boolean canProcessFont(Font font)
The Renderer will need to simply respond "false" when a font is presented
that it doesn't know how to handle. The font system can then throw an
exception back to the client application saying that the Renderer has
rejected the font.
This would *allow*, but not really *require* a Renderer to manage fonts at
the level of detail that you envision. So most Renderers could simply:
boolean canProcessFont(Font font) {
return true;
}
I have added some comments regarding this to the FontConsumer section:
http://foray.sourceforge.net/module/font/index.html#api-design
This seems to address both of the competing concerns:
* your major concern that the Renderer have more control
* my major concern that fonts and font logic be removed from the
Renderers
It also seems to have the advantage of allowing the font subsystem to pull
information out of the Renderer as needed rather than having the Renderer
push everything it knows to the font system. For example, if a Renderer
knows how to handle all 2300 (+/-) of Adobe's fonts, it seems like a good
thing for it to only have to respond to querys about the 3 that are actually
used in a document, rather than build all 2300 and tell the system about
each of them.
Thanks for the good feedback.
Victor Mote
