GNOME Bugzilla – Bug 416526
Space size problems
Last modified: 2018-05-22 12:26:29 UTC
With code like shown below, I am getting these results on a mostly standard SuSE 10.1 system. Pango is 1.14.7 font=Sans 10 U200a --> 7168x14336 U2009 --> 7168x14336 U2008 --> 7168x14336 U0020 --> 4096x16384 U2006 --> 1024x24576 Issues: 1. U200a is supposed to be no wider than any other spaces. 2. U2006 is thinner [good] but is very tall. This seems like bad interaction between pango and something below. I want to use a different kind of spaces for the purpose of filling. But there doesn't seem to be a good one available. static gunichar thin_spaces[] = { 0x200a, /* Hair space */ 0x2009, /* Thin space */ 0x2008, /* Puctuation space */ ' ', 0x2006 /* Six-per-em space */ g_print ("font=%s\n", pango_font_description_to_string (font->desc)); PangoLayout *layout = pango_layout_new (context); pango_layout_set_font_description (layout, font->desc); for (i = 0; i < (int)G_N_ELEMENTS (thin_spaces); i++) { gunichar uc = thin_spaces[i]; char ucs[8]; int w, h; ucs[g_unichar_to_utf8 (uc, ucs)] = 0; pango_layout_set_text (layout, ucs, -1); pango_layout_get_size (layout, &w, &h); g_print ("U%04x --> %dx%d\n", uc, w, h); }
The problem is that Pango does not handle space characters any different than other chars. So, you get the space char from the first font that includes a glyph for it...
> The problem is that Pango does not handle space characters any > different than other chars. Is that really true? There are a lot of hits on G_UNICODE_SPACE_SEPARATOR over in break.c. Point being: it could. > So, you get the space char from the first font that includes a > glyph for it... For some definition of "first", yes. You will notice that it seems to have picked a size more like 18pt and not the 10pt I asked for. (Would you consider that a fontconfig bug by itself?) This bug really lives on the borderline between pango and fontconfig, but something really is wrong when "Sans" doesn't produce reasonable results.
(In reply to comment #2) > > The problem is that Pango does not handle space characters any > > different than other chars. > > Is that really true? There are a lot of hits on G_UNICODE_SPACE_SEPARATOR > over in break.c. Point being: it could. Point is taken. That is in fact bug 145275. Dupping. > > So, you get the space char from the first font that includes a > > glyph for it... > > For some definition of "first", yes. The definition doesn't really matter. What matters is that it sorts the fonts into an order, and picks the first that has the glyph. No matter what the list looks like, you'll end of getting glyphs from different fonts, and they differ in sizes just because not all fonts have the same metrics (the will in an ideal world, but). > You will notice that it seems to have > picked a size more like 18pt and not the 10pt I asked for. (Would you > consider that a fontconfig bug by itself?) No, not a fontconfig bug. Definitely not. It's a font bug if some font has a size like 18 at 10pt. > This bug really lives on the borderline between pango and fontconfig, but > something really is wrong when "Sans" doesn't produce reasonable results. There's not much fontconfig can do here. Pango on the other hand can be smarter. *** This bug has been marked as a duplicate of 145275 ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/69.