Ubuntu

FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in Inkscape and too bold in Qt apps)

Reported by Francois Thirioux on 2011-03-29
360
This bug affects 80 people
Affects Status Importance Assigned to Milestone
Fontconfig
Fix Released
Wishlist
Linux Libertine
Unknown
Unknown
Ubuntu Font Family
Undecided
Unassigned
fontconfig (Ubuntu)
Undecided
Unassigned
qt4-x11 (Ubuntu)
Medium
Unassigned
Natty
Undecided
Unassigned
Oneiric
Undecided
Unassigned
Precise
Undecided
Unassigned
Quantal
Medium
Unassigned
ubuntu-font-family-sources (Ubuntu)
High
Unassigned
Natty
High
Unassigned
Oneiric
High
Unassigned
Precise
High
Unassigned
Quantal
High
Unassigned

Bug Description

[Kubuntu natty up-to-date]
Hi,
Without any change on my system, I noticed some days ago that my default font (ubuntu) changed. Some odd behaviour appeared : ubuntu medium 10 pt was ok but ubuntu medium 11pt was bold (-> in my taskbar clock or in kpackapgekit). In fact, after some play with kcm kubuntu font manager, the ubuntu medium 10pt was wrong, since kcm module shows the true appearance of ubuntu medium, which is quite bold. I swapped to ubunu light font
SO ! I changed font hinting to light (default in kubuntu seems to be medium) and it seems to have solved bugs.
Anyway, "ubuntu font" management by KDE seems to be strange, and firefox 4 font rendering is worse (imho) with light hinting (but maybe because of unselected "system default" parameter in fonts kcm).

Francois Thirioux (ft73) wrote :

I forgot to say that this issue is maybe not typically ubuntu-font related, since font rendering is doubious at this time in kubuntu.
But anyway ubuntu-font is the official one, so...

There are definitely issues with both Ubuntu and Ubuntu Light installed.

We are trying to set things up so:

 * sophisticated apps that can handle multiple weights see one face,
"Ubuntu", with the weights Light, Medium, Regular, and Bold.
 * normal apps that can only handle "regular and bold" for a face, see
two faces: Ubuntu (Regular and Bold) and Ubuntu Light (Regular and
Bold). The Ubuntu Light Bold is of course Medium.

This *should* be possible, but it seems either we've misread the
relevant documentation for OpenType, or there are bugs in the various
font subsystems, or both. Thanks for the bug report. Paul Sladen will
have more thoughts shortly, I think! Any font experts willing to comment?

While I did advise against linking Light and Medium in this way
originally, that was entirely on user-confusion grounds - I certainly
expected it to actually work.

I think Paul's initial reading is right - applications (possibly font
subsystems) are mixing their interpretations of preferred naming, weight
flags, and basic style flags. We've tested on preferred-name-aware
applications (InDesign, for example) and a various legacy-name-using
applications without problem.

The simple fix is to untie the Light and Medium, but a better fix would
be to get the preferred name support as good as it is on other platforms
and applications. As a user I'd definitely prefer the latter.

Dave

On 29/03/11 21:13, David Marshall wrote:
> The simple fix is to untie the Light and Medium, but a better fix would
> be to get the preferred name support as good as it is on other platforms
> and applications. As a user I'd definitely prefer the latter.

Agreed. If what you're saying is:

  * on Windows, installing these fonts shows the simplistic two-face
option in Word, and the sophisticated one-face-multiple-weights option
in Photoshop
 * same one Mac

... then we basically have a problem in Ubuntu and it's apps / toolkits
that needs fixing.

Mark

Hi again,

A temporary workaround for KDE seems to be setting user fonts to "rgb true hintslight true" (->~/.fonts.conf) and "Ubuntu medium 9", from Kubuntu systemsettings.
I'm really not technically involved, so I damn do not know why, but it works. Ubuntu medium font is well displayed in plasma workspace (quite bold) and in firefox (not bold).

papukaija (papukaija) on 2011-03-31
Changed in ubuntu-font-family:
status: New → Confirmed
Dmitry Shachnev (mitya57) wrote :

