[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Devel] Re: CFF problems
Blinn, Eric W
RE: [Devel] Re: CFF problems
Wed, 22 Nov 2000 09:50:26 -0600
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
> 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
> (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
> you see are getting shifted right 16, so the number is much smaller.
> it makes the assumption that dict->font_matrix.yy is postive, which for
> font, it is not. I will committ a patch for this.
> Finally, left side bearings can be negative. This usually means the left
> of the glyph is to the left of the glyph origin. I rarely see this, but I
> it is done.
> I'll look into why ftview doesn't work with CFF fonts...
> 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
- RE: [Devel] Re: CFF problems,
Blinn, Eric W <=