Pango Fc Shaper gives incorrect geometry information

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Pango Fc Shaper gives incorrect geometry information

Simon Cozens
I've had some bug reports about my SILE typesetter providing badly
letter-spaced output on Linux, when the output looks fine in OS X. I've
tracked this down to pango_shape returning geometries which are being
(erroneously) quantized to integer multiples of PANGO_UNITS.

For instance, the code below on OS X (using the pango-basic-coretext module)
returns the correct answer, 7.070312. On Linux, it reports the width of a 12pt
Gentium "z" as 7.000000pts. The width of an "m" is 12.851562pt on OS X, but
12.000000pts on Linux.

I'm not sure what to do (other than shift to harfbuzz for shaping...) to get
the correct results. Is it something inside Pango quantizing the geometries,
or something inside FreeType?

#include <pango/pangocairo.h>

int main() {
   PangoFontMap * fm = pango_cairo_font_map_get_default ();
   PangoContext * pango = pango_font_map_create_context(fm);
   PangoAttrList * pal = pango_attr_list_new();
   PangoAttribute * pa1 = pango_attr_family_new("Gentium");
   PangoAttribute * pa2 = pango_attr_size_new(PANGO_SCALE * 12);
   PangoItem* charitem;
   PangoGlyphString* pgs = pango_glyph_string_new();
   PangoGlyphInfo g;

   pango_attr_list_insert(pal, pa1);
   pango_attr_list_insert(pal, pa2);
   charitem = pango_itemize(pango, "m", 0, 1, pal, NULL)->data;
   pango_shape("m", 1, &(charitem->analysis), pgs);
   g = (pgs->glyphs)[0];
   printf("%f\n",g.geometry.width/(double)PANGO_SCALE);
}
_______________________________________________
gtk-i18n-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Reply | Threaded
Open this post in threaded view
|

Re: Pango Fc Shaper gives incorrect geometry information

Nicola Fontana-3
Il Thu, 04 Sep 2014 16:34:29 +0100 Simon Cozens <[hidden email]> scrisse:

> ...
> For instance, the code below on OS X (using the pango-basic-coretext module)
> returns the correct answer, 7.070312. On Linux, it reports the width of a 12pt
> Gentium "z" as 7.000000pts. The width of an "m" is 12.851562pt on OS X, but
> 12.000000pts on Linux.

A bit late but... for the posterity.

I had this very same issue recently. I think this is not a bug: my
guess is this is the expected behavior of the hinting algorithm. I
found some rounding code in pango triggered by it, e.g.:

https://git.gnome.org/browse/pango/tree/pango/pango-layout.c?h=1.40.12#n4688

When the device unit is pixel it is not a big deal, but if you use
points (AFAIK the default device unit on a cairo PDF surface) the
result is quite gross.

> ...
> #include <pango/pangocairo.h>
>
> int main() {
>    PangoFontMap * fm = pango_cairo_font_map_get_default ();
>    PangoContext * pango = pango_font_map_create_context(fm);
>    PangoAttrList * pal = pango_attr_list_new();
>    PangoAttribute * pa1 = pango_attr_family_new("Gentium");
>    PangoAttribute * pa2 = pango_attr_size_new(PANGO_SCALE * 12);
>    PangoItem* charitem;
>    PangoGlyphString* pgs = pango_glyph_string_new();
>    PangoGlyphInfo g;
>
>    pango_attr_list_insert(pal, pa1);
>    pango_attr_list_insert(pal, pa2);

Disabling the hint metrics just before pango_itemize() returns the
expected result:

    cairo_font_options_t *options = cairo_font_options_create();
    cairo_font_options_set_hint_metrics(options, CAIRO_HINT_METRICS_OFF);
    pango_cairo_context_set_font_options(pango, options);
    cairo_font_options_destroy(options);

>    charitem = pango_itemize(pango, "m", 0, 1, pal, NULL)->data;
>    pango_shape("m", 1, &(charitem->analysis), pgs);
>    g = (pgs->glyphs)[0];
>    printf("%f\n",g.geometry.width/(double)PANGO_SCALE);
> }

Ciao.
--
Nicola
_______________________________________________
gtk-i18n-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list