Isn't it a duplicate of bug 741862 (Default interface font is too bold in all Qt4 applications)?

Paul Sladen (sladen) on 2011-04-07
summary: - Kubuntu hinting medium seems to break ubuntu-font appearance
+ FontConfig/Qt stack choke on Ubuntu Medium font meta-data
summary: - FontConfig/Qt stack choke on Ubuntu Medium font meta-data
+ FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in
+ Inkscape and too bold in Qt apps)
Paul Sladen (sladen) wrote :

The current situation is that 'ttf-ubuntu-font-family' isn't the broken part, but the easiest way to effect a fix before release if we can't fix FontConfig/Qt before release (which is increasing in likelihood) is to do it via the 'ttf-ubuntu-font-family' package.

This can be done by not shipping the Medium and Medium Italic weights in Ubuntu 11.04 ('rm /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-M*.ttf').

The /actual/ issue is likely in FontConfig, which appears to be paying more credence to the older 'Bold' flag than the user numerical weight.

Jonathan Riddell (jr) on 2011-04-07
tags: added: kubuntu
Changed in ubuntu-font-family-sources (Ubuntu):
milestone: none → ubuntu-11.04-beta-2

The other option is to convert the legacy naming of the Medium so that
it's a stand-alone family (like the Light) rather than being the Light-Bold.

Dave

Felix Geyer (debfx) on 2011-04-07
Changed in ubuntu-font-family-sources (Ubuntu):
importance: Undecided → High
Mark Shuttleworth (sabdfl) wrote :

On 07/04/11 12:27, David Marshall wrote:
> The other option is to convert the legacy naming of the Medium so that
> it's a stand-alone family (like the Light) rather than being the Light-Bold.

I would like this, except it will bite everyone in future when we change
it. I think we hold off and drop this into 11.10, and if the changes are
really only in FontConfig and they are small, consider an SRU for 11.04.

Thanks for all the debugging!

Mark

Paul Sladen (sladen) wrote :

Mark: to clarify; "drop this" == "drop the individual Medium .ttfs that are currently knocking the barrel over" ?

On 07/04/11 18:00, Paul Sladen wrote:
> Mark: to clarify; "drop this" == "drop the individual Medium .ttfs that
> are currently knocking the barrel over" ?

Yes. Perhaps we can keep Light without the Medium ("Light Bold") weight?

Mark

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-font-family-sources - 0.71.2-0ubuntu2

