"Ubuntu Light" font has heavier weight than "Ubuntu"

Bug #1512111 reported by Alberto Donato on 2015-11-01
This bug affects 7 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Ubuntu Font Family
chromium-browser (Ubuntu)
fonts-ubuntu (Ubuntu)

Bug Description

After upgrading from Vivid to Wily, pages using the "Ubuntu light" font actually renders with a weight heavier than the regular one in web pages.
This happens with Chrome/Chromium and also the Ubuntu browser.

After manually reinstalling the 0.80-0ubuntu6 version from Vivid (in place of 0.83-0ubuntu1), the issue is fixed.

See the attached screenshot showing the result seen browing https://www.google.com/fonts#UsePlace:use/Collection:Ubuntu

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: ttf-ubuntu-font-family 0.83-0ubuntu1
ProcVersionSignature: Ubuntu 4.2.0-17.21-generic 4.2.3
Uname: Linux 4.2.0-17-generic x86_64
ApportVersion: 2.19.1-0ubuntu4
Architecture: amd64
CurrentDesktop: Unity
Date: Sun Nov 1 17:55:19 2015

InstallationDate: Installed on 2014-10-14 (382 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140923)
PackageArchitecture: all
SourcePackage: ubuntu-font-family-sources
UpgradeStatus: Upgraded to wily on 2015-10-31 (0 days ago)

IMPACT: Ubuntu Light font renders incorrectly for all 15.10 users which impacts the usability and visual design.

The new version of font package (0.831) corrects the relationship between Light and Medium weight to follow the commonly used naming standards:

Ubuntu Light Light Light Italic
Ubuntu Regular Italic Bold Bold Italic
Ubuntu Medium Medium Medium Italic
Ubuntu Condensed Regular
Ubuntu Mono Regular Italic Bold Bold Italic

TEST CASE: in 15.10, go to https://www.google.com/fonts#UsePlace:use/Collection:Ubuntu

If the Light weight renders heavier than Normal weight, the bug is in place


0.831 was tested by manually running in 15.10 and no regression was noticed, while the bug was fixed. The potential for regression is small.

Alberto Donato (ack) wrote :
description: updated
Changed in ubuntu-font-family-sources (Ubuntu):
status: New → Confirmed
no longer affects: ubuntu-font-family
Matthew Paul Thomas (mpt) wrote :

This might be related to bug 859673.

Changed in ubuntu-font-family-sources (Ubuntu):
status: Confirmed → In Progress
Changed in ubuntu-font-family:
status: New → In Progress
importance: Undecided → High
Changed in ubuntu-font-family-sources (Ubuntu):
importance: Undecided → Medium
assignee: nobody → Magdalena Mirowicz (magdalena-mirowicz)
Changed in hundredpapercuts:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Magdalena Mirowicz (magdalena-mirowicz)
Changed in ubuntu-font-family:
importance: High → Medium
assignee: nobody → Magdalena Mirowicz (magdalena-mirowicz)
description: updated
Paul Sladen (sladen) wrote :

The test case suggests a change to 'Ubuntu Mono', but the 'Ubuntu_0.831.zip' I have here doesn't have any Ubuntu Mono (nor source, nor changelog, nor scripting, nor test cases, nor any contextual information). I can see:

  2016-01-04 11:31 Zip file (repacked today?)
  2015-12-04 10:55 .ttfs
  2015-12-04 10:53:12..10:53:39, internal timestamps (three-second intervals)

The two positive takeaways are that the version debug glyph shows 0.831, and from the close-interval timestamps we can deduce that the change(s) were made in an automated fashion. The question remains *what those changes are*.

We can see eg:

  $ otfinfo -s {,/usr/share/fonts/truetype/ubuntu-font-family/}Ubuntu-R.ttf

That the 0.84 files already out in the real world have flags indicating 'Hebrew' and 'Default', which these don't. Since these support less than than the higher-numbered version out there, it remains:

  * What are these files for. What is their purpose, what is supposed to be tested.
  * Are they even targetted for distribution. If so what are we supposed to do with them when they have a lower version number and less functionality.

Paul Sladen (sladen) wrote :

(For want of a better place to put it), useful ttx diffs + changelog forwarded to me at the end of yesterday which gives more context on what the above referenced .zip file delivery is.

[Kudos to DM Engineering to doing this in an automated fashion, and those along the chain for passing it along].

Adolfo Jayme (fitojb) on 2016-01-22
Changed in ubuntu-font-family-sources (Ubuntu Wily):
status: New → Triaged
importance: Undecided → Medium
Alberto Donato (ack) wrote :

FWIW, I'm seeing the same issue after upgrading to Xenial, which installs 1:0.83-0ubuntu2.

Alberto Donato (ack) on 2016-03-16
tags: added: xenial
Changed in hundredpapercuts:
assignee: Magdalena Mirowicz (magdalena-mirowicz) → nobody
Changed in ubuntu-font-family:
assignee: Magdalena Mirowicz (magdalena-mirowicz) → nobody
Changed in ubuntu-font-family-sources (Ubuntu):
assignee: Magdalena Mirowicz (magdalena-mirowicz) → nobody
Alberto Donato (ack) wrote :

This is fixed for me on Xenial with 1:0.83-0ubuntu2

Alberto Donato (ack) wrote :

This seems to have regressed in Artful. The local 'Ubuntu' 300 font is heavier than the one from fonts.google.com.

Font version is:

ii ttf-ubuntu-font-family 1:0.83-0ubuntu2

Alberto Donato (ack) wrote :

Attached a sample html which shows the behavior comparing local and remote fonts (tested in Chromium).

Confirmed, I am seeing this everywhere that local fonts are being used.
I think it's a fontconfig or related regression.


