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!


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

Reply via email to