Re: Font metrics problems implementing AFP Unicode support

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

Re: Font metrics problems implementing AFP Unicode support

[Peter Hancock <pe...@gmail.com>]

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