font variants information ignored

Bug #165521 reported by Ankh-users
124
This bug affects 22 people
Affects Status Importance Assigned to Milestone
Inkscape
Invalid
Medium
bbyak

Bug Description

Inkscape's font dialogue offers a (seemingly random)
subset of available fonts for a given family. For
example, I have bought the Adobe Caslon; this shows up
(in 0.37) as only four fonts, regular / italic / bold /
bold italic, but here is the output of fc-list | grep
-i 'adobe caslon'; of the four fonts chosen by
inkscape, one was small caps or expert, one was swash
italic, so the fonts weren't useable at all.

 lee> fc-list | grep -i 'caslon' | sort
Adobe Caslon:style=Bold
Adobe Caslon:style=Bold Alternate
Adobe Caslon:style=Bold Expert
Adobe Caslon:style=Bold Italic
Adobe Caslon:style=Bold Italic Alternate
Adobe Caslon:style=Bold Italic Expert
Adobe Caslon:style=Bold Oldstyle Figures
Adobe Caslon:style=Italic
Adobe Caslon:style=Italic Alternate
Adobe Caslon:style=Italic Expert
Adobe Caslon:style=ItalicOsF
Adobe Caslon:style=Ornaments
Adobe Caslon:style=Regular
Adobe Caslon:style=Regular Alternate
Adobe Caslon:style=Regular Expert
Adobe Caslon:style=Regular Small Caps & Oldstyle Figures
Adobe Caslon:style=Semibold
Adobe Caslon:style=Semibold Alternate
Adobe Caslon:style=Semibold Expert
Adobe Caslon:style=Semibold Italic
Adobe Caslon:style=Semibold Italic Alternate
Adobe Caslon:style=Semibold Italic Expert
Adobe Caslon:style=SemiboldSC
Adobe Caslon:style=Swash Bold Italic
Adobe Caslon:style=Swash Italic
Adobe Caslon:style=Swash Semibold Italic
CaslonItalicWithSwashes:style=Regular
ITC Caslon 224:style=Black
ITC Caslon 224:style=Black Italic
ITC Caslon 224:style=Bold
ITC Caslon 224:style=Bold Italic
ITC Caslon 224:style=Book
ITC Caslon 224:style=Book Italic
ITC Caslon 224:style=Medium
ITC Caslon 224:style=Medium Italic

Revision history for this message
Luke-hutchison (luke-hutchison) wrote :

I've noticed something related to this -- that if you select
a variant other than Normal, it just defaults back to
Normal. e.g. selecting Times New Roman Italic shows the
italic in the font dialog, but when you apply it, the font
on the canvas reverts to Normal. You have to edit the SVG
directly to get it to display italic on the canvas.

Revision history for this message
Buliabyak-users (buliabyak-users) wrote :

This is being gradually fixed. At least it should display
all fonts within a family in the list. Luke: if you can run
the latest CVS, could you please test the font selection in
the list. It should work now for most (but probably not all)
styles within a family. If it still doesn't work, send me
the names of the fonts where it fails.

Revision history for this message
Luke-hutchison (luke-hutchison) wrote :

Times New Roman Italic now works for me with v0.38.1. I
can't test exhaustively right now however. Thanks!

One question -- are there plans to have mappings of generic
style features to different family names? e.g. pressing
Ctrl-B while editing text applies "Bold", if present, else
"Demi", else "Heavy", else "Thick" etc., and pressing Ctrl-I
applies "Italic", if present, else "Oblique", else "Slanted"
(or whatever the various equivalents or near-equivalents are)?

Revision history for this message
Buliabyak-users (buliabyak-users) wrote :

Yes, font support is much better in 0.38, but I'm not
closing this because it only covers CSS-supported variants,
while styles such as Outline or Alternate will still likely
fail. More work is needed to support arbitrary style names.

As for changing styles by hotkeys, sure, it will be done
when we have a normal text selection implemented (as opposed
to just applying the style to the entire text object).

Revision history for this message
Luke-hutchison (luke-hutchison) wrote :

I was actually not mentioning that with emphasis on hotkeys,
but rather on aliases to styles that are similar: Oblique
and Italic are similar (of course, they are not similar to
real typographers, but they both share a slant
characteristic, and usually a font will not have both variants).

Normally, a wordprocessor will select either Italic or
Oblique intelligently, depending on which families are
available for the font, when Ctrl-I is pressed to italicize
the word -- there is not a separate key for Italic and Oblique.

