[Devel] Re: CFF problems

[Tom Kacvinsky]

OK,

This font came from a Distiller produced PDF file, didn't it?

Next, the FontMatrix in the font is [.001 0 0 -.001 0 0], so this font is
supposed to be flipped over the horizontal axis.  As I am not a user of FreeType
(only a debugger), perhaps David can point you to the correct function for
transforming a font (it is best not to mess with the CFf guts -- they are
working properly in this case).

The default grid for this ont is not 32768 units by 32768 units.  The numbers
you see are getting shifted right 16, so the number is much smaller.  However,
it makes the assumption that dict->font_matrix.yy is postive, which for your
font, it is not.  I will committ a patch for this.

Finally, left side bearings can be negative.  This usually means the left edge
of the glyph is to the left of the glyph origin.  I rarely see this, but I know
it is done.

I'll look into why ftview doesn't work with CFF fonts...

Tom

On Tue, 21 Nov 2000, Blinn, Eric W wrote:

> 
> I'm seeing some problems with CFF fonts. I have some fixes
> or workarounds that work reasonably with my application, 
> but I've also been digging down into the FreeType code to 
> understand what is going on and wanted to go ahead and 
> bounce the problems off the FreeType and/or CFF gurus 
> on the list.
> 
> I've attached a small CFF font file to demonstrate the 
> problems. Load it into ftview with a ppem of 72 (note that 
> the ftview from ft2demos-current fails to open a CFF file 
> but the one from ft2demos-beta8 works). Once the font is 
> brought up in ftview, the problems are as follows:
> 
> 1) The glyphs are tiny. In T2_Init_Face() the units_per_EM
> is being set extremely high, at 32768 grid units. Standard 
> Type 1 Postscript fonts should be fixed at 1000 grid units, 
> right? Setting units_per_EM to 1000 seems to get the CFF 
> glyphs rendered at the proper size.
> 
> 2) The glyphs are flipped (reflected over a horizontal 
> midline). There is some disabled code in T2_Load_Glyph() 
> where FT_Outline_Transform() would otherwise be called. 
> Enabling that code and feeding it the appropriate transform 
> matrix values flips the glyphs into the orientation I would 
> expect.
> 
> 3) The pen position is not always getting advanced correctly. 
> Glyphs often sit on top of one another. This appears to be 
> caused by incorrect glyph metrics, particularly a negative 
> left side bearing (horiBearingX). The left side bearing 
> should always be positive for a horizontal layout, right? I 
> thought maybe this was happening because the metrics were 
> being calculated using a control box. You might expect this
> behavior if some control points lie far enough outside the 
> glyph's bounding box. However, I've tried using the bounding 
> box to calculate the metrics instead, but saw no improvement.
> 
> Thanks,
> Eric Blinn
> 
>  <<example.cff>> 
>