Re: [ft-devel] vertBearingY of CFF glyphs is always unscaled
On Thu, Apr 4, 2013 at 12:14 AM, Werner LEMBERG w...@gnu.org wrote: I fear that support for the various vertical metrics components is severely broken in FreeType. In particular, values are computed differently for different font formats. To fix this for all font formats ... First we need to fix it for CFF first, where the problem was reported. We'l deal with other formats later based on this example. The docs say that the bearings are defined by CBox ( http://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html) and this is what the code in cffgload.c does for horizontal layout. I do not understand why it gets crafty for vertBeraingX and forgets about vertBearingY altogether. I would just set it to CBox values according to the definition, but I sense a trap because the pictures in the doc show that the origin is different for different layouts. Does CBox depend on the layout as well? It looks like it should. Thoughts? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] vertBearingY of CFF glyphs is always unscaled
On Thu, Apr 04, 2013 at 06:14:07AM +0200, Werner LEMBERG wrote: [CCed Behdad] I had an issue with vertical text layout in HarfBuzz, in short we have the calculation: y = metrics.horiBearingY - (-metrics.vertBearingY) and since horiBearingY is scaled with font size while vertBearingY is not, the result was completely wrong resulting in misplaced glyphs (it was mysterious because it affected only glyphs where the value of this calculation was used, and the degree of misplacement changes with font size). I fear that support for the various vertical metrics components is severely broken in FreeType. In particular, values are computed differently for different font formats. To fix this for all font formats it would be necessary to investigate the issue in great detail; in particular, we need a detailed comparison with the MS and Apple engines: Some comments in FreeType indicate that, for example, the OpenType specification and recommendations contradict the actual implementation in Windows (and/or OS X). Do you have some time to devote to this issue? Or maybe another volunteer? I fixed my immediate problem by using FT_LOAD_NO_SCALE and then scaling on my own (since I don't want embedded bitmaps nor hinting anyway). I'd like to look into vertical typesetting in general in the next months, but right now I know very little about it to promise anything. Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] vertBearingY of CFF glyphs is always unscaled
Hi all, While debugging some mysterious glyph positioning issue, I found that the vertBearingY of CFF glyphs is always the same no matter what font size is. The attached patch fixes the issue for me, though I'm not sure if this is the right place to scale the metric. Regards, Khaled diff --git a/src/cff/cffgload.c b/src/cff/cffgload.c index 30996c1..c8d130d 100644 --- a/src/cff/cffgload.c +++ b/src/cff/cffgload.c @@ -2988,6 +2988,7 @@ /* Then scale the metrics */ metrics-horiAdvance = FT_MulFix( metrics-horiAdvance, x_scale ); metrics-vertAdvance = FT_MulFix( metrics-vertAdvance, y_scale ); + metrics-vertBearingY = FT_MulFix( metrics-vertBearingY, y_scale ); } /* compute the other metrics */ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] vertBearingY of CFF glyphs is always unscaled
[CCed Behdad] I had an issue with vertical text layout in HarfBuzz, in short we have the calculation: y = metrics.horiBearingY - (-metrics.vertBearingY) and since horiBearingY is scaled with font size while vertBearingY is not, the result was completely wrong resulting in misplaced glyphs (it was mysterious because it affected only glyphs where the value of this calculation was used, and the degree of misplacement changes with font size). I fear that support for the various vertical metrics components is severely broken in FreeType. In particular, values are computed differently for different font formats. To fix this for all font formats it would be necessary to investigate the issue in great detail; in particular, we need a detailed comparison with the MS and Apple engines: Some comments in FreeType indicate that, for example, the OpenType specification and recommendations contradict the actual implementation in Windows (and/or OS X). Do you have some time to devote to this issue? Or maybe another volunteer? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
