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 95043 - GTK doesn't deal well with arbitrarily named font styles
GTK doesn't deal well with arbitrarily named font styles
Status: RESOLVED OBSOLETE
Product: pango
Classification: Platform
Component: general
1.1.x
Other Linux
: Normal normal
: Medium feature
Assigned To: pango-maint
pango-maint
: 147372 169314 760686 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-10-07 05:41 UTC by Nicholas Miell
Modified: 2018-05-22 12:00 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Bermuda LP Dots example (48.46 KB, image/png)
2002-10-07 05:42 UTC, Nicholas Miell
Details
Bermuda LP Open example (48.53 KB, image/png)
2002-10-07 05:43 UTC, Nicholas Miell
Details

Description Nicholas Miell 2002-10-07 05:41:34 UTC
Some font faces don't use the usual Regular/Bold/Italic/Bold Italic style
naming scheme, either because they provide more weights or obliques than
normal, or because they have styles that don't have anything to do with
weight or obliqueness.

The font selector doesn't like these for some reason, and behaves in a
somewhat random manner -- selecting many of the displayed styles does nothing.
Comment 1 Nicholas Miell 2002-10-07 05:42:28 UTC
Created attachment 11427 [details]
Bermuda LP Dots example
Comment 2 Nicholas Miell 2002-10-07 05:43:24 UTC
Created attachment 11428 [details]
Bermuda LP Open example
Comment 3 Nicholas Miell 2002-10-07 05:46:02 UTC
I've attached two screen shots of the font selector with an "exotic"
font selected.

The first image has the Dots style selected, the second has the Open
style selected, but in both cases the Squiggle style is displayed.

As far as I can tell, there is no way to select any other style
besides Squiggle. (And I don't know why GTK settled on the Squiggle
style.)
Comment 4 Owen Taylor 2002-10-07 12:48:17 UTC
Pango should handle fonts with more weight than normal without
any problems. 

If the styles of the font don't hvae anything to do with
stretch/weight/obliqueness, then what really needs to happen
is that the fonts should be treated as separate fonts with
similar names. This is something that actually needs to
happen at the fontconfig or maybe even the FreeType level.

 - Are you using Xft1 or Xft2
 - Are these postscript Type1 fonts or TrueType fonts?
Comment 5 Nicholas Miell 2002-10-08 02:26:38 UTC
They're Type1 fonts and I'm using fontconfig/Xft2 (RedHat 8).

I have less exotic Type1 fonts that have the same problem --
they have style names like "Extra Black", "Demi Bold", "Oblique",
"Roman", "Semibold Sans", "45 Light", "55 Roman", "95 Black", etc.

Basically, Type1 style names are arbitrary and seperating each style
into a new face doesn't make any sense, because some of these fonts
have a dozen or so style names, all of which are the visually the same
font.
Comment 6 Owen Taylor 2002-10-08 14:48:23 UTC
Reassigning to Pango, though it's really more of a fontconfig
issue than a Pango issue.

For some more data, looking at the fonts in "Adobe Originals Sampler 2",
fontconfig considers there to be four families:

 Minion:Condensed, Condensed Italic, Bold Condensed Bold, Bold
Condensed Italic
 Sanvito: Light, Roman
 Penumbra: Semibold Sans, Semibold Flare, Semibold Serif
 Viva: Regular, Light Condensed, Bold Extra Extended 

Pango, like CSS, orders the faces within a particular family 
along the axes of:

 weight, stretch, style [slant], variant [smallcaps/normal]

Pango can't deal with styles that can't be distinguished along
these axes, though there provisions in the API for future
extensions to make it possible.

So, Pango would be happiest if the families appeared as:

 Minion:Condensed, Condensed Italic, Bold Condensed Bold, Bold
Condensed Italic
 Sanvito: Light, Roman
 Penumbra Sans: Semibold
 Penumbra Flare: Semibold
 Penumbra Serif: Semibold
 Viva: Regular, Light Condensed, Bold Extra Extended

Note however, that fontconfig doesn't categorize fonts by
stretch, so Pango using fontconfig can't deal properly with
stretch variants, and would need the more split up:
 
 Minion Condensed: Regular, Italic, Bold, Bold Italic
 Sanvito: Light, Roman
 Penumbra Sans: Semibold
 Penumbra Flare: Semibold
 Penumbra Serif: Semibold
 Viva: Regular, 
 Viva Condensed: Light
 Viva Extra Extended: Bold

Though I'd certainly _like_ to see fontconfig support stretch.

A lot of windows software falls into the category of thinking
that fonts come in only 4 styles - Regular Bold/Italic/Bold Italic,
which leads to a categorization that is even more split up
Sanvito becomes two families "Sanvito Light", "Sanvito Roman".

The README in the Adobe package indicates that that last 
categorization (Sanvito split) is actually how the fonts appear on 
Windows. But I'd hope we can do better than that.

