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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
