xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: AFP Font Question
Date Wed, 04 Mar 2009 15:41:27 GMT
On 04.03.2009 16:31:34 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> Hi Jeremias,
> thanks for the detailed reply. Comments inline.
> > To a certain degree, it is already possible using the Intermediate
> > Format. You'd generate the IF file using the font metrics for the PDF
> > output but render the IF file to AFP output. The tricky thing is to
> > synchronize the font setups for PDF and AFP (especially the font names)
> > so there won't be any font selection problems when generating the AFP.
> > However, the devil is in the detail: for performance reasons we don't
> > store the position of each individual glyph. This is what would be
> > necessary to achieve a maximum of "equalness". Otherwise, little
> > differences in the native font metrics can accumulate to a visible
> > difference in the final output if you have long strings or use things
> > like letter-/word-spacing. So much for what is possible today...
> So basically it's not really possible because both Area Tree XML and IF 
> XML use letter/word spacing instead of absolute positioning each glyph.

"Not possible" is a bit hard. Let's say that in some cases the results
will not be as expected. In cases where you just have simple
left-aligned text and relatively short strings, it will probably be good
enough. (Speculation, no real-life tests performed. I think an
experiment is worth the time.)

> > It is thinkable that a special subclass of AFPPainter would be written
> > that has a special drawText() method which could use an additional
> > FontInfo object set up for a PDF renderer to calculate individual glyph
> > positions but then paint the glyphs using normal AFP infrastructure.
> > Just so there are no illusions: that comes with a performance penalty. I
> > can also not guarantee that the result is much better than the above.
> > Depends on the documents.
> That is one possibility I can mention to the client. Any idea on how 
> much effort it would be to implement these changes in the AFP 
> Renderer/Painter?

Around 1-2 days for someone who knows his way around that class. The
problem is deciding how best to expose that functionality API-wise.

> > 
> > Technically correct is what works and doesn't have a negative impact on
> > the overall system. ;-) At any rate, it's possible.
> > 
> > So I guess that lists the downsides also. Let's also look at other
> > possible solutions:
> > 
> > Normal AFP outline fonts are nothing other than Type1 PFB fonts embedded
> > in a FOCA resource. Type1 fonts are cheap. One could experiment by
> > writing a program that can turn a Type1 font into a FOCA outline font by
> > generating the necessary data structures (general and glyph metrics)
> > from the original font files. However, there's a certain risk that font
> > generated like this may not have optimal values everywhere so some
> > differences could result from this. However, I consider the risk here
> > relatively small as we're speaking about a scalable font. But you also
> > have to take into account the cost involved writing such a converter.
> No need to write such a converter. IBM supplies such a program as part 
> of the software that ships with Info Print. I guess I need to track down 
> the CD and try it out. Thanks for the idea!


> > 
> > Another approach would be to generate bitmap fonts from Type 1 or
> > TrueType fonts. Creating bitmap images of single glyphs is easy. However,
> > bitmap fonts are usually manually optimized for the various sizes and
> > target resolutions which an automated program probably couldn't do that
> > well. The same risk as for the converted Type 1 font applies, only the
> > risk of suboptimal output is definitely higher.
> > 
> > Going further: modern AFP/IPDS environments allow to directly use
> > TrueType fonts as data object resources. FOP could be taught to use
> > TrueType fonts which would make it possible to use the same font for PDF
> > and AFP. Of course, if it's no option to uprade an old AFP/IPDS
> > environment...
> > 
> > Finally, there are various tools on the market (ex. Compart's DocBridge
> > Mill) which can convert AFP to PDF. That would entirely bypass the
> > problem. However, PDFs generated that way may not offer the same
> > feature-set that FOP can offer and the generated files might be bigger
> > than FOP-generated PDFs.
> Thanks for your help,
> Chris
> > 
> > HTH
> > 
> > On 04.03.2009 09:47:11 Chris Bowditch wrote:
> > 
> >>Hi All,
> >>
> >>one of my clients is using the PDF and AFP Renderers to produce the same 
> >>document via different outputs. PDF is for archiving and AFP for 
> >>Printing. However, currently the output between the 2 is different. The 
> >>AFP output line breaks differently to the PDF version, with the text 
> >>appearing larger and bolder despite the font size being the same between 
> >>the output channels. After some investigation I realised that the cause 
> >>of the problem was the use of raster AFP Fonts. When I tested PDF and 
> >>AFP output using TTF in PDF and an equivalent outline Font in AFP the 
> >>output looks identical. So I thought great and told the client to switch 
> >>to Outline Fonts in AFP.
> >>
> >>However, my client doesn't want to do that. Apparently there would be 
> >>some large costs to purchase all the outline fonts necessary for their 
> >>large collection of existing documents. My client has asked if it is 
> >>possible to enhance FOP to use metrics from TTF or Type1 Fonts when 
> >>working with AFP raster Fonts, and just use the glyphs from the raster 
> >>font. This would ensure output between PDF and AFP looks identical. I 
> >>know XEP does something similar. Is this enhancement feasible? Is it 
> >>technically correct to use metrics from one font type and use the glyphs 
> >>from other. Is there any downside?
> >>
> >>Comments would be appreciated.
> >>
> >>Thanks,
> >>
> >>Chris

Jeremias Maerki

To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message