Libreoffice chooses incorrect font weight

Bug #1054204 reported by Alan Pope 🍺🐧🐱 🦄 on 2012-09-21
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Fix Released
Ubuntu Font Family
fontconfig (Ubuntu)
ubuntu-font-family-sources (Ubuntu)

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:-


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)

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:
  "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:

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

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

It, too, was ignored.

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

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!

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.

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.

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
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
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:

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

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

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

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

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.

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.

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?

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

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:

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

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

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.


Changed in fontconfig:
status: Confirmed → In Progress

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


Changed in fontconfig:
status: In Progress → Fix Released
Timo Jyrinki (timo-jyrinki) wrote :

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


Changed in fontconfig (Ubuntu):
status: Confirmed → Fix Released
Adolfo Jayme (fitojb) on 2014-02-07
no longer affects: libreoffice (Ubuntu Quantal)
no longer affects: libreoffice (Ubuntu Raring)
Adolfo Jayme (fitojb) on 2014-04-18
no longer affects: fontconfig (Ubuntu Quantal)
no longer affects: fontconfig (Ubuntu Raring)
Changed in libreoffice (Ubuntu):
milestone: quantal-updates → none
Adolfo Jayme (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
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 (0.83 too) and

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  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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