Fonts weight variants selection

[Denis Moyogo Jacquerye]

Inkscape's font selector displays the right fonts

Steps:
* install the snapshot of DejaVu with DejaVu Sans
ExtraLight:
http://dejavu.sourceforge.net/wiki/index.php/Snapshots
* type some text in Inkscape 0.43
* open the font selection tool

Expected behaviour:
* each variant should be displayed in the preview
accordingly
* if applied, the font variant should be used by the
text object

Current behaviour:
* DejaVu Sans BoldOblique displays what Sans Book
displays in the preview and with the text object (see
following cases)

* with the ExtraLight font named ExtraLight:
  DejaVu Sans Book displays ExtraLight with the text
object but correctly in the preview
  DejaVu Sans ExtraLigth displays Sans Book in the
preview but correctly with the text object

* changing the name of DejaVu ExtraLight to DejaVu
Light in the source and producing new ttf file:
  DejaVu Sans Book displays ExtraLight all the time
(both preview and with text object)

* Applied font selection to a text object is not
remembered (ExtraLight, Book and BoldOblique return to
Book)

[Denis Moyogo Jacquerye (moyogo)]

The same problem occurs with Serif Book and Serif
BoldOblique, as well as Sans Mono Book and Sans Mono
BoldOlblique.

BoldOblique is displayed and remembered as Book.

[Denis Moyogo Jacquerye (moyogo)]

A very similar behaviour occurs with Yanone Kaffeesatz:
http://www.yanone.de/schriftgestaltung/kaffeesatz/

[Denis Moyogo Jacquerye (moyogo)]

Dealing with DejaVu Sans Bold Oblique can be dealt with on
the font side by setting the Style name to "Bold Oblique"
instead of the default PS "BoldOblique" that Inkscape
doesn't understand.

I made a few sample fonts with different weights and styles:
http://home.sus.mcgill.ca/~moyogo/fonts/test/
They should all have different weights and only Contour
should be different. Right now Inkscape is mixing them up.
No donut for Inkscape :P

[Bug Importer (bug-importer)]

This bug is release-critical, it should be definitely
finished before 0.44.

[Bryce Harrington (bryce)]

The canvas and font selector use two very separate
mechanisms for rendering fonts. This is not likely to be a
simple bug to fix.

If this is release-critical, wouldn't this need to be scored
a 9 instead of a 6?

Also, cyreve is listed as the owner - cyreve, are you
actively working on this one?

Bryce

[Bryce Harrington (bryce)]

Bumping up to 9, since it was described as release critical.

[Bug Importer (bug-importer)]

Is there a way to bypass the bug? I really-really-really
need to use Lucida Sans Demibold, but it is impossible to
apply it in the font selection dialog.

[Denis Moyogo Jacquerye (moyogo)]

Inkscape should not use the Style tag of the font for
anything but for what name to use for the user interface.
The backend should use the stretch/width and the weight
information to differentiate between the fonts. Style can be
anything, from standard names to totally arbitrary ones,
weights are a finite set and stretch width too.

For Lucida Sans Demibold you could rename the font to one
style that Inkscape currently support. Fontforge can do that
but I doubt this procedure is legal.

[Bug Importer (bug-importer)]

Could someone please outline the steps for renaming a font
to a style supported by Inkscape in Fontforge? Is it
possible to install the font without restarting X?

[Denis Moyogo Jacquerye (moyogo)]

Changing the font style:
* Open the ttf file
* Element -> Font info,
* Select the tab: TTF Names
* Click on the Styles (SubFamily) value and set to desired
style name

Inkscape only recognizes the following style names:
Regular, Roman, Normal, Plain, Medium, Book, Italic,
Oblique, Slanted, Bold, Caps. Any thing else will mess
things up.

[Denis Moyogo Jacquerye (moyogo)]

By the way, the sample test fonts also include some fonts
that just vary in stretch.
So Jaja Condensed and the likes should be in the "Jaja" font
family and should just be displayed as different Styles.
http://home.sus.mcgill.ca/~moyogo/fonts/test/, the CSS zip
files or the All-OTF zip file contain them.