---------------
ubuntu-font-family-sources (0.71.2-0ubuntu2) natty; urgency=low

  * Don't ship Ubuntu Medium ("Ubuntu Light" "Bold") because
    of issues with the font/toolkit stacks on Ubuntu not working.
    Workaround for (LP: #744812).
 -- Paul Sladen <email address hidden> Mon, 11 Apr 2011 08:49:02 +0000

Changed in ubuntu-font-family-sources (Ubuntu):
status: New → Fix Released
Erdal Ronahi (erdalronahi) wrote :

This does not really solve the issue (in ttf-ubuntu-font-family_0.71.2-0ubuntu3_all.deb). In LibreOffice I can still make the "Ubuntu Light" font bold - and the result is ugly. Kerning seems not to work at all so that "Ubuntu Light Bold" becomes even wider than "Ubuntu Bold".

Attaching PDF with the issue.

Lucazade (lucazade) wrote :

The issue is no more present in Unity2D Qt indicator appmenu. thanks

Mark Shuttleworth (sabdfl) wrote :

Ah. I guess, in the absence of a declared bold, you get an
auto-manufactured one, which would indeed be ugly.

Do we have any deeper understanding of the fixes needed in various
stacks to make the proper fonts work properly?

Erdal Ronahi (erdalronahi) wrote :

It's a misunderstanding to see this as a QT stack problem. The same issue is present under GNOME. It's pure coincidence that the other bugs were made a duplicate of this one.

I am using GNOME, the examples that I posted in my original bug report were also from GNOME. I don't think this has very much to do with Qt, although the title of this bug suggests otherwise.

I am also checking the font on a computer with Debian Squeeze under GNOME, the results are exactly the same as unter Natty.

Mark Shuttleworth (sabdfl) wrote :

No, there are two different bugs.

In one bug, when we have Medium encoded as "Light Bold", Qt gets
confused and uses that when it should not.

In a second bug, what you are seeing now, when we take the "medium" out
of "Ubuntu Light", the systems try to auto-create a "bold". And that is
what you're seeing, I think. Both Gtk and Qt would do that.

Paul Sladen (sladen) wrote :

Erdal: I think this bug report (and the dups) note that the root-cause in the lower levels. The mentioning of "Qt" in the title is mainly there to increase the chance of people finding it.

Paul Sladen (sladen) wrote :

Synthesis would occur twice as often if we presented both fonts individually to the user and they chose to embolden them anyway:

  Ubuntu Light -> [click bold] -> Synthesised Ubuntu Light Bold
  Ubuntu Medium -> [click bold] -> Synthesised Ubuntu Medium Bold

Paul Sladen (sladen) wrote :

Equivalent bug for the LinuxLibertine multi-weight typeface:

  ("Not all Libertine 5.0 fonts usable under Linux - ID: 3307966")
  http://sourceforge.net/tracker/?func=detail&aid=3307966&group_id=89513&atid=590374

again, not actually a bug in the fonts, but in the Linux font stack.

Olivier Tilloy (osomon) wrote :

It used to work well (I’m specifically referring to the symptom of Qt applications defaulting to the medium style, quite visible when running unity-2d), but with today’s update it broke again. I upgraded ttf-ubuntu-font-family from 0.71.2-0ubuntu3+phasedbeta1~natty to 0.71.2-0ubuntu5+phasedbeta3~natty (from the private PPA) and noticed the regression instantly.

Paul Sladen (sladen) wrote :

osomon: for Ubuntu 11.04 we couldn't find a solution, so the workaround was to drop 'Medium' and 'Medium Italic' (just) from the Ubuntu 11.04 release. The complete font family is there on http://font.ubuntu.com/ in the Oneiric archive, beta PPA and internal Canonical walled-garden PPA. Owing to an oversight, that upload (also containing a newer-beta of Mono) never made it to the 'natty' pocket of the Canonical PPA; this was remedied yesterday.

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.

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.

Paul Sladen (sladen) on 2011-07-14
Changed in ubuntu-font-family-sources (Ubuntu Natty):
status: New → Fix Released
importance: Undecided → High
Changed in ubuntu-font-family-sources (Ubuntu Oneiric):
status: Fix Released → New
status: New → Triaged
Changed in ubuntu-font-family:
status: Confirmed → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-font-family-sources - 0.71.2-0ubuntu7

---------------
ubuntu-font-family-sources (0.71.2-0ubuntu7) oneiric; urgency=low

  * Don't ship Ubuntu Medium ("Ubuntu Light" "Bold") because
    of issues with the font/toolkit stacks on Ubuntu not working.
    Workaround for (LP: #744812).
 -- Paul Sladen <email address hidden> Mon, 05 Sep 2011 07:38:36 +0100

Changed in ubuntu-font-family-sources (Ubuntu Oneiric):
status: Triaged → Fix Released
Lucazade (lucazade) wrote :

This bug is still present in Kubuntu 12.04.
All Qt4 apps uses a bold font-weight instead of "Regular" one.

Lucazade (lucazade) wrote :

removing these:
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-B.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-BI.ttf

temporary fixes the issue.

Alberto Mardegan (mardy) wrote :

I filed this as a new bug some time ago: bug 918577.

Paul Sladen (sladen) wrote :

Lucazade: it's not really practical to remove bold as it's used widely. Is it also solved if /instead/ you remove either just the Lights (-L*) or the Mediums (-M*).

Lucazade (lucazade) wrote :

@mardy
seen your report..

@sladen
I know it is not ideal, we need a better and proper fix for this..
While I was playing with fonts I noticed also that plasma panel and menu don't follow hinting at all.. fonts are really pixelated.

Paul Sladen (sladen) on 2012-01-25
Changed in ubuntu-font-family-sources (Ubuntu Precise):
status: Fix Released → Fix Committed
status: Fix Committed → Confirmed
milestone: ubuntu-11.04-beta-2 → ubuntu-12.04-beta-2
Marco Parillo (marco-parillo) wrote :

I believe the appearance is already greatly improved in Kubuntu 12.04 Beta-1.

Nikola Snele (n-schnelle) wrote :

This is still present in Kubuntu 12.04 beta1.

My font configuration: Use anti-aliasing, Use sub-pixel rendering: RGB, hinting style: medium.

Precise screenshot (look at empty space between de and fault in default word for example): http://www.dodaj.rs/f/2V/QX/3vBP6BH9/snapshot1.png

Oneiric screenshot: http://www.dodaj.rs/f/V/fi/2Zrd2Vmo/snapshot11.png

tags: added: rls-mgr-p-tracking
avlas (avlas) wrote :

If using kubuntu 12.04, I recommend in the meantime to use package from oneiric and hold it to avoid updates

Changed in ubuntu-font-family-sources (Ubuntu Precise):
milestone: ubuntu-12.04-beta-2 → ubuntu-12.04
Launchpad Janitor (janitor) wrote :

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

---------------
ubuntu-font-family-sources (0.80-0ubuntu2) precise; urgency=low

  * Don't ship Ubuntu Medium ("Ubuntu Light" "Bold") because
    of issues with the font/toolkit stacks on Ubuntu not working.
    Workaround for (LP: #744812).
 -- Florian Boucault <email address hidden> Wed, 21 Mar 2012 11:02:09 +0000

Changed in ubuntu-font-family-sources (Ubuntu Precise):
status: Confirmed → Fix Released
avlas (avlas) wrote :

The fix works great

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in fontconfig (Ubuntu Natty):
status: New → Confirmed
Changed in fontconfig (Ubuntu Oneiric):
status: New → Confirmed
Changed in fontconfig (Ubuntu Precise):
status: New → Confirmed
Changed in fontconfig (Ubuntu):
status: New → Confirmed
Dmitry Shachnev (mitya57) wrote :

In Quantal, ubuntu-font-family-sources *will* ship the Medium version of the font (see http://pad.lv/1048600). Can anybody please re-open the ubuntu-font-family-sources task and nominate/target all tasks to quantal?

Kate Stewart (kate.stewart) wrote :

Have added tasks to track getting this fixed in quantal when the medium fonts land. See comment #39.

Changed in ubuntu-font-family-sources (Ubuntu):
milestone: ubuntu-12.04 → ubuntu-12.10
status: Fix Released → Triaged
Changed in ubuntu-font-family-sources (Ubuntu Quantal):
status: Triaged → Confirmed
Lucazade (lucazade) wrote :

with the latest update all the fonts in quantal kde are bold.. is this going to be fixed?

temporary workaround:
sudo rm /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-M.ttf /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-MI.ttf

Michał Sawicz (saviq) wrote :

I managed to track down the culprit:

http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontdatabase_x11.cpp#line729

The problem is that Qt only supports 5 weights:
http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfont.h#line103
  Light = 25,
  Normal = 50,
  DemiBold = 63,
  Bold = 75,
  Black = 87

FontConfig has 11 weights defined:
http://cgit.freedesktop.org/fontconfig/tree/fontconfig/fontconfig.h#n126
  #define FC_WEIGHT_THIN 0
  #define FC_WEIGHT_EXTRALIGHT 40
  #define FC_WEIGHT_ULTRALIGHT FC_WEIGHT_EXTRALIGHT
  #define FC_WEIGHT_LIGHT 50
  #define FC_WEIGHT_BOOK 75
  #define FC_WEIGHT_REGULAR 80
  #define FC_WEIGHT_NORMAL FC_WEIGHT_REGULAR
  #define FC_WEIGHT_MEDIUM 100
  #define FC_WEIGHT_DEMIBOLD 180
  #define FC_WEIGHT_SEMIBOLD FC_WEIGHT_DEMIBOLD
  #define FC_WEIGHT_BOLD 200
  #define FC_WEIGHT_EXTRABOLD 205
  #define FC_WEIGHT_ULTRABOLD FC_WEIGHT_EXTRABOLD
  #define FC_WEIGHT_BLACK 210
  #define FC_WEIGHT_HEAVY FC_WEIGHT_BLACK
  #define FC_WEIGHT_EXTRABLACK 215
  #define FC_WEIGHT_ULTRABLACK FC_WEIGHT_EXTRABLACK

And getFCWeight maps them as follows:
   0 ÷ 75 => Light
  76 ÷ 140 => Normal
 141 ÷ 190 => DemiBold
 191 ÷ 205 => Bold
 206 ÷ ∞ => Black

Because of that both Ubuntu Regular and Medium fall into the same Qt weight - QFont::Normal. Since that operation loses the granularity, there's probably no easy way to distinguish between Normal and Medium later in the process.

Possible solutions:
a) introduce QFont::Medium
b) make FC_WEIGHT_MEDIUM mapped to QFont::DemiBold
c) drop seemingly duplicate fonts

I myself would lean towards solution a), but neither that or b) really fixes anything - if there's duplicates, it becomes non-deterministic in which font will be selected (the last one added? a random one?). Solution c) seems to be the most complete, but then also quite intrusive. We'd have to only leave the one whose fontconfig weight is closest to the respective weight. So from each of the getFCWeight ranges only one font would be selected, closest to what fontconfig says that weight should be.