An interesting question is how Adobe is encoding its font
names in OpenType files, since Type1 is a (slowly) dying format.
Adobe's  OpenType fonts aren't cheap though, so I'm not that
inclined to buy a couple just to find out.
Comment 7 Owen Taylor 2002-12-06 23:27:22 UTC
Not a 1.2.0 issue; will require fontconfig work.
Comment 8 Keith Packard 2003-05-05 00:59:37 UTC
fontconfig now exposes 'width' to allow applications to select fonts
based on stretch.  Other varients remain visible only in the named
style field.  Fontconfig prefers to match on the style names, so pango
could expose both the parametric attributes as well as the explicit
names so that applications could select among styles which aren't
currently parameterized.
Comment 9 Owen Taylor 2003-11-17 23:02:10 UTC
I want to keep the idea that Pango faces are distinguishable
among the CSS axes. If fontconfig isn't going to support this,
we'll probably have to do this with nasty hacks at the Pango
level.

Yes, it would be possible to add a style field to 
PangoFontDescription that overrode the other fields, that causes
all sorts of uncleanliness. E.g., pango_font_face_describe()
is going to give you a face with a "style" field so you
can't describe then modify the weight of the returned font
description.

Comment 10 Owen Taylor 2004-02-21 18:24:18 UTC
Major amount of work here to present the right model. The stretch
part is bug 131561.
Comment 11 Owen Taylor 2004-07-12 14:18:32 UTC
*** Bug 147372 has been marked as a duplicate of this bug. ***
Comment 12 Ross Burton 2005-02-08 18:21:10 UTC
I have a font (ITC Eras) which has the following styles: Light, Demi, Ultra,
Medium, Book, and Bold.  Pango however shows Light correctly but maps all of the
others to glyphs from Ultra.

Obviously this makes the font pretty much useless, how much effort would it be
to add style name matching?
Comment 13 Ross Burton 2005-02-08 18:51:42 UTC
Right, with fontconfig + pango from CVS, things are looking better.

$ fc-list -v "ITC Eras" family file weight
/home/users/ross/.fonts/Russels/ItcEras-Light.pfa: ITC Eras:weight=50
/home/users/ross/.fonts/Russels/ItcEras-Demi.pfa: ITC Eras:weight=180
/home/users/ross/.fonts/Russels/ItcEras-Medium.pfa: ITC Eras:weight=100
/home/users/ross/.fonts/Russels/ItcEras-Bold.pfa: ITC Eras:weight=200
/home/users/ross/.fonts/Russels/ItcEras-Book.pfa: ITC Eras:weight=75
/home/users/ross/.fonts/Russels/ItcEras-Ultra.pfa: ITC Eras:weight=205

FontConfig can tell the fonts apart by weight.  However, ITC Eras Medium and ITC
Eras Book are rendered using the same glyphs by Pango.
Comment 14 Owen Taylor 2005-03-07 22:01:47 UTC
*** Bug 169314 has been marked as a duplicate of this bug. ***
Comment 15 Patrick Lam 2006-03-18 20:26:59 UTC
fontconfig style names now mismatch the pango-synthesized names coming from the weight property.  See fontconfig bug 6255 (https://bugs.freedesktop.org/show_bug.cgi?id=6255).
Comment 16 Jeff Waugh 2008-03-02 01:53:25 UTC
Here's a similarly problematic font -- a full set of Meta (type1), which includes Caps, Expert, Lf (lining figures), etc. There are 59 styles listed here, but very few consecutive display changes as you scroll down the style list in the font selector (ie. they're mostly ignored, mapped to one style).