Alberto Donato (ack) wrote :

Same behaviour in current Bionic installs (package version is the same as Artful)

tags: added: artful bionic
Daniel van Vugt (vanvugt) wrote :

Partially confirmed on bionic, but maybe not.

LibreOffice writer: Bug exists and "Light" is heavier if you type in "Ubuntu Light". However if you use "Ubuntu" and right-click on text to choose Character... > Style=Light, then it is correctly lighter. No bug.

gnome-font-viewer: No bug (light is indeed lighter).

Looking at the HTML in comment #9, I'm thinking maybe that test case is wrong. In theory you would probably want to change:

           font-family: 'Wrong';
- font-style: normal;
+ font-style: light;
           font-weight: 300;
- src: local('Ubuntu Light');
+ src: local('Ubuntu');

However in practice CSS doesn't appear to have an option "font-style: light". So it would appear to me trying to use Light in a web page or CSS is the mistake. It works fine in native apps where you can select Style = Light.

Paul Sladen (sladen) wrote :

Hello Daniel, plan is to switch the fonts for source-built versions. These source-built fonts should in the first instance be work-alikes (equivalents) to the binary fonts currently shipped via Google Fonts.

The versions hosted on Google Fonts have undergone various refinements of the metadata via binary patching.

The intention is that the source-built version will have equivalent metadata.

Iain Lane (laney) wrote :

I think you can define a font family like in the attached file - which I've eliminated the Google fonts from, so we're only using the files shipped in Ubuntu. This file renders "as expected" in epiphany (webkit) and Firefox, but not in Chromium (as is the case for the previous example given).

It *feels* from those results like a problem in Chrome/Chromium, but maybe not - if Olivier has some time, perhaps he could have a look ... ? I'm not a HTML/CSS expert so I could just be understanding it wrong and I'm getting some undefined behaviour cross-browser. If you use Firefox's inspector you can see that it finds Ubuntu / Ubuntu Light / Ubuntu Bold properly. Unfortunately it looks like Chromium's only shows the family so you can't see in great detail what it's doing.

no longer affects: chromium-browser (Ubuntu Wily)
Changed in chromium-browser (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
Paul Sladen (sladen) wrote :

The valid CSS would be:

  font-weight: lighter;

In the case of explicitly wanting "Ubuntu Light", once everything is fixed, the CSS access will hopefully be just:

  font-family: "Ubuntu";
  font-weight: 300;

Iain Lane (laney) wrote :

Ahoy Paul!

On Mon, Jan 22, 2018 at 01:29:46PM -0000, Paul Sladen wrote:
> The valid CSS would be:
> font-weight: lighter;
> In the case of explicitly wanting "Ubuntu Light", once everything is
> fixed, the CSS access will hopefully be just:
> font-family: "Ubuntu";
> font-weight: 300;

That works - see the second <p> in my test.html. In fact that one works
even in Chromium.

What seems to not work in Chromium (only, AFAICS) is defining a font
family using @font-face and selecting Ubuntu {,Regular,Light}
explicitly, defining their appropriate weights.


Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Olivier Tilloy (osomon) wrote :

According to https://drafts.csswg.org/css-fonts-3/#src-desc:

« When authors would prefer to use a locally available copy of a given font and download it if it’s not, local() can be used. The locally-installed <family-name> argument to local() is a format-specific string that uniquely identifies a single font face within a larger family. Like its use in font-family, <family-name> can be a quoted string, or a series of unquoted identifiers which are converted to a face name by concatenating them separated by a space.
Just as a @font-face rule specifies the characteristics of a single font within a family, the unique name used with local() specifies a single font, not an entire font family »

So it looks like chromium is not behaving correctly. Neither is epiphany in my tests. Only firefox seems to implement that CSS rule correctly.

Olivier Tilloy (osomon) wrote :
Changed in chromium-browser (Ubuntu):
status: New → Confirmed
John (theislandofnonda) wrote :

Downloaded ubuntu-font-family-0.83 from design.ubuntu.com/font.

This bug also affects me on Debian 9.

If I remove Ubuntu Medium, Ubuntu Light renders properly in LibreOffice.

Also, Microsoft Windows displays Ubuntu Medium's font name as "Ubuntu Light."

Adolfo Jayme (fitojb) on 2018-03-19
affects: ubuntu-font-family-sources (Ubuntu) → fonts-ubuntu (Ubuntu)
Adolfo Jayme (fitojb) on 2019-02-19
no longer affects: fonts-ubuntu (Ubuntu Wily)
Harry W. Haines, III (harry17) wrote :

Any further progress on this? Why have a bug reporter if bugs are going to sit out here forever unresolved. This is a definite issue with the metadata in the fonts. Easily fixable.

Olivier Tilloy (osomon) wrote :

Aside from the chromium upstream bug (https://bugs.chromium.org/p/chromium/issues/detail?id=627143), I'm not seeing any issue with the rendering of Ubuntu Light:

 - libreoffice renders text correctly when using the Ubuntu font and setting the character style to light
 - firefox and epiphany (web) render Iain's test page (comment #14) as expected

I have tested on disco (19.04) and eoan (19.10).

I have a limited understanding of how fonts work, but the chromium issue doesn't appear to be caused by font metadata, rather by an incorrect implementation of the W3C spec.

@Harry, are there other problems with the rendering of Ubuntu Light?

Changed in chromium-browser (Ubuntu):
assignee: Olivier Tilloy (osomon) → nobody
Changed in fonts-ubuntu (Ubuntu):
status: In Progress → Incomplete
Changed in hundredpapercuts:
status: In Progress → Incomplete
Changed in ubuntu-font-family:
status: In Progress → Incomplete
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.