Libreoffice chooses incorrect font weight

Bug #1054204 reported by Alan Pope 🍺🐧🐱 🦄
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Fontconfig
Fix Released
Wishlist
Ubuntu Font Family
Invalid
Undecided
Unassigned
fontconfig (Ubuntu)
Fix Released
High
Unassigned
ubuntu-font-family-sources (Ubuntu)
Fix Released
Undecided
Unassigned
Quantal
Fix Released
Undecided
Unassigned
Raring
Fix Released
High
Unassigned

Bug Description

How to fix the problem:

See comments on wrong "Ubuntu Light" font family being specified in the information of Ubuntu-M.ttf.

You can fix the problem manually by installing fontforge program, going to Open dialog, navigating in it to /usr/share/fonts/truetype/ubuntu-font-family/ and opening Ubuntu-M.ttf. In Element -> Font Info, you can fix the family on the first page, and then export the font with File -> Generate Fonts, selecting the type "TrueType". Save to somewhere in your home folder first, accept the warnings, then in a terminal window / command line type:

sudo mv Ubuntu-M.ttf /usr/share/fonts/truetype/ubuntu-font-family
sudo dpkg-reconfigure fontconfig

Attached to this bug report is also a branch of the Ubuntu packaging that includes this manually modified Ubuntu-M.ttf, since the sources seem not to be editable with free tools.

Original description:

After installing the Ubuntu Font 0.80-0ubuntu3+console from quantal I have the added "Medium" font weight:-

/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-B.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-RI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-MI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-LI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-RI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-M.ttf
/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-BI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-B.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-L.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-C.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-BI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf

If I install this font and choose "Ubuntu Light" in LibreOffice, it actually picks the "Medium" font weight. If I remove the medium font weight files and restart LibreOffice it chooses the right weight again. It seems related to bug 744812.

Screenshots show the issue.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libreoffice-writer 1:3.6.1~rc2-1ubuntu5
ProcVersionSignature: Ubuntu 3.5.0-15.22-generic 3.5.4
Uname: Linux 3.5.0-15-generic x86_64
ApportVersion: 2.5.2-0ubuntu4
Architecture: amd64
Date: Fri Sep 21 17:34:30 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120102)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
In , Paul Sladen (sladen) wrote :

Truetype/Opentype files have various sets of metadata, not all of which can be directly queried/matched via FontConfig.

In particular, both the OpenStep and CSS font-matching schemes require the "PostScript name" as the canonical form of first attempt:

  http://www.w3.org/TR/css3-fonts/#ltfont-face-namegt
  "the unique name used with local() specifies a single font, not an entire font family. Defined in terms of OpenType font data, the Postscript name is found in the font's name table, in the name record with nameID = 6 (see [OPENTYPE] for more details). The Postscript name is the commonly used key for all fonts on OSX and for Postscript CFF fonts under Windows. The full font name (nameID = 4) is used as a unique key for fonts with TrueType glyphs on Windows."

Previously patch(es) were offered by Isaiah Beerbower and Evgeniy Stepanov:

  http://lists.freedesktop.org/archives/fontconfig/2008-June/thread.html#2957
  http://lists.freedesktop.org/archives/fontconfig/attachments/20080605/c063ded6/attachment.diff

but these do not appear to have been replied. A request is made during the conversation to file a bug and attach the files.

Revision history for this message
In , James H. Cloos Jr. (cloos-jhcloos) wrote :

I also posted an RFD patch to cache and match on the postscript name.

It, too, was ignored.

Revision history for this message
In , Paul Sladen (sladen) wrote :

James: do you have a link to your version of the patch too?

Revision history for this message
In , Freedesktop (freedesktop) wrote :

James, feel free to fork fontconfig. I encourage that. If and when distros pick up your tree, I'll hand you the fdo tree. That's what I did to Keith afterall. Don't sound apologetic!

Revision history for this message
In , Freedesktop (freedesktop) wrote :

Note that any patch to add this has to address the interaction between searching by postscript name and family name. Just adding the postscript name to the pattern and putting it in a random place in the matcher is easy. Making sense of how this feature is to be used is something I haven't seen anyone answering so far.

Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) wrote :
Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) wrote :
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Regarding the fonts themselves, I can see that the Ubuntu-M.ttf's "Family Name" says "Ubuntu Light". Fontname and name for humans are Ubuntu-Medium & Ubuntu Medium.

More inconsistencies include that Ubuntu Light has all Fontname / Family name / Name for Humans as Ubuntu-Light or Ubuntu Light, where as the Ubuntu Bold has family name only "Ubuntu".

As the last possibile thing to check is Styles (SubFamily) setting in TTF Names, which is "Bold" for both Ubuntu Medium and Ubuntu Bold, and "Regular" for Ubuntu Light.

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

