Hi Adrian,

I'm not really a specialist of the font handling stuff in FOP, but
having worked a bit in this area I can drop a few ideas (and ask a few
naive questions), in the hope they will be useful.

> In the process of looking at this bug
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=42861) I came to the
> conclusion that I´m not really happy with the current font handling
> implementation.  There is quite a bit of duplicated effort between the
> renderers with regards to font configuration.

Can you give some examples? Not that I don't believe you, just to have
some concrete things to discuss about. For example, IIRC, in PDFFactory
there is some code to read the font stream for embedding it. I guess
there is about the same code in the PS renderer for embedding TrueType
fonts. That job should really be deferred to the font library which
would directly provide the stream to those renderers that need it. Is
that what you're thinking of?

> I would very much like to see a shared ¨FontSource¨ implementation (e.g.
> both the Postscript and PDF renderers could make use of a shared
> Base14FontSource and CustomFontSource) instead of having their own
> separate configurations.  Any new implementation would of course

What would a FontSource exactly correspond to? What would be the
different kinds of FontSources? Would a Base14FontSource really make
sense? I mean, base14 fonts are PDF- (and, to a certain extent, PS-)
specific. Does a PDF renderer really need to know that it's manipulating
a base14 font? Isn't it just enough to know whether the font should be
embedded or not?

Jeremias has been having some ideas regarding font handling for some
time. You can probably find some of them by looking at the archives [1].
I hope he'll have time to speak up but, if I remember well, he wants to
group fonts by kinds: Type1 fonts, TrueType fonts, AFP fonts, AWT fonts,
SVG fonts, etc. Each kind would be usable by one or more renderers; for
example the PDF renderer could use Type1, TrueType and AWT fonts
(although it would not be possible to embed the latter).

I think this all makes sense. Ideally we would define a common API that
would be used by the renderers and hide as much as possible of the
actual font manipulation. The renderers would keep only their format's
specific code (e.g., creating a PDF font object).

> (initially at least) remain backwards compatible with existing FOP font
> configurations.  I believe these ideas were spoken about a while ago and
> I do not think it would be too much work and it should simplify font
> configuration somewhat and should be more efficient in embedded
> implementations that make use of more than one renderer.  Its probably a
> bit late in the day to make the 0.94 release, but in the longer term
> does anybody have any initial thoughts on this proposal?

I hope those few ideas will give you some things to think about. Anyway,
I think there's still quite a bit of work to do in this area, even if
the auto-detection stuff was a big step forward.

Thanks for looking into this,

[1] See, among others, the first thread about FOrayFont (hem, and please
don't pay attention to the flame war!)

Reply via email to