The same of course goes for having a menu item (rather than
a keyboard shortcut) for Italic, Bold etc., as a quick way
of selecting one of the many possible variant family names
for "slanted text" in the current font.

Am I over-simplifying the problem?

Revision history for this message
Buliabyak-users (buliabyak-users) wrote :

Sure, smart choice among available styles is appropriate for
such a command. E.g. we will probably have "make bolder" and
"make lighter" commands that will navigate through the
available weights, or just switch to bold and back when only
one bold weight is available. These controls will all be put
on the text tool's top panel as well as in shortcuts.

Revision history for this message
Bug Importer (bug-importer) wrote :

I like the idea that if Inkscape is asked (by a user) to
make a font Bold, it tries Bold, then Demibold, etc.
However, I think that this feature would be genercially
useful, so belongs in a different level of infrastructure. I
would think that in Fontconfig would be the best.

Otherwise, each application would be doing this Bold
substitution in its own, incompatible way.

Revision history for this message
Jflemaire (jflemaire) wrote :

I don't have the same font, but hasn't this bug gotten fixed
over time? "Nimubs Sans L" has 8 different variants, all
displaying in the Text and Font selector and working fine in
Inkscape Linux CVS.

Revision history for this message
Dreckkopf-users (dreckkopf-users) wrote :

I can confirm this bug with inkscape 0.43. The Font
"DINSchrift" comes in three flavors "DINSchrift",
"DINSchrift Bold" and "DINSchrift Light". In the font
dialogue inkscape displays only a style option called
"regular". The preview is from "DINSchrift", but the font in
the drawing is rendered as "DINSchrift Light". That's very
confusing. I put a screenshot here:
http://img302.imageshack.us/my.php?image=inkscapescreenshot3bh.png

Revision history for this message
Philbull-users (philbull-users) wrote :

A similar bug has been reported in the Ubuntu Malone bug
tracker:

https://launchpad.net/distros/ubuntu/+source/inkscape/+bug/36876/+index

Thanks

Revision history for this message
Lucychili-users (lucychili-users) wrote :

Fonts variant and cousins:

904962 font variants information ignored ITCCaslon, DINSchrift

998230 Alternate fonts can look bad Poetica, variants:
ampersands, chancery1, smallcaps

1288935 bold italic variant is wrong in a Type1 font Garamond

1448618 Fonts weight variants selection DejaVu, Yanone
Kaffeesatz, Serif Book, Sans Mono

1456620 Certain fonts dont work croco issue invalid
filenames as C identifiers

1327094 css font-family, not properly escaped quotes
around space or !, issue rel variants.

bbyak (buliabyak)
Changed in inkscape:
status: New → Confirmed
Ryan Lerch (ryanlerch)
Changed in inkscape:
assignee: buliabyak-users → buliabyak
Revision history for this message
rndmerle (rndmerle) wrote :

I have the same problem with Inkscape 0.46 (Oct 24 2008) : Some font variants are not shown in the fonts selector.

I join 2 font sets :
+ Day Roman : a ttf font. Under Fontmatrix there is the "Day Roman" family with "Regular" and "Expert" variants. Under Inkscape there is only "Normal" and the faked Italic/Bold
+ Existence : a otf font but splited into several files. Under Fontmatrix there is the "Existence" family with "Light", "Stencil Light" and "Unicase Light". Under Inkscape there is only "Light" and the faked Italic/Bold

Regards.

su_v (suv-lp)
tags: added: fonts
removed: other
Revision history for this message
su_v (suv-lp) wrote :

list updated from sf.net to LP bug tracker (comment #11):

Bug #165521 “font variants information ignored” (Confirmed)
Bug #165872 “Alternate fonts can look bad” (CLOSED as out of date)
Bug #166935 “bold italic variant is wrong in a Type1 font” (Duplicate of #165521)
Bug #167353 “Fonts weight variants selection” (Confirmed)
Bug #167377 “Certain fonts dont work” (Confirmed)
Bug #167041 “css font-family, not properly escaped” (Fix Released)

Revision history for this message
su_v (suv-lp) wrote :

There have been several font weights added to be handled properly in Inkscape, as part of the refactored text tool:
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48#Text_Tool>

Additional details:

Some of the relevant commits by Tavmjong Bah are
9332 Added missing Pango Weights
9334 First step in fixing the changing of font faces (must also update toolbox.cpp).
         Expands use of pango_font_decription_better_match()
9340 Second step in fixing changing of font faces.
9348 Added/Fixed Pango font weights.
9365 Converted text toolbar to GTK toolbar.
... and some minor fixes in later revisions AFAICT.

(copied from an earlier comment in related bug #362810).

Revision history for this message
JBR (jbrgraphics) wrote :

The "Text and Font" dialog is currently displaying incorrect "Style" information (v 0.48.2 r9819 on Arch Linux). The attached fonts, purchased from a professional font foundry, have the available styles "100", "300", "500", 700", "900", "1000". Instead, styles named "Normal", "Heavy", "Light", "Italic", "Bold", "Semi-Bold", and "Bold Italic" are listed. Thus, access to at least one of the styles is prevented by Inkscape. Furthermore, the italic variants are 'forced' and not intended by the font's designer.

The appropriate fix would be to list the styles "100", "300", "500", 700", "900", "1000" as intended by the font's designer. Italicized variants should not be included in the "Styles" list so that the user understands that the font was not intended by the designer to be italicized.

For comparison, the gtk/gnome application "font-manager" http://code.google.com/p/font-manager/ displays the appropriate styles, though it also incorrectly lists the unintended variants "Italic" and "Bold Italic".

Revision history for this message
Gatonegro (gatonegro) wrote :

I confirm JBR's issues -- I'm having exactly the same problem. This is somewhat of a showstopper, since playing with font-weights is a great resource in design.

Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

We are limited by what Pango and CSS do.

CSS does not define a weight of 1000. I don't see a weight of 1000 listed in the CSS3 Fonts Module working draft. If you think that this is important then you should send a comment to the CSS working group. There will be a public comment period and all comments must be responded to before the spec can be finalized, but it would be best to contact them earlier.

See: http://www.w3.org/TR/css3-fonts/

Pango does include weight of 1000.

As for the "synthetic" fonts (generated by Pango), I plan on turning those off.

Revision history for this message
JBR (jbrgraphics) wrote :

Re: Comment #17

"As for the "synthetic" fonts (generated by Pango), I plan on turning those off."

This will be very much appreciated!

"CSS does not define a weight of 1000."

I'm unclear as to how this affects the issue I reported in comment #15. Regarding the font files I attached to that comment, I doubt that the font designer's choice of numeric style names, including the name "1000", directly relate to the numeric CSS font weights listed at http://www.w3.org/TR/css3-fonts/ . As the font was designed with six weights, and CSS defines nine weights, it seems to me that the font's six styles could be mapped to CSS weights. **However, within the Inkscape UI, the style names defined by the font's designer should be displayed, and not any other names of weights as defined in CSS or Pango.**

To quote the CSS working draft: "The CSS font selection mechanism merely provides a way to determine the “closest” substitute when substitution is necessary."

Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

I have had another look at this bug. There are a log of issues. Looking at Museo Sans Rounded with FontForge and some print statements inside Inkscape one finds:

Name PS Weight TTF Style Pango Pango Weight
100 Extra Light 100 300 Light
300 Light 300 300 Light
500 Normal 500 400 Normal
700 Semi Bold 700 600 Semi-Bold
900 Bold 900 700 Bold
1000 Black 1000 900 Heavy

Pango is using the PS Weight to determine the Pango/CSS weight. From looking at the Pango code, it seems that Extra Light should have a CSS value of 200. There appears to be a bug parsing the value in Pango. Inkscape keeps track of fonts using the Pango "Font Description" (PFD) which is based on CSS font properties. The duplication of weight 300 is the reason the Inkscape GUI shows only five weights when in fact their are six. This needs to be fixed in Pango.

Pango does have a function that returns a unique style name "suitable for displaying to users" for each face in a font family. In the case of Museo Sans Rounded the values are the same as in the 'Name' column above. Unfortunately, this information is not easily accessible inside Inkscape. It will take some hacking to make it available in our GUI (the argument to the function is a 'face' which is a temporary object that exists only when building the font map).

The long term solution has two parts. The first part is we should support CSS @font-face rules. With this, one can directly link a font resource (e.g. a font file) to a style. Then there is no guessing about which font face will be used. No substitution will be necessary. This will require a lot of work as it is not apparent (at least to me) on how to get Pango to support "User" fonts. The second part is to support the CSS Font Module Level 3 'font-variant' property. This allows choosing which glyphs to use out of a single font face. For example, instead of needing a separate font file for small-caps, the small-caps are in the same file as the regular glyphs. This is the current trend with font packaging and is the direction the HTML/CSS is heading.

As a final comment. Firefox, at least on Linux, uses Pango as a backend. It has the same bug with Museo Sans Rounded as Inkscape (showing five weight variants rather than six). But this is better than Chrome and Opera, which only display two weights.

Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

The designer face name is now shown in the Text and Font dialog along with the CSS face name (r13414).

Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

Actually, it appears Pango is using the OS/2 weight (Fontforge: Element->Font Info...->OS/2->Misc->Weight Class). Here are the values:

  Museo Sans Rounded 100: 250
  Museo Sans Rounded 300: 300 Light
  Museo Sans Rounded 500: 400 Book
  Museo Sans Rounded 700: 600 Demibold
  Museo Sans Rounded 900: 700 Bold
  Mueso Sans Rounded 1000: 900 Black

250 Is mapped to Light, preventing 300 from being added. Changing 250 to 200 allows Inkscape to see both.

Revision history for this message
Nutchanon Wetchasit (nutchanon-wetchasit) wrote :

Bug #1612945 (which also affects current Inkscape 0.92.1) seems to be related to this problem; resulting in incorrect font weight in SVG file that tries to use the affected font family.

Revision history for this message
Thor Michael Støre (thormichael) wrote :

Ran into what seems to be this bug just now. I'm running 0.91 on OS X. I have four "Futura Std" styles installed: light, medium, heavy and bold. They all show up in Font Book and LibreOffice just fine. In Inkscape 0.91 only light, medium and bold are available. I also note that for the latter of the four the "Text and Font" menu shows "CSS: Bold, Face: Heavy", though I don't know if that means it is confusing the two. It is the bold variant I'm seeing.

The fonts in question are:
http://fontsgeek.com/fonts/Futura-Std-Bold
http://fontsgeek.com/fonts/Futura-Std-Heavy

Revision history for this message
Christoph Ra (chraab) wrote :

I have problem as well. Since it's been suggested that this is a Pango issue, I can offer two points of support for that:

- It doesn't occur with Scribus, which isn't linked against Pango. Inkscape is (version 1.36.3 for me).
- It has actually been reported as a bug there as early as 2002:
https://bugzilla.gnome.org/show_bug.cgi?id=95043
https://bugzilla.gnome.org/show_bug.cgi?id=490609

That's not to say that Inkscape might not be able to work around it, but if any interested programmer is reading, maybe that library is a better place to start. Actually, I'd be willing to chip in for a bug bounty. Does someone know a good place to do that? One of the big projects, or bring it up on one of the Inkscape dev's Patreon sites?

tags: added: bug-migration
Changed in inkscape:
status: Confirmed → Invalid
Revision history for this message
grey tomorrow (gtomorrow) wrote :

Closing because INVALID: fixed in Inkscape 1.0rc1.

Tested on Inkscape 1.0rc1 (09960d6, 2020-04-09), macOS 10.13.6 (17G12034).

Original report: cannot corroborate as I do not have the Adobe fonts listed. Tested with other typeface families with more than four faces (e.g, Archivo, Chivo, etc.), all typeface families are displayed and utilized correctly by Inkscape.

Comment #1: Inkscape displays and utilizes correctly all four typefaces in Times New Roman family (Regular, Italic, Bold, Bold Italic).

Comment #15 et al: I can confirm Tavmjong Bah's findings in Comment #21 that Museo Sans Rounded 100 (installed only for testing purposes) does have its OS/2 Weight Class mistakenly set at 250. When the font is regenerated with the correect OS/2 weight class (100 Thin), it appears in the Inkscape font lists as "Thin", which corrisponds to my testing with pango-view (100=Thin, 300=Light, 500=Regular, 700=Semi-Bold, 900=Bold, 1000=Ultra-Bold). (Thanks to Patrick Storz)

Comment #25: problem resolved. Inkscape displays and utilizes correctly the six typefaces in macOS's Futura.ttc (Medium, Medium Italic, Bold, Bold Italic, Condensed Medium, Condensed ExtraBold)

If you feel this issue has been unjustly closed, please feel free to open a new issue at https://inkscape.org/report . Thank you.

Closed by: https://gitlab.com/greytomorrow

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.