nobody: You can install a font through Gnome's
System->Preferences->Font->Details->Font folder or by
opening the location "fonts://" in the file browser. In KDE
you can go to the kontrol center. These will take care of
the new fonts and you'll just need to restart Inkscape.

[Bug Importer (bug-importer)]

I'm using XFCE4 in Ubuntu, so neither the Gnome nor KDE way
work for me. I think fonts should be installed by copying
them to /usr/share/fonts/truetype and updating font cache
with fc-cache. I'm not sure how to tell X that fonts have
changed though...

[Bug Importer (bug-importer)]

Is somebody working on this?

[Bryce Harrington (bryce)]

Originator: NO

Postponing for 0.45 due to lack of action on this bug.

[dcberg (david-sipsolutions)]

Originator: NO

Hmm, seems like I should have put some action on this bug ;)
It's bugging me again right now with Yanone Kaffeesatz. The problem has
changed, Inkscape correctly displays, what you can select, but I got a list
of

Regular
Regular
Regular
Bold

instead of

Thin
Light
Regular
Bold

Please fix. It's something you stumble across every now and then and in
that moment really hate it and then forget about for a long while again.
Bulia once explained to me, that he cared more about the styles actually
supported by SVG, but since one doesn't have to use bold and italic tags
but could just use another font name, I don't see this point. For
professional and semi-professional designing, having the right fonts is
most crucial.

[Peter Lewerin (vermeil-deactivatedaccount)]

I'm confirming this in accordance with <URL http://wiki.inkscape.org/wiki/index.php/BugTriageProjects>.

[momo (momo33-operamail)]

The font selection system seems to classify all fonts roman/italics normal/bold. This might work with some fonts, but fails with many serious font families. Inkscape is becoming a very serious drawing program, and should be able to use extensive font families. Please drop the bold and italic buttons, and make a selection tool (drop-down list?) that provides all font shapes.

[nemoinis (nemoinis)]

I'm having the same problem with Exotic350 Light & Demibold, and many other fonts. Fudging the font style with FontForge isn't a portable option and is very embarrasing. The words "crucial" and "critical" have been used already about this bug. I completely agree.

[JiHO (jiho)]

On OS X also many variants are ignored while they exist in the fonts file, so I made this bug all-platforms. In addition to not supporting exotic variants (like extra light, black etc.), simple variants show up as available but applying them has no effect, or turns the text in the default "Sans" font.
Example of some fonts which come with every OS X system (I think):
- American Typewriter: no variant work except italics
- Andale Mono : no Bold
- Apple Chancery : no Bold
- Baskerville: no variant, the variant recognized as normal is in fact Bold Italic
- Cochin: no variants
...
And this was only until letter C for those fonts that worked. These are all fonts in the dfont format, which is just a packaging around TTF files.

[JiHO (jiho)]

Following on my own comment. Updating the libraries Inkscape uses seems to fix many of the issues on OS X. Certain fonts however are still problematic in that they propose a Bold variant which does not exist. Such fonts are for example:
Baskerville Old Face -> only a regular variant but proposed in italics (work), bold (does not work) and bold italics (displayed as italics)
Playbill -> idem

[Bryce Harrington (bryce)]

Dropping cyreve as assignee since I've not seen him in a while. We need a volunteer to take on implementation of a fix for this issue. I've increased the priority to critical.

If someone can take ownership and be the assignee, it would also be possible to milestone it for the 0.46 release, however time is short to get a fix in so this would need to happen very soon.

[JiHO (jiho)]

