On 13.09.2005 20:57:31 Vincent Hennebert wrote:
> >>Let's look at it from another side. If someone writes some 
> >>kind of FO editor or a configuration tool for FOray/FOP a 
> >>method that reports all available fonts will certainly be useful. :-)
> > 
> > OK. That makes sense. To avoid wasteful parsing, it will mean that at least
> > 3 new classes need to be exposed through interfaces (RegisteredFont,
> > RegisteredFontFamily, and RegisteredFontDesc), which may be a good thing
> > anyway.
> 
> Yes, I think it could be interesting. It would also be necessary to add 
> getStream methods, now that font parsing is delegated to the font server. 
> Currently there is only one getPDFFontFileStream method. There should perhaps 
> be 
> also a getPSFontFileStream, and something like getPDF/PSSubset? It seems that 
> the client is unable to make font subsetting with the current interface.

And what about PCL? And SVG? And AFP? IMO, output format specific code
should not appear in the main interfaces for font access. Every target
platform will have their little specialities: special font formats, font
conversions may be necessary (Type 1 to SVG fonts, SVG fonts to Type 3).
It makes sense to write font embedding code directly in the renderer.
The font provider can certainly make the job easier by providing access
to often-used data and especially to the raw font streams. But that may
be limited to certain aspects of a font type or dependant on the font
subsystem implementation. Providing a font to a layout engine has also
different requirements than embedding or using a font in a specific
output format. Maybe the Font interface should simply have a method to
return a very generic interface for more detailed and font- and
output-system-specific access to the font. Consumers of this interface
can then cast it to a special interface/class. Something like:
TargetFormatHelper Font.getTargetFormatHelper(String mime)
Subclasses of TargetFormatHelper could be PDFTargetFormatHelper
or a PSTargetFormatHelper. The Font interface in aXSL seems to be
overloaded already, so this might be an improvement anyway.

<snip/>

> > The more I think about it, encapsulating the characteristics of a specific
> > PostScript interpreter is probably the "right" way to go. Then the rendering
> > run can use that to decide whether the font needs to be embedded or not.
> > I'll have to ponder that for awhile.
> 
> Here I'm beginning to get lost because I don't know the Postscript standard.
> 
> 
> My hope to get ready before the upcoming realease starts vanishing... :-(

It's a complex problem area. I'm not surprised.

> Here's my summary of the current discussion:
> 1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS 
> file, even those that will never be used. It does this by parsing itself the 
> font files;
> 2. I can't reproduce this behavior with aXSL and FOray easily, because I've 
> no 
> direct access to the font files;

Which is a problem IMO. See my comments above.

> 3. Still doing this would require hacking the FOrayFont subpackage; that 
> would 
> result in something dirty but that should work;

I believe this can be designed in way that is even cleaner than it is
now. I just wish I had time to participate but my priorities make that
impossible.

> 4. Anyway there are several improvements to bring to the PS renderer: mainly 
> character encoding, font embedding and in a longer term two-pass rendering 
> for a 
> proper font handling.
> 
> Now I'm thinking of the next release: simply putting the font name in the 
> postscript file would be rather straightforward to implement, and should work 
> for most of cases (?), thanks to the non-standard but well-known base14 (and 
> even base35) font set.

Without the knowledge on how to access a glyph outside the default
encoding, characters like the very important Euro character will be
impossible to produce.

> But that's definitely a regression from the current state.
> Improving the PS renderer to allow proper embedding will require (1) changes 
> to 
>   the aXSL interfaces (so a certain amount of discussions), (2) me to learn 
> Postscript. That would prevent the FOrayFont subsystem from being integrated 
> in 
> the pre-release.

If aXSL-font provides access to the raw underlying font streams, that
problem basically dissolves. The following would certainly be no
problem:
InputStream Font.getRawStream(String part) where part may be "pfb", "pfm",
"afm", "ttf" etc.

> Do you agree with my summary?
> 
> Integrating FOrayFont in the pre-release would be great...

Quite unrealistic as it stands now, sorry.

> Deciding to delay the integration would give me more time to investigate the 
> insides of FOrayFont, learn PS and PDF standards and so do things much better.
> 
> If there is a decision to make it does not belong to me...

Look, the first preview release doesn't have to be perfect. It's simply
a first big sign to the outside world that FOP is not dead but is
instead back in business with a much better codebase. That's the sole
purpose of the first release. There will be no guarantees about API
stability or production fitness, in the contrary, there will be big
warning signs. It simply needs to do a few things better than 0.20.5 and
show promise to those who want to continue using FOP in the future and
to those who want to get back to an open source solution because they
are very unhappy with the commercial solutions they were forced to use
because FOP didn't provide certain features they needed or because the
licensing schemes are simply insane for certain use cases.


Jeremias Maerki

Reply via email to