Dmitry Shachnev (mitya57) wrote :

Thanks for investigating this!

> The problem is that Qt only supports 5 weights:
> http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfont.h#line103
> Light = 25,
> Normal = 50,
> DemiBold = 63,
> Bold = 75,
> Black = 87

Apparently these are just integers. Maybe it's possible to map FC_WEIGHT_MEDIUM to an integer like 60 or 65, without using the QFont::Weight enum?

Paul Sladen (sladen) wrote :

Saviq: thanks for finding the Qt part. Things that may be useful in reaching a decision: Truetype defines a weight scale; which is {100,200,300,400,500,600,700,800,900}; (plus other flags); these can be seen with:

  (cd /usr/share/fonts/truetype/ubuntu-font-family/; for i in *.ttf ; do echo -ne "$i\t:"; showttf $i | grep -i Weight | xargs echo ; done)

This TTF scale is the source for virtually all weights in use (as virtually all fonts are sourced from TTF/OTF containers these days). These are suffering from a double-remapping + double discard. Other people's handling of the mapping are; for Google Web Fonts (documented per Dave Crossland) on:

  https://bugs.launchpad.net/ubuntu-font-family/+bug/730912/comments/2

Probably the most useful recommendation on the handling of mapping is from the CSS specification;

  http://www.w3.org/TR/CSS21/fonts.html#propdef-font-weight
  "…association of other weights within a family to the numerical weight values is intended only to preserve the ordering of darkness within that family."

