Problem is, currently fontchooser widgets keep a PangoFontDescription internally and use the pango_font_description_to_string() return value for user display of the selected font.  However, this is less than ideal.

As an example, consider the Noto Sans CJK DemiLight font.  PangoFontDescription parses that, notices that DemiLight is another name for SemiLight, detects the font weight correctly, and then converts to text as Noto Sans CJK SemiLight, which is not the name of any font in existence.

The PangoFontFace has that correct name.  And the fontchooser used to use that.  I'll attach a patch for fontchooserwidget that resurrects that.  However, the bug will remain in fontbutton, and we can't fix it there because we don't have the PangoFontFace anymore.

So I think the correct way to fix this is to add new API to fontchooserwidget and fontchooserbutton to get/set strings, instead of PangoFontDescription.  And make fontchooserbutton use that new API of fontchooserwidget, to correctly retain the preferred name.

I'm not sure what else might need fixing, but this is a good start.

was there a patch coming, Behdad ?

Created attachment 283536 [details] [review]
proof of concept