RE: [Devel] Re: CFF problems

[Blinn, Eric W]

Yes, the CFF font came from a Distiller produced PDF 
file. For my particular application, all the CFF fonts 
are coming from Distiller produced PDF files, so that 
has pretty much been my frame of reference while 
looking into these issues.

Thanks for the clarification on several of the issues 
and also the fixes that came in your follow up messages. 

If David can point me to the correct function for 
transforming the font outside of the CFF guts, that 
would be great. Otherwise, I'll dig through the code 
to see what I can figure out.

You said the left side bearing can in fact be negative. 
That being the case, then it might be a good idea for 
someone to make a small change to the "FreeType Glyph 
Conventions" document. It states that the left side 
bearing "is positive for horizontal layouts, and in most 
cases negative for vertical ones". Perhaps that "in most 
cases" should also be applied to horizontal layouts 
having positive left side bearings.

Even with the possibility of a negative left side bearing 
in mind, I don't doesn't appear to be the intent with CFF 
fonts like the one I provided. I haven't tried your t2parse 
fixes yet (will be doing that shortly). Did it clean up the 
metrics that lead to the negative left side bearing?

> ----------
> From:         Tom Kacvinsky[SMTP:address@hidden
> Sent:         Wednesday, November 22, 2000 12:38 AM
> To:   address@hidden
> Subject:      [Devel] Re: CFF problems
> 
> 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>> 
> > 
> 
> 
> 
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel
>