and which provides the recommended remapping algorithm in text form. This initially maps a Medium back to 500 (if available) and a Bold to 700 (if available). and uses other logic to fill outwards from those reference points. Given QML<->CSS and the significance of familiarity with HTML/CSS (and exposure/testing) that it has likely had, it might be reasonable to transpose/implement this algorithm too.

TTF weights {300,400,500,700}. FC weights {50,80,100,200}. Ideal Qt output {25,50,63,75}

(Rule of thumb would seem to be ~0.125 of TTF value, or ~0.63 of FC value for the two important weights Regular and Medium).

The idea way might be to have would be perhaps to have Qt's getFCWeight() reverse the bucket logic of FcFreeTypeQueryFace() (which returns discreet enums, not an integer, nor the raw 'os2->usWeightClass' directly), and then apply the CSS algorithm to the untransformed result. This should be fairly robust.

Paul Sladen (sladen) wrote :

Proposed patch for discussion; this shifts the buckets to avoid ABI/API break. Saviq would you be able to test this and see what happens?

tags: added: patch
Paul Sladen (sladen) wrote :

(Chatting to Saviq in IRC). We've tracked down some more aggravating factors. Main one being the Qt requests Medium by default(!) (in spite of having no internal Enum/handling for Medium).

Somewhat larger patch idea (blind, since I haven't rebuilt Qt), with substantially more comments. This includes both the ideal codepaths for the future, and minimal solutions separated by #if/#else constructs.

Michał Sawicz (saviq) wrote :

The above patch alone does not help as the database isn't used directly. Instead, requests are forwarded to Fontconfig, which is a good thing.

It then maps Qt weights back to FC weights:
http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontdatabase_x11.cpp#line1489

And the mapping looks as follows:
         0.0 => Medium
  0.0 ÷ 36.5 => Light
 36.5 ÷ 56.5 => Medium
 56.6 ÷ 69.0 => DemiBold
 69.0 ÷ 81.0 => Bold
 81.0 ÷ ∞ => Black

An attentive reader will find that there's no Regular there... Which means Qt will _never_ request a Regular font from Fontconfig, so as long as there's anything closer to Medium than Regular (e.g. Medium), it will choose that over Regular. What's more, it defaults to Medium, which seems a common pattern in that code:
http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontdatabase_x11.cpp#line777
http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontdatabase_x11.cpp#line1069
http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontdatabase_x11.cpp#line1078
http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontdatabase_x11.cpp#line1491

Michał Sawicz (saviq) wrote :

We've made some progress with three possible versions of the patch:
QML:
unpatched: http://ubuntuone.com/7a8TfmDRaYUaRYWZUtRmuW
medium: http://ubuntuone.com/0sZZPdbwYeG9iSIcvMZtSe
medium+demibold/2: http://ubuntuone.com/1Iurc6svseVNZ31sTEjs81
demibold: http://ubuntuone.com/5fJQHga4xfZiXGuBAIoNO8

Qt GUI:
unpatched: http://ubuntuone.com/2QVRUraAPK5pr7VlbHmJG1
medium: http://ubuntuone.com/4ef1K6IseimToUsbGj5ghB
medium+demibold/2: http://ubuntuone.com/0a5N1ArQQbEy0xoxy1RzId
demibold: http://ubuntuone.com/1xz9HLhm7hYg5s4Vf6NiZo

It seems that the "medium" one is the least wrong, but changes behaviour for DemiBold for fonts that only have Regular and Bold.

I'm not sure why "medium+demibold/2" for DemiBold selects a font heavier than Bold. Will investigate as fixing that could yield best results with smallest behaviour change.

Michał Sawicz (saviq) wrote :

Found the issue - for medium+demibold/2 it comes back with "embolden: true", which seems to be broken for the Exo font.

New pre/post:

QML
http://ubuntuone.com/7eicHCbFn6PkshRN23jXjA vs. http://ubuntuone.com/62PiHljh4W0NNZEnuxFWEy

Qt GUI
http://ubuntuone.com/1dJKerWBZeeS9tkLf1SOOf vs. http://ubuntuone.com/1HcmdfXAwBzrCWsnYnORVn

Mark Shuttleworth (sabdfl) wrote :

You guys rock. Thank you for chasing this!

Michał Sawicz (saviq) wrote :

I've built patched packages in ppa:saviq/testing, you can first:

$ sudo apt-get install ttf-ubuntu-font-family

to get the Medium fonts back, and see how that affects Qt apps.

Then, upgrade Qt with packages from my ppa:

$ sudo apt-get upgrade

And the results:

QML
pre: http://ubuntuone.com/4szdxbd9tKmako0XGQSWzh
post: http://ubuntuone.com/3uBwe3BhqtnPb5XfCWnn7f

Qt GUI
pre: http://ubuntuone.com/30TgXSVWajLHUowlOqQEeg
post: http://ubuntuone.com/3SpZM4PHMVpX9orDWyTbek

Ubuntu One
pre: http://ubuntuone.com/5SP0tfSijfV82Uo0Bywbhk
post: http://ubuntuone.com/00gE9SPxiemzm8sZmfQldm

To anyone concerned: please test and report back with success or failure stories.

Michał Sawicz (saviq) wrote :

And here's the patch.

Paul Sladen (sladen) wrote :

For those following along, Saviq has raised this with #kubuntu-devel:

  http://irclogs.ubuntu.com/2012/09/24/%23kubuntu-devel.html#t20:05

and I've tried to raise it with the original backend authors (Lars Knoll and Jiang Jiang) over on Freenode #qt-labs.

It would be really good to get feedback. The change is intended to be transparent to applications (no visible ABI/API) change, but it would still be good to know this viewed as a step along the path to properly fixing's Qt X11/Fontconfig backend.

Michał Sawicz (saviq) wrote :

I've also now put it up for review in Qt:
https://codereview.qt-project.org/#change,35591

Alan Pope ㋛ (popey) wrote :

Tested qt from Saviqs ppa and looks good. See attached screenshots. Showing Mumble, VLC and U1 client.

Alan Pope ㋛ (popey) wrote :

Previous screenshot was "before". This one is "after".

Changed in qt4-x11 (Ubuntu Natty):
status: New → Invalid
Changed in qt4-x11 (Ubuntu Oneiric):
status: New → Invalid
Changed in qt4-x11 (Ubuntu Precise):
status: New → Invalid
Changed in qt4-x11 (Ubuntu Quantal):
assignee: nobody → Ken VanDine (ken-vandine)
importance: Undecided → Medium
status: New → Triaged
Changed in qt4-x11 (Ubuntu Quantal):
assignee: Ken VanDine (ken-vandine) → nobody

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

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.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qt4-x11 - 4:4.8.3+dfsg-0ubuntu3

---------------
qt4-x11 (4:4.8.3+dfsg-0ubuntu3) quantal-proposed; urgency=low

  [ Iain Lane ]
  * On armel and armhf, build with -gstabs instead of -g in an effort to get
    the link step for QtWebkit to complete before timed out by the builders.

  [ Felix Geyer ]
  * Disabling SSL/TLS compression to mitigate the "CRIME" attack. (LP: #1057578)
    - Add disable-SSL-compression-by-default.patch
 -- Iain Lane <email address hidden> Tue, 02 Oct 2012 10:36:17 +0100

Changed in qt4-x11 (Ubuntu Quantal):
status: Triaged → Fix Released
tags: removed: rls-mgr-p-tracking
no longer affects: fontconfig (Ubuntu)
no longer affects: fontconfig (Ubuntu Natty)
no longer affects: fontconfig (Ubuntu Oneiric)
no longer affects: fontconfig (Ubuntu Precise)
Changed in fontconfig (Ubuntu Quantal):
status: Confirmed → Invalid
no longer affects: fontconfig (Ubuntu Quantal)
Changed in fontconfig (Ubuntu):
status: New → Confirmed
Jonathan Riddell (jr) on 2012-10-08
tags: removed: kubuntu
Timo Jyrinki (timo-jyrinki) wrote :

There is a workaround in the font in quantal now (bug 1054204) that enables Ubuntu Medium font, but it is not the original intent of the font. The bugs have been workarounded in other fonts well, but the real bugs in fontconfig and libreoffice should also get fixed, so that the original configuration of the Ubuntu Medium font could be restored.

The original setting in the font is related to remapping to the preferred family, so when eg. one would bold Ubuntu Light one would get Ubuntu Medium.

Changed in ubuntu-font-family-sources (Ubuntu Quantal):
status: Confirmed → Fix Released
Changed in fontconfig:
importance: Unknown → Wishlist
status: Unknown → Confirmed

The attachment "src_gui_text_qfontdatabase_x11.cpp.diff" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Hi guys - please do let's fix this properly, meaning that the "bold of
Ubuntu Light is Medium". Please don't reflect the bugs as fixed if that
is not the case.

Mark

Download full text (3.2 KiB)

Just following up on comment 42, I assume the equivalent to be done in LibreOffice at convertWeight() in fontmanager.cxx:

 http://opengrok.libreoffice.org/xref/core/vcl/generic/fontmanager/fontconfig.cxx#428

which maps:

LibreOffice weight fontconfig weight value
WEIGHT_THIN FC_WEIGHT_THIN <=0
WEIGHT_ULTRALIGHT FC_WEIGHT_ULTRALIGHT/FC_WEIGHT_EXTALIGHT <=40
                        FC_WEIGHT_LIGHT <=50
WEIGHT_LIGHT FC_WEIGHT_BOOK <=75
WEIGHT_SEMILIGHT FC_WEIGHT_REGULAR/FC_WEIGHT_NORMAL <=80
WEIGHT_NORMAL FC_WEIGHT_MEDIUM <=100
WEIGHT_MEDIUM FC_WEIGHT_DEMIBOLD/FC_WEIGHT_SEMIBOLD <=180
WEIGHT_SEMIBOLD FC_WEIGHT_BOLD <=200
WEIGHT_BOLD FC_WEIGHT_EXTRABOLD/FC_WEIGHT_ULTRABOLD <=205
                        FC_WEIGHT_BLACK/FC_WEIGHT_HEAVY <=210
WEIGHT_BLACK FC_WEIGHT_EXTRABLACK/FC_WEIGHT_EXTRAHEAVY <=215

Where do the Ubuntu fonts fall in that scale?
I will try to testload the Ubuntu font in a debug build of LibreOffice, to see what http://opengrok.libreoffice.or...

Read more...

Hold on, what I wrote above is for LibreOffice 3.7+/master, 3.6 still guesses font weights from the strings in the GlobalFontInfo struct:

https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=vcl/generic/fontmanager/fontmanager.cxx;h=76ca13ec4366a9c82b84bceef2c0b4d12b6cd117;hb=da8c1e62c79033f0c895f81e019d23ce79aa6834#l138

Also note that any nontrivial patch there will affect all fonts in rendered documents opening us to a lot of havoc, if our vendor patch makes documents being rendered different (different font weight might change pagebreaks, thus numbers of pages, manual (hardcoded) references to pages or images -- esp. things like "last page") on Ubuntu than everywhere else (Windows, OSX). Even if we would do it right, and everyone else would do it work -- the users likely would not care, if it destroys their crossplatform document fidelity (with the same major -- even minor).

Graeme Hewson (ghewson) wrote :

Bug 972279 "Konsole displays bold text with normal weight" might be related to this.

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

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

committed.

Changed in fontconfig:
status: In Progress → Fix Released
BubuXP (bubuxp) wrote :

I'm using Ubuntu font family in Debian Sid (Xfce) and I still get this bug when using VLC (that uses Qt).
I'm not a developer, nor a programmer, but after reading the whole report and found where the bug lies, I've managed to fix it copying the method used for the Delicious font in conf.avail/80-delicious.conf and adapting it for the Ubuntu font.

I attached the file to put in /etc/fonts/conf.d/ or in ~/.config/fontconfig/conf.d/ but the code for Ubuntu Medium Italic doesn't work (when Regular Italic is used for interface, Medium Italic is still used in VLC/Qt). Probably it's very easy to someone more experienced than me to fix this patch for correct Medium Italic handling.
After that I have to rebuild the font cache as root (sudo) and as user, or it doesn't work.

Is a possible solution to bring this file (properly fixed) with ubuntu font deb package?
In case it should be placed in /usr/share/fontconfig/conf.avail/ and symlinked to /etc/fonts/conf.d/

I'm using those libraries versions, if it matters:
Fontconfig ver.: 2.11.0-2
FreeType ver.: 2.5.2-1

BubuXP (bubuxp) wrote :

Ok, now this configuration works for 'Medium Italic' too (it was easier than I thought).
Probably this is not a "full range" solution, but it surely fixed the problem in my case.

This bug is still present in Ubuntu or Saucy adopted the patches in this thread to fix it?
In Debian it's still present and that means probably that upstream code hasn't merged those patches.

BubuXP (bubuxp) wrote :

Excuse me, I won't spam the discussion anymore :)
This is my last version of the workaround, this fixes both this bug and bug #813373

The font developer team could fix the font hard-coded 'family', 'style' and 'weight' properties easily to fix those bugs.

To post a comment you must log in.