I set the Family Name for Ubuntu-M.ttf to Ubuntu Medium, which seemed to fix the problem (screenshot attached). Ubuntu Medium now also appeared in LibreOffice's font list as a separate entry.

Changed in libreoffice (Ubuntu Quantal):
status: New → Invalid
Changed in ubuntu-font-family-sources (Ubuntu Quantal):
status: New → Confirmed
Changed in ubuntu-font-family:
status: New → Confirmed
description: updated
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

After all, it apparently is that the bugs do exist in programs/libraries, but font makers mostly have workarounded them. Liberation reportedly has some similar issues.

Changed in libreoffice (Ubuntu Quantal):
status: Invalid → Confirmed
Revision history for this message
Paul Sladen (sladen) wrote :

In broad terms there is the simple metadata (fontname + boolean for italic + boolean for bold); and there is the complex metadata (name, family name, numerical slant, numerical weight, …). Various applications; including FontConfig IIRC makes errornous presumptions when mixing those.

Now, from a UFF PoV, we may have to change the mapping method to cope with certain software like MSIE; but that would none-the-less still leave the handling of "separate" metadatas broken. The only string that is /supposed/ to be globally unique is the Postscript Name; which OpenType and CSS mandate, and which Fontconfig currently junks:

  https://bugs.freedesktop.org/show_bug.cgi?format=multiple&id=38737

Adding that to FontConfig as an available matching spec would at least allow debugging by canonically knowing what you're getting.

Revision history for this message
In , Freedesktop (freedesktop) wrote :

Akira, can you update this bug with your latest plans?

Revision history for this message
In , Akiro (akiro) wrote :

Well, still thinking how to address comment#4 though, the ideas I have so far is:

For cache:
* the change in FcFreeTypeQueryFace(): in case any fonts doesn't have TT_NAME_ID_PS_NAME, generate PS-compliant name from the family name as the printing libraries do.

For match:
* the change in FcNameParse(): we could add some code to guess if the string is more likely to be the family name or PostScript name from the existence of '-', ' ', and '-H', or '-V' as the suffix etc. set it to FC_FAMILY and/or FC_POSTSCRIPT_NAME. in some case, pre-lookup for that name may be a good idea? because it would be easy to write the mathing rules if we are sure either of the values points to the correct value. otherwise one who is responsible to maintain the rule needs to write the complicated (or duplicated) rules to match either of FC_FAMILY or FC_POSTSCRIPT_NAME then. or think about the syntax to achieve the rule like:

  If pat['family'] == 'Courier' or pat['postscript'] == 'Courier' then
    something

* in FcNameParse() or in fcstr.c and fclang.c:

 * any function to guess the language from CMap if any.

 * a special comparison mode or attribute to ignore the suffix string like CMap. or should it be done with the above idea at pre-stage?

There should be more we need to think about, but just to share current idea.

Revision history for this message
In , Paul Sladen (sladen) wrote :

Akira, thanks for the update!

One thought I'd like to add, regarding the synthesis of missing data; is that when it comes to /debugging/ font-related issue, a large percentage of the (invalid) issues relate to sythesis and substitution occuring in FC or the toolkits. It is often the difficulty in seeing past where the sythesis (or simplification) of data is occuring, that hampers the debugging.

Thus, it might arguably be better to cleanly /fail/ if a request is made for a TT_ attribute that doesn't exist (such as TT_NAME_ID_PS_NAME), than to return something that wasn't or isn't there.

Perhaps the printing issue highlighted (where synthesis of missing attributes is needed) could be covered with a helper function of something like ReturnUniqueNameAsPostscript(). Such a function() (or ENUM) could then return the TT_NAME_ID_PS_NAME if it exists, or make something up. But in both cases, without obscuring the ability of an application /that cares/ to uniquely query or get the raw data.

Does that make sense? I'm happy to expand on the above if not.

Revision history for this message
In , Akiro (akiro) wrote :

Well, I know there are some request of additional APIs like FcFontMatch and FcFontSort without the substitution. we should deal with it as a separate bug or RFE IMHO.

Revision history for this message
Björn Michaelsen (bjoern-michaelsen) wrote :

So this seems from reading the comments to be a bug in fontconfig, which could be workarounded in the Ubuntu font. While LibreOffice shows the buggy behaviour, it needs to be fixed in fontconfig or worked around in the Ubuntu fonts. Is that correct?

Revision history for this message
Sebastien Bacher (seb128) wrote :

targetting for release, it has been suggested that it would really be a dissapoinment if that slips and miss Quantal...

Changed in libreoffice (Ubuntu Quantal):
importance: Undecided → High
milestone: none → ubuntu-12.10
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-font-family-sources - 0.80-0ubuntu5