$ fc-list -v "Meta" style weight width slant
:style=Book Expert:slant=0:weight=80:width=100
:style=Bold Caps Italic:slant=100:weight=80:width=100
:style=Bold Roman:slant=0:weight=80:width=100
:style=Bold Caps:slant=0:weight=80:width=100
:style=Black Lf Caps:slant=0:weight=80:width=100
:style=Bold Lf Roman:slant=0:weight=80:width=100
:style=Medium Lf Caps:slant=0:weight=80:width=100
:style=Book Italic:slant=100:weight=80:width=100
:style=Normal Lf Roman:slant=0:weight=80:width=100
:style=Normal Caps Exp Italic:slant=100:weight=80:width=100
:style=Book Caps Exp Italic:slant=100:weight=80:width=100
:style=Black Caps:slant=0:weight=80:width=100
:style=Book Caps:slant=0:weight=80:width=100
:style=Black Expert Italic:slant=100:weight=80:width=100
:style=Normal Expert Italic:slant=100:weight=80:width=100
:style=Medium Lf Roman:slant=0:weight=80:width=100
:style=Medium Caps Italic:slant=100:weight=80:width=100
:style=Black Lf Caps Italic:slant=100:weight=80:width=100
:style=Book Caps Exp:slant=0:weight=80:width=100
:style=Medium Caps Exp Italic:slant=100:weight=80:width=100
:style=Black Caps Italic:slant=100:weight=80:width=100
:style=Normal Expert:slant=0:weight=80:width=100
:style=Normal Lf Caps:slant=0:weight=80:width=100
:style=Normal Lf Italic:slant=100:weight=80:width=100
:style=Normal Italic:slant=100:weight=80:width=100
:style=Book Lf Roman:slant=0:weight=80:width=100
:style=Black Roman:slant=0:weight=80:width=100
:style=Bold Lf Caps Italic:slant=100:weight=80:width=100
:style=Normal Caps Italic:slant=100:weight=80:width=100
:style=Bold Expert:slant=0:weight=80:width=100
:style=Book Roman:slant=0:weight=80:width=100
:style=Normal Roman:slant=0:weight=80:width=100
:style=Normal Caps:slant=0:weight=80:width=100
:style=Book Lf Italic:slant=100:weight=80:width=100
:style=Bold Expert Italic:slant=100:weight=80:width=100
:style=Bold Italic:slant=100:weight=80:width=100
:style=Black Italic:slant=100:weight=80:width=100
:style=Medium Expert Italic:slant=100:weight=80:width=100
:style=Book Lf Caps Italic:slant=100:weight=80:width=100
:style=Black Caps Exp:slant=0:weight=80:width=100
:style=Medium Lf Italic:slant=100:weight=80:width=100
:style=Black Expert:slant=0:weight=80:width=100
:style=Black Lf Italic:slant=100:weight=80:width=100
:style=Medium Caps Exp:slant=0:weight=80:width=100
:style=Medium Italic:slant=100:weight=80:width=100
:style=Medium Expert:slant=0:weight=80:width=100
:style=Book Lf Caps:slant=0:weight=80:width=100
:style=Bold Lf Caps:slant=0:weight=80:width=100
:style=Bold Caps Exp Italic:slant=100:weight=80:width=100
:style=Medium Roman:slant=0:weight=80:width=100
:style=Bold Lf Italic:slant=100:weight=80:width=100
:style=Medium Lf Caps Italic:slant=100:weight=80:width=100
:style=Normal Caps Exp:slant=0:weight=80:width=100
:style=Black Caps Exp Italic:slant=100:weight=80:width=100
:style=Black Lf Roman:slant=0:weight=80:width=100
:style=Bold Caps Exp:slant=0:weight=80:width=100
:style=Book Expert Italic:slant=100:weight=80:width=100
:style=Book Caps Italic:slant=100:weight=80:width=100
:style=Medium Caps:slant=0:weight=80:width=100
Comment 17 Tomáš Znamenáček 2008-05-28 14:05:35 UTC
Having more than the four traditional styles is a feature described in the OpenType specification, see http://www.microsoft.com/OpenType/OTSpec/name.htm:

“For historical reasons, font families have contained a maximum of four styles, but font designers may group more than four fonts to a single family. The Preferred Family allows font designers to include the preferred family grouping which contains more than four fonts. This ID is only present if it is different from ID 1.”

Many fonts use this feature.
Comment 18 Michael Natterer 2016-05-02 13:21:25 UTC
*** Bug 760686 has been marked as a duplicate of this bug. ***
Comment 19 Nicolas Mailhot 2016-05-02 18:44:38 UTC
This Microsoft Whitepaper analyses the constrains that need to be applied to font styles for them to be usable in apps:
http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-components-postattachments/00-02-24-90-36/WPF-Font-Selection-Model.pdf

Any font style that fits the WWS rules documented there absolutely needs to be handled by GTK font dialogs (not only n b i bi)

Anything else is broken, but there are lots of broken legacy stuff out there. The graceful way to deal with it is to repair font/style name using the kind of heuristics MS suggested and implemented in WPF, but that needs to happen lower in the stack (probably at the fontconfig level)
Comment 20 Todd Showalter 2016-05-02 18:56:53 UTC
The issue I'm having (which is the duplicate just above) is with multiple fonts, but the particular trigger for me was with a font that has four "styles", that amount to two separate settings.  One is whether the font looks pixellated or smoothed ("raw" vs. "render") and the other is whether the font has lowered numerals ("osn").  That font, Telegrama, is attached to 760686.

It's decorative, so it doesn't really fit into the normal/bold/italic framework; none of the variants differ particularly in weight or slant.  They do differ in appearance significantly, but they're also clearly of the same immediate family.
Comment 21 Nicolas Mailhot 2016-05-02 19:18:51 UTC
(In reply to Todd Showalter from comment #20)

> It's decorative, so it doesn't really fit into the normal/bold/italic
> framework; none of the variants differ particularly in weight or slant.

Then it needs to be treated as X different font families, as the variants do not fit in the CSS WWS model and will only trip applications if unified.
Comment 22 GNOME Infrastructure Team 2018-05-22 12:00:47 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/2.