After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 490609 - Font selector is limiting styles for default aliases
Font selector is limiting styles for default aliases
Status: RESOLVED OBSOLETE
Product: pango
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2007-10-26 18:19 UTC by Nicolas Mailhot
Modified: 2018-05-22 12:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas Mailhot 2007-10-26 18:19:57 UTC
More and more fonts are available with more than the 4 legacy
regular/italic/bold/bold italic styles (dejavu is such an example)

If you make such a font the default "Sans" "Serif" or "Monospace", however,
only the  4 legacy styles will be exposed via the  "Sans" "Serif" or
"Monospace" aliases

keithp in https://bugs.freedesktop.org/show_bug.cgi?id=12236 writes the problem is gtk-side
Comment 1 Nicolas Mailhot 2007-10-26 18:20:54 UTC
quoting keithp "the gnome font selector would have to convert the
alias into a family name and then list that family to detect which styles were
available."
Comment 2 Owen Taylor 2007-10-26 18:32:26 UTC
I think keithp forgot to mention that the Sans alias is not any particular
font, it's a list of fonts. I don't know what you'd want Pango to report,
and I doubt it would be meaningful to the user rather than confusing.

If the user knows in particular what font they want, and want extended
styles from it, they must select that font by name.

(This can be done in gnome-font-properties for the default fonts on
the system.)

If you want to try to come up with a patch, the relevant code is in:
pangofc-fontmap.c:pango_fc_family_list_faces()
Comment 3 Nicolas Mailhot 2007-10-26 18:50:54 UTC
Yes, Sans (and Serif, and Monospace) are a composition of fonts. User-desirable behaviour would be:

if sans is composed of foo (A, B styles) and bar (B, C styles) sans should be available in A, B, C styles

Without any bias towards bold, italic and bolditalic

In particular sans condensed is a very common user need (arial narrow windows-side) and it should be exposed when sans is defined with one or several fonts that have a condensed style
Comment 4 Owen Taylor 2007-10-26 19:00:58 UTC
But imagine that one of the fonts way down in the big list of fonts in
Sans, had an unusual style name, maybe, "Very Stretched". Would you really
want that to appear when they selected Sans, when sans is Deja Vu?

So that implies that maybe it should be just the top font sorted according
to the language of the current locale. But the locale doesn't always 
correspond to the document I'm working on or the text I'm typing.
Comment 5 Nicolas Mailhot 2007-10-26 19:12:10 UTC
That's a risk I'm willing to take – the fonts that get in the default aliases are carefully chosen I doubt this case will be hit often.

Another possibility since the default aliases are synthetic anyway would be to rewrite the styles to standard names, so styles with the same weight stretch and slant are always aliased the same way
Comment 6 Behdad Esfahbod 2007-10-27 07:46:09 UTC
Nicolas, the fonts returned by the default aliases are not carefully chosen.  They are a set of carefully chosen (if you want to call it) list followed by all other lists available, only pruned based on their coverage.  So, if you have one Arabic font on the system that has a weird style, you get that style listed, but no Latin font even has that style.

Owen said it all already.  My current feeling is:

  - If you want DejaVu Sans Condensed, just choose it!

  - Listing styles from the top matching font, ok maybe.
Comment 7 GNOME Infrastructure Team 2018-05-22 12:35:20 UTC
-- 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/104.