On 13.09.2005 00:53:56 Vincent Hennebert wrote:
> Well, so there is no simple solution :-(
> 
> I could probably add a method like getConfiguredFonts in the font server to 
> put 
> in the postscript file all of the fonts defined in the config file. But that 
> really sounds dirty to me.
> 
> A temporary solution (before implementing a two-pass approach) would be to 
> only 
> support Base14 fonts;

Yes, that's an option, though it's not one I like very much. The other
option is to create an extension element to be put as a child into the
fo:declarations element and attached to the document using the new
ExtensionAttachment functionality to provide a hint to the PostScript
renderer which fonts are actually going to be used in the whole
documents. Something like:

<fo:declarations>
  <ps:supplied-fonts>Garamond,Garamond-Bold</ps:supplied-fonts>
</fo:declarations>

> BTW, are these fonts well defined in the postscript 
> standard? Or do they only exist in PDF?

PDF was derived from PostScript, so yes, they are well-defined.

> And a somewhat related question: how does font embedding work in postscript? 
> I 
> believe that it is like in PDF: embedding is not mandatory, one can simply 
> put 
> the font name in the file, and this will work if the corresponding font is 
> installed on the client system. So this should almost always work for the 
> fonts 
> corresponding to the PDF Base14, and not always for others. Is there a 
> font-naming convention?

Font embedding is indeed very similar to PDF and no, I don't think there
is a font-naming convention that you can rely on in every case.

> So, depending on the answers to the preceding questions: what do we choose? 
> Systematic font embedding or only putting the font name?

If the current approach is very difficult to implement, then I think
it's best to use the approach with the renderer hint. I can implement
that for you if you want. Only referring to the font name will not work
since we currently have to reencode each font to the WinAnsi charset.
And since each PostScript page should be self-sufficient and removable,
we can't do this reencoding when the font appears for the first time.

I will also need to check with my client if the renderer hint approach
would be acceptable.

> Thanks,
> Vincent
> 
> 
> Jeremias Maerki a écrit :
> > I know exactly what you mean. The only way around this is to do a
> > two-pass approach when writing PostScript, meaning that you keep track
> > of resources (like fonts) while writing the pages and later you put
> > together the complete PostScript document by including the needed
> > resources in the right places. Obviously, that means loosing a lot of
> > processing speed. PDF is in a better position because it's a
> > random-access file format while PS is streaming. We can add the font
> > objects to the PDF after we've already used them. On the other side, the
> > PDF generated this way cannot be not a linearized file which allows
> > "Fast Web View". The browser always has to load the whole PDF file to
> > display it because the cross-reference table is at the end of the file.
> > So, even PDF has, in a way, the same problem.
> > 
> > So you see: the problem is speed versus beauty.
> > 
> > BTW, that was the reason why I started introducing a better resource
> > handling with PS support, so we can later add such a mode where we write
> > the PS file in a two-pass approach.
> > 
> > On 12.09.2005 21:40:11 Vincent Hennebert wrote:
> > 
> >>In PSDocumentGraphics2D.writeFileHeader (and also in 
> >>PSRenderer.startPageSequence) the font dictionary is written into the PS 
> >>file by 
> >>a call to PSFontUtil.writeFontDict.
> >>At this time all of the fonts present in the fontInfo (defaults + those 
> >>found in 
> >>the config file) seem to be written out, even those that won't be used in 
> >>the fo 
> >>file.
> >>
> >>I'm a bit worried because I can't reproduce that easily with FOrayFont. All 
> >>I 
> >>can get is the set of fonts that were used within the document. I guess 
> >>that 
> >>rendering starts as soon as possible and that at the time when the file 
> >>header 
> >>is written out the whole document may not have been entirely parsed yet? 
> >>(but 
> >>the PDFRenderer only stores used fonts by making a call to 
> >>FontInfo.getUsedFonts!? This also is the case in PSRenderer.stopRenderer).
> >>
> >>So the question is: is there a mean to only put used fonts when writing out 
> >>a PS 
> >>font dictionary? This would be cleaner anyway.
> >>
> >>I hope I'm clear.
> >>Vincent
> > 
> > 
> > 
> > 
> > Jeremias Maerki
> > 



Jeremias Maerki

Reply via email to