Just to complete my comments, the version of Pango used on OS X and that seem to solve most of the issues is 1.19.3 and rendering is either by Freetype 2.3.5 or Cairo 1.5.8. In the meantime X and fontconfig also got updated and improved regarding OS X font formats but I think that's something pretty OS X specific and the version of X is still quite lagging behind what's available on linux anyway (don't know about windows).

Using these libraries, the original problem reported with Deja Vu is gone: extralight, bold oblique, book (=normal in Inkscape), all work perfectly.

The issues that remain are:

- Inkscape proposes bold and italic variants when they do not exist in the font. The italic variant is correctly faked by using an oblique version of the regular font. The bold variant usually does not work and should not be proposed. This is true with ttf, dfont and ttf suitcase formats. I don't have an otf font with only a regular version (they all have bold variants) so I can't really test this but my gut feeling is that this is something general, not font-format specific.

- Inkscape does not see all the variants of advanced, professional fonts (mostly otf in my case). It makes a good work detecting many of them (extralight, light, semi-bold) but does not detect more exotic things (capitals, subhead, display). It think a conscious choice was made to support only what could be expressed in CSS syntax so this part of the bug could be invalid regarding Inkscape (it is just a limitation of SVG). It would be nice if Gail or someone could give precisions or pointers into the mailing list archive.

[Gail (gbanaszk)]

Regarding JiHO's comments above:

- This sounds like an issue that should be looked into. There are two possibilities: First, we of course may be doing something wrong on the Inkscape side. Second, it is possible that Pango is messing up somehow. A lot of what we do relies heavily on Pango, so it may be that Pango inocrrectly thinks the bold faces exist. I have not spent a lot of time with the code lately, but I believe we do some extra checking as well, so I'm not sure where this problem is arising off hand.

- You are pretty much bang on for this one. I have added a new CSS attribute in the Inkscape namespace to try and get around this problem, but as mentioned above, we still rely very much on Pango. The next step in this process would be to either ditch Pango for font management (yeah, not likely), or work on having the Pango devs add support for non-css fonts. Until then we are stuck with basic fonts that Pango understands :( (If there is a GSoC again this year, I would want to look into pursuing this as a possible project).

So in conclusion, I should look into the first problem mentioned. Maybe you can point me to some fonts I can use to demonstrate the problem?

[JiHO (jiho)]

I attached a font which shows the problem and for which it is particularly obvious: Andale Mono is a monospaced font with only a regular variant (so says FontBook at least http://docs.info.apple.com/article.html?artnum=304764) and should probably not be displayed as italics or bold (monospaced font are usually not suited for this).
I'm not sure about the legality of putting it online and will suppress the attachment if a problem arises. Just grab it while it's there.

[Stefan (stefan314)]

I don't think Inkscape is able to do much about this issue.

The root of all problems probably is that pango doesn't use the font's style name to differentiate between the fonts but the weight, width and slant values. If you have fonts where the difference doesn't fit into these attributes, then pango cannot tell them apart. This is probably the case when using e.g. the Pochoir fonts (http://www.yanone.de/typedesign/pochoir/) which have a "Regular" and a "Sprayed" style (as I don't have the fonts I cannot check if the faces really are style linked, but you get the point). This can only be fixed at the pango level.

The second problem is caused by how Fontconfig handles style linked fonts. MS Windows can only handle four styles per family (Regular, Italic, Bold, Bold Italic), so families like e.g. the free "Yanone Kaffeesatz" (http://www.yanone.de/typedesign/kaffeesatz/) have their Regular and Bold weights style linked under a "Regular" family and have extra families for the lighter weights. However, the "preferred family" and "preferred style" are set to the real values so more sophisticated software (i.e. everything that is not MS Windows) is able to correctly style link them. Unfortunately Fontconfig doesn't just use the "preferred" names, but everything it finds and puts the "preferred" names in front of the list. For Kaffeesatz this results in:

Kaffeesatz Light:
  Family: "Yanone Kaffeesatz", "Yanone Kaffeesatz Light"
  Style: "Light", "Regular"
Kaffeesatz Regular:
  Family: "Yanone Kaffeesatz", "Yanone Kaffeesatz Regular"
  Style: "Regular", "Regular"

MS Windows sees the second value and shows them as two different families whith a "Regular" style, Mac OS sees the first value and shows them as one family with "Light" and "Regular" style. Fontconfig sees both, and when a font with Family="Yanone Kaffeesatz" and Style="Regular" is requested, it will find both fonts, because both have "Yanone Kaffeesatz" in the list of family names, and both have "Regular" in the list of style names. So it might happen that "Yanone Kaffeesatz Regular" is requested and "Yanone Kaffeesatz Light" really gets selected. This is a Fontconfig issue, but fixing it is easy. Put the following simple configuration snippet into /etc/fonts/fonts.conf:

<match target="scan">
    <edit name="family"><name>family</name></edit>
    <edit name="style"><name>style</name></edit>
</match>

Or put the attached file into /etc/fonts/conf.d or wherever Fontconfig will find it. Don't forget to run "fc-cache -f". Now Fontconfig discards everything after the first entry in the family and style lists of all fonts, so only the "preferred name" remains. This fixes most font selection issues.

What Inkscape could do is documenting the known font selection limitations and perhaps suggesting something like the above configuration snippet.

[Rastator (slub)]

In the continuity of the issue with fonts,

I have a big problem with some fonts which have not the same size in Inkscape 0.4.6 and in another tools under Windows XP whereas I use the same font with the same size in the both tools...

So it is very difficult to make model of document when the space used by words is not the same in my model under Inkscape and the results in production.

Am I the only one which has this problem or not ??

Thanks in advance

[BenDJ (bendj095124367913213465)]

Hi,

I'm seeing the same problem with Inkscape 0.46+devel r22575 (Nov 12 2009) (built on openSUSE 11.2).

E.g., I've installed only the following GillSans otf variants as system-wide fonts ...

 ls -1 *GillSans*
 GillSans-BoldCondensed.otf
 GillSans-BoldExtraCondensed.otf
 GillSans-BoldItalic.otf
 GillSans-Bold.otf
 GillSans-Condensed.otf
 GillSans-ExtraBoldDisplay.otf
 GillSans-ExtraBold.otf
 GillSans-Italic.otf
 GillSans-LightItalic.otf
 GillSans-Light.otf
 GillSans-LightShadowed.otf
 GillSans.otf
 GillSans-Shadowed.otf
 GillSans-UltraBoldCondensed.otf
 GillSans-UltraBold.otf

In both FontMatrix & Scribus (no pango?) I see these fonts as installed/active, and they're all usable.

In Inkscape, however, I see

 Font family: Gill Sans
  Style:
   Normal
   Condensed
   Light
   Italic
   Light Italic
   Bold
   Bold Condensed
   Bold Extra-Condensed
   Ultra-Bold
   Ultra-Bold Condensed
   Bold Italic
 Font Family: Gill Sans Light
  Style:
   Light
   Light Italic
   Bold
   Bold Italic

but NO trace of, e.g., the

 GillSans-ExtraBoldDisplay.otf
 GillSans-ExtraBold.otf

variants. Apart from working in/on Scribus, these are all Adobe .otf fonts that have been used on OSX with no apparent issues in any app.

I'm certainly no expert, but it seems to me that crafting workaround snippets is not the way to go for dealing with 'industry standard' fonts. Wouldn't it make more sense to do what Scribus does (part of the Libre Graphics project, like Inkscape, no?) or use _this_ discussion to get upstream (pango? fontconfig? whatever?) to make required fixes?

Thanks,

BenDJ

[BenDJ (bendj095124367913213465)]

I though I could link to other bugs ... my mistake.

Anyway, this but submitted by Ankh-Users

  "font variants information ignored"
   https://bugs.launchpad.net/inkscape/+bug/165521

seems to be related to the same problem discussed here.

BenDJ

[Lenin (gagarin)]

likewise with M+ fonts

[su_v (suv-lp)]

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).

[Vladimir Savic (vladimir-firefly-savic)]

I believe this report is, at least by subject, the right place to add comment.
We are seriosly missing font variant dropdown selector added to text toolbar. Right now you can aproach to exotic variants like Extra, Thin, Outline of some typeface only by dedicated dialog. It's far from being productive workflow. Especially problematic is change of typeface on already formatted text. If you use that dedicated dialog you'll have to have some variant selected and on typeface change you'll lose all bold, italics etc.

[moomooranch (amagawa)]

What worked for me was going into FontForge and changing the "Preferred Family" and "Preferred Styles" fields in Element > Font Info > TTF Names, to match the "Family" and "Styles (SubFamily)" fields on the same tab.

Inkscape is trying to be smart by grouping the fonts by preferred families and styles, but fails, so we have to prevent it from trying to group them and instead list the different styles as different fonts.

[Kris (kris-degussem)]

It seems to me that the issue or some subissues are dealt with? For exdample, comment 31: there is a font variant selector in the text toolbar (though it's content does not seem to be emptied when there is no "font variant"). Can some affected user check whether the reported problem is still an issue with a recent development version?

[MOW (wolter)]

I still see fscked up "bold" behavior in 0.48+devel r11359, and considering that 0.48.2-1 is still featured as the stable version, it will probably still be around for some time ...

I noticed that with some fonts, Inkscape doesn't show any changes on screen when switching bold around, but it _does_ affect printing and exports.

(Also interesting that the two pdf exports look quite different; in the variant where text is not exported as path apparently the bold gets dropped from the two "i" in the bottom line; but that's another bug.)

Right now I'm downloading r11870 and will retry with that.

Attached: two PDFs and one SVG, all exported by "Kopie speichern unter", no other changes in between.

[MOW (wolter)]

Yep, bug is still there (r11870). Just that "bold" is now not a button but a dropdown.

(PDF export bug is also still there. Suggestions where to report this welcome.)

[Tavmjong Bah (tavmjong-free)]

Work-around in comment #25 doesn't appear to still work.

[Marek (abulak)]

with new font selection I cannot select font weights apart from default (usually medium) and Bold;

Choosing semi-bold, heavy, light... gives You normal/medium weight.

these however work in Text Properties Dialog (You can see the difference), but are not applied to the font in the document.

I can choose different families (italic, oblique, etc)

actually changes are forgotten when You change selection (only family is remembered).

[.:Cyb3rGlitch:. (cyber-glitch)]

Workaround: http://graphicdesign.stackexchange.com/questions/16873/dejavu-sans-condensed-not-showing-up-in-inkscape-despite-installed/17582#17582

[cesasol (cesasol)]

Similar problem with Museo, and Museo Sans. The weight should be 100, 300, 500, 700 and 900. But is showing as light, heavy, medium and bold.
Another problem, and very catastrofic is the wight of some fonts are not recognized as it should, like museo slab, and maven pro light with similar weights as museo ar not recognized at all and shows as regular and bold when they have betwen 5 and 10 weights.

[marc des vosges (bony-marc)]

Hi, (For french scroll now)

I have same problem.

For around the bug, I copy the name of font from LibreOffice Writer (or an other program), and I paste in the Inkscape bar font.
But, the export into PDF is not possible...

Merci

------------------------------------

Salut,

J'ai le même problème.

Pour le résoudre, je copie le nom de la police depuis un logiciel comme LibreOffice Writer, puis je le colle dans la barre de police d'Inkscape.
Par contre l'export en PDF n'est plus possible...

Merci

[Davide Depau (depau)]

This also happens with the fonts "Ubuntu Condensed" and "Roboto Condensed".

[Tavmjong Bah (tavmjong-free)]

0.91 improved the ability to select different font faces from the same family. Since we rely on CSS styling for face selection there is a limit to what we can support which still leads to some problems (e.g. not being able to distinguish between Museo Sans Rounded 100 and 300 which both map to 'Light'). The text tool bar shows the face name according to CSS. Both the CSS and designer font face name is shown in the Text and Font dialog.

Unless any other problems are found, this bug should be closed.

[su_v (suv-lp)]

Updating bug status based on comment #42.