Hi Jeremias, I have come to the same conclusion, but because the print out looked good I originally assumed that if the font outline was being extracted, then the font metrics were there too. I am now wondering if the printer derived the font from elsewhere!
Thanks for your help! Pete I have observed that the fallback widths are indeed being used, messing up my layout. On Mon, Jan 11, 2010 at 9:21 PM, Jeremias Maerki <d...@jeremias-maerki.ch>wrote: > Hi Peter > > Hmm, maybe it is my lack of knowledge about the Japanese language (and > as a result I'm talking utter BS), but if you look at your FO file, the > first character in the text is 0x306F (HIRAGANA LETTER HA). But there is > no width information in CZJHMNU for the character U000306F. What I do > find in this font are Katakana and Hangul characters (x0xFF**) as well > as latin characters (0x00**). Could it be that you picked text with > characters from a different character set than the one the font offers? > In that case it wouldn't be surprising if the line breaking is off > because FOP would just fallback to the width of the space (?) character. > Have you tried viewing the generated files in more than one AFP viewer? > I don't trust any single AFP viewer to provide a reliable result. > > HTH > > On 11.01.2010 11:45:13 Peter Hancock wrote: > > Hi All, > > > > I am having problems determining the font-metrics of double-byte afp > fonts > > and wonder if you can help. > > > > I am currently trying to implement support for double-byte fonts in the > AFP > > renderer. I am following the outline in > > http://wiki.apache.org/xmlgraphics-fop/AFPFonts as a guide. > > > > I am using the* J-Heisei Mincho* Unicode font resources, as suggested in > the > > wiki. I have managed to reference this font in my fop.xconf and, with > minor > > code changes, I have managed to produce the .afp from the attached > xsl-fo > > (see attached screen shot of the .afp rendered in an AFP viewer - note > the > > font not supported). When I print this out the correct font is used > which I > > assume is extgracted from the embedded outline definitions. > > > > The problem I am now addressing affects the layout of the text. > Comparing > > the attached pdf to the screen image of the afp (ignore the glyphs used > by > > the afp viewer), you will note that the line-breaking is not respecting > the > > font metrics (I am aware that the single fo:block specified in the > xsl-fo > > will not layout the text nicely but it should be bounded by the page > > boundary). The correct character width is required by the layout engine > to > > determine page breaks. Fop tries to extract this data from the font > > resource "CZJHMNU" by reading from the bytes within the 'Font Index' > > structured field (see org.apache.fop.afp.fonts. > > AFPFontReader.java). This data represents a mapping from font metric > data > > to the 'Graphic Character UCS Identifier' -e.g 'U000FFAA' for the > > code-point FFAA is mapped to font width etc. However the GCUIDs of the > > characters in my text cannot be found in this structured field (although > > the relevant GCUIDs do appear in the TT11200 codepage). > > > > At the moment I am assuming I the font resource is either not meant > > double-byte fonts, or the font metrics are somehow reused for the > characters > > that are not mapped? > > > > I am aware that this post is a little vague and due to the size and > > licensing issues I am unable to attach the CZJHMNU font resource - but if > > you can point me in the right direction that would be great. > > > > > Jeremias Maerki > >