---------------
ubuntu-font-family-sources (0.80-0ubuntu5) quantal; urgency=low

  [ Timo Jyrinki ]
  * Add modified Ubuntu-M.ttf binary (LP: #1054204)
  * Restore installing Ubuntu-M* (LP: #1048600)

  [ Iain Lane ]
  * Modify Ubuntu-MI.ttf in the same way (set "Family Name"), otherwise Ubuntu
    Medium Italic gets selected for Ubuntu Light Italic in LO.
 -- Iain Lane <email address hidden> Sat, 06 Oct 2012 13:20:49 +0100

Changed in ubuntu-font-family-sources (Ubuntu Quantal):
status: Confirmed → Fix Released
Changed in ubuntu-font-family-sources (Ubuntu Quantal):
milestone: none → ubuntu-12.10
Changed in fontconfig (Ubuntu Quantal):
importance: Undecided → High
Revision history for this message
Björn Michaelsen (bjoern-michaelsen) wrote :

Is there anything to do still for LibreOffice for Quantal on this one? It looks fine as is to me. We should recheck in Q+1 as per:

https://bugs.launchpad.net/ubuntu-font-family/+bug/744812/comments/72
https://bugs.launchpad.net/ubuntu-font-family/+bug/744812/comments/73

the situation upstream changed between 3.6 and master (hopefully for the better). Anyway, can I close this one for quantal as wontfix now?

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 1054204] Re: Libreoffice chooses incorrect font weight

If we have LO using Medium as the bold for Ubuntu Light, then we can
close it :)

Changed in fontconfig:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Changed in libreoffice (Ubuntu Quantal):
milestone: ubuntu-12.10 → quantal-updates
Changed in fontconfig (Ubuntu Quantal):
milestone: none → quantal-updates
status: New → Confirmed
Revision history for this message
In , Akiro (akiro) wrote :

http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz38737

This repo contains the initial patch to propose a fix of this issue.
I didn't implement anything about CMap this time. because dealing with it in fontconfig may be overkill. applications who wants to use this feature should knows about it well. they could set the lang into FcPattern instead.

Please test. if there are no problems or concerns, I'll merge it into master.

Thanks,

Changed in fontconfig:
status: Confirmed → In Progress
Revision history for this message
In , Akiro (akiro) wrote :

I'll merge this change into master shortly if there are no objections.

Revision history for this message
In , Akiro (akiro) wrote :

committed.

Changed in fontconfig:
status: In Progress → Fix Released
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Looking at the upstream git log [1] the fontconfig part should be fixed since saucy.

[1] http://cgit.freedesktop.org/fontconfig/commit/?id=b561ff2016ce84eef3c81f16dfb0481be6a13f9b

Changed in fontconfig (Ubuntu):
status: Confirmed → Fix Released
no longer affects: libreoffice (Ubuntu Quantal)
no longer affects: libreoffice (Ubuntu Raring)
no longer affects: fontconfig (Ubuntu Quantal)
no longer affects: fontconfig (Ubuntu Raring)
Changed in libreoffice (Ubuntu):
milestone: quantal-updates → none
Revision history for this message
Adolfo Jayme Barrientos (fitojb) wrote :

A pango & fontconfig fix is underway, should help. Also, libreoffice 4.3 contains a related enhancement.

no longer affects: libreoffice (Ubuntu)
Changed in ubuntu-font-family:
status: Confirmed → Invalid
Revision history for this message
memartin (memartin) wrote :

Came across this bug today because I cannot use Ubuntu Medium/Bold correctly in neither Libreoffice (5.1.4-0ubuntu1) nor Inkscape (0.91 r13725) under Kubuntu 16.04. The System was installed from scratch and updates are recent.

I have tried the ttf-ubuntu-font-family/xenial package (0.83-0ubuntu2) as well as downloaded Versions from both font.ubuntu.com (0.83 too) and fontsquirrel.com.

In LOO I get all weights under the "Ubuntu" Family entry, except "Medium" -- interestingly Light Italic/Italic/Medium Italic/Bold Italic are there and working! Non-Italic only Light, Regular and Bold show up as Styles. There is no separate Light/Medium Family, only Condensed and Mono.

In Inkscape, otoh, I have Medium/Medium Italic, but no Bold styles.

All available Styles are rendered correctly, i. e. "Regular" is normal, not Medium, etc. In Inkscape I can get a text set to correct Bold style if I enter "Bold" in the Style Dropdown manually.

I am sure this is supposedly not the correct place to put this report - maybe someone can point me somewhere better. Maybe it is a regression, though. A quick look into Ubuntu-M.ttf showed the "Ubuntu Light" thing, and I have also read Bug 744812, but found it it also quite dated and complex.

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

Other bug subscribers

Remote bug watches

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