Created attachment 110989 [details] [review]
The patch

Created attachment 110991 [details]
A test program that prints a glyph from a font into a PNG file

Needs cairo and pango.
Example:
pango-test "Symbol 72" 42 out.png

Without the patch, out.png contains a "G" and a warning is generated :
(pango-test.exe:2908): Pango-WARNING **: couldn't load font "Symbol Not-Rotated 72", falling back to "Sans Not-Rotated 72", expect ugly output.

With the patch, everything works fine and out.png contains a Gamma.

I am still not convinced that this is the right thing to do... Sure, the patch is trivial, but... if you need Greek characters, why not use the proper Unicode representation of them, and let the Greek glyphs present in the normal fonts be used instead?

Both the pseudo-fonts like "sans" or "serif", and also most of the normal real Windows fonts like Arial or Georgia do cover Greek. Won't this patch just perpetuate the (MS-DOS age?) misunderstanding that one should use the Symbol font to write Greek, and then use "a" for "α" etc? Are the Greek glyphs in Symbol somehow better that the ones in Times New Roman, Arial, etc?

Sorry if I seem stubborn...

I just agree with Tor that the change looks bogus, from a general Pango standpoint.

My point is not that I need a greek character from a symbol font. 
I am writing a formula editor. As you can imagine, such an editor should be able to show radicals. The unicode standard therefor has two general symbols:
U+221A SQUARE ROOT
U+23B7 RADICAL SYMBOL BOTTOM

That is not enough for good layout. The Math2 font (a symbol font) contains 24 glyphs for laying out radical signs.

Created attachment 111590 [details]
All glyphs in the math2 font

Here are all the glyphs of the Math2 font, I mentioned.

OK, thanks. I was hoping you would say exactly something like that, then it indeed makes sense I guess. Should we somehow try to prevent misguided users from using fonts without Unicode cmaps in the normal way, and allow only Peter's way to access it using glyph indexes directly? Is that even possible, no idea. Behdad?

It seems that pangoft2 allows the Symbol font just fine, and if you use it for the string "abc" you get "αβγ", etc. Eek, but I guess it can't be so bad then if pangowin32 does the same.

/me doesn't have a Symbol font around.

Ideally with all backends, one should be able to load symbol fonts (or any fonts without Unicode cmaps), but not meaningfully use them.  That is, their charset should report to support no character.  You can then use show_glyphstring functions to render individual glyphs using their glyph ide (not fake character code).  This also ensures that the symbol font will not be accidentally used when it's not intended to.

Does that make sense?  It will make using them harder as one can't simply use PangoLayout with them anymore.  An alternative would be to provide something like the PangoFcDecoder, which is a way to attach custom character to glyph mapping to fonts.  That way you can bring symbol fonts back to life if that's really what you want to.

/me wishes PangoFcDecoder was rewrriten generically.

-- 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/135.