Vincent Hennebert wrote:

> > 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.

OK. I have actually not been sure how much of the code is reusable between
the two. PS rendering is way lower on my priority list than PDF, so I don't
work with it much. Here is our decision tree:

if (PS font embedding works in FOP now) {
    if (it been added since May, 2004, when I forked the FOP code) {
        we need to patch FOray with that logic;
    } else {
        Victor somehow lost this in the refactoring work;
        FOray still needs to be patched;
    }
} else {
    we can add PS font embedding later;
}

I am not sure what you mean "getPDF/PSSubset".

> > 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... :-(
> 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;

Hmmm. I think something has changed here since I last looked at it.
Jeremias?

> 2. I can't reproduce this behavior with aXSL and FOray 
> easily, because I've no 
> direct access to the font files;

Point me to the FOP code that does the embedding, class name(s) and line
numbers, and I'll see if I can extract it into an aXSL-exposed method.

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

Better would be to just make aXSL provide what needs to be provided. If we
can hack FOray to do it, then we should be able to expose what is needed.
Since nothing we are talking about here is a pollution of the interface, we
should just be able to change the interface.

> 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.

OK. I am confused. I thought above that font embedding worked in PS now, but
this seems to indicate that it does not.

> 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. 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.
> 
> Do you agree with my summary?

I can take some of this burden off of you, in that I can hopefully fix aXSL
and FOray to provide what is needed. If that is done well, you shouldn't
need to learn too much PostScript to get it to work, and perhaps one of the
other developers can help you get it glued in. I don't know how much work it
will take for me to get the FOray PS Renderer working (it may work now), I
can use that as a test bed also.

Even if we can't get PS embedding working in time for the release (and I
think we should be able to), I am not sure whether this is a step backwards
from 0.20.5. I can't imagine that I just totally yanked PS embedding code
out of the FOray PS renderer.

> Integrating FOrayFont in the pre-release would be great...
> 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...
> Vincent

Nor to me. I'll just try to help get working what you need and let you guys
decide what works best.

Victor Mote

Reply via email to