Forum Bugs

Ubuntu Font not rendered properly

nico
Hi,

I would like to use the Ubuntu font (http://font.ubuntu.com). It displays very well in my browser but unfortunately not in Prince.

For exemple if I write the following string in my HTML file :

<p>l&#8217;électron &#8220;libre&#8221; e&#8211;e</p>


It will render correctly in my browser:

l’électron “libre” e–e


But not in Prince:

l⁹électron ⁸libre⁹ eẃe


The result is the same on OSX and Win8.

Any idea why browsers can display this font but not Prince? Note that the version from Google Fonts seems to work, but with the following message:

prince: warning: cyclic @font-face redirect to "Ubuntu"


Funny enough, I tried to download the TTF files from Google Fonts and the files are exactly the same (though with different names) than the ones I got from ubuntu.com...

You can see the HTML I used for testing below.

Nicolas




<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Test Ubuntu Font</title>

<!--
<link href='http://fonts.googleapis.com/css?family=Ubuntu:300,400,500,700,300italic,400italic,500italic,700italic' rel='stylesheet' type='text/css'>
<link href='http://fonts.googleapis.com/css?family=Ubuntu+Mono:400' rel='stylesheet' type='text/css'>
-->

<style type="text/css">
body
{
	font-family: Ubuntu;
	text-align:center;
}
@page
{
	size: A6;
	margin: 2cm 0.5cm 1cm;
}
</style>
</head>
<body>


<p><a href="http://font.ubuntu.com">Ubuntu Font</a></p>
<p>l&#8217;électron &#8220;libre&#8221; e&#8211;e</p>
<!--
l⁹électron ⁸libre⁹ eẃe
-->

</body>
</html>


Edited by nico

mikeday
I can't reproduce the problem with Prince 9 rev 5, see the attached PDF below. I downloaded the font from Google, but if it's the exact same file then it shouldn't matter. Can you attach a generated PDF here? It might help to generate it with --no-compress.
  1. test.pdf6.9 kB
nico
Thank you for your reply Mike !

I generated the HTML above with Prince 9.0 rev 5 and --no-compress.
  1. With the Ubuntu font family enabled on my system (OSX 10.9.5)
  2. With the Ubuntu font family disabled
The PDF are attached to this post.

Did you make the test with a Linux system ?

Nicolas
  1. test_ubuntu_font-disabled.pdf15.4 kB
  2. test_ubuntu_font-enabled.pdf8.8 kB
mikeday
In that case it seems that it must be specific to the way Prince is accessing system fonts on MacOS X. That will take us longer to investigate the cause. In the meantime, you could workaround it by using the Google font, or alternatively accessing it as a local file via a @font-face rule, but without installing it as a system font.
nico
Note that Windows 8 is also affected by this problem.

I continued to make some tests and here are my conclusions :
  • The font is always displayed correctly in browsers (Safari, FF and Opera)
  • The font is never displayed correctly in LibreOffice and Pages
  • The font is not displayed correctly in Prince when
    • using the system font
    • using Google font with “subset=latin-ext,greek-ext”
  • The font is displayed correctly in Prince when using Google Fonts with “subset=greek-ext” or when no subset is defined.
It seems to me that the font itself has a problem. Even the Font Book in Mac OSX displays « ⁸ » instead of « ’ ».

I will use the @font-face rule with “subset=greek-ext” for now.

Thank you for your help.

Nicolas

mikeday
Yes, the font appears to be broken. But it's a confusing situation, because the WOFF file from Google is fine. But the TTF file from font.ubuntu.com has a broken cmap table. However, it has three cmap subtables, two of which are broken, one of which seems non-broken, so presumably the browser is using the non-broken one? But the broken ones are the Unicode subtables, which are the ones that Prince (and LibreOffice etc.) will use preferentially if available. Hence the problem.
mikeday
I have logged the font bug here.
nico
Many thanks for your help Mike. I don’t have the knowledge to understand what’s going wrong with this font, but I guess that your bug report https://bugs.launchpad.net/ubuntu-font-family/+bug/1334363 will help the developers. They know this bug since June 2014 and they did nothing it seems. Now with your explanation I hope they will be able to fix it. Thanks again.
sladen
nico: Fixing is often the easy part, and proper fixing is only possible once an issue has been debugged and fully understood. As you've probably discovered now, pinning down precisely when superscript '9' substitution occurs depends on certain combinations of operating system release and precise version, combined with certain applications application versions, and also which exact TTFs and WOFF subsets produced from them.

It's really good you've been able to debug some of the combinations where it happens and where it doesn't happen, and that you've then linked to/from the bug #1334363 report and this Prince #2867 bug report. This allows getting a couple more data-points to help with (eventually) pinning down the causes, and so from that finding a solution that keeps all of the font parses on all of the current platforms happy.

We need to be a bit more exact though, would you be able to paste the exact URLs (and ideally checksums) of the files that you know work, and don't work.
mikeday
I don't think it is necessary to check different operating systems or applications, as we have already seen that the Unicode cmap subtable is incorrect. If you like I can run a quick comparison of the different cmap subtables and find all the inconsistencies, that will be faster and more thorough.
mikeday
Okay, this is what I have found so far:

The font has three cmap subtables, one Apprle Roman subtable and two Unicode subtables. The two Unicode subtables appear to be consistent with each other, but inconsistent with the Apple Roman subtable. The Apple Roman subtable appears to be correct, and the Unicode subtables appear to be wrong. So whether the font works or not depends on which subtable an application accesses first.

Here are the differences between the Apple Roman subtable and the Unicode subtables:
macroman 182 maps to glyph 410, but U+03b4 maps to glyph 953
macroman 183 maps to glyph 413, but U+03a3 maps to glyph 943
macroman 184 maps to glyph 412, but U+03a0 maps to glyph 941
macroman 189 maps to glyph 414, but U+03a9 maps to glyph 949
macroman 197 maps to glyph 421, but U+2245 maps to glyph 0
macroman 198 maps to glyph 411, but U+0394 maps to glyph 929
macroman 206 maps to glyph 109, but U+0152 maps to glyph 360
macroman 207 maps to glyph 121, but U+0153 maps to glyph 372
macroman 208 maps to glyph 115, but U+2013 maps to glyph 361
macroman 209 maps to glyph 116, but U+2014 maps to glyph 362
macroman 210 maps to glyph 112, but U+201c maps to glyph 372
macroman 211 maps to glyph 113, but U+201d maps to glyph 373
macroman 212 maps to glyph 110, but U+2018 maps to glyph 372
macroman 213 maps to glyph 111, but U+2019 maps to glyph 373
macroman 219 maps to glyph 98, but U+00a4 maps to glyph 127
macroman 220 maps to glyph 108, but U+2039 maps to glyph 360
macroman 221 maps to glyph 120, but U+203a maps to glyph 372
macroman 222 maps to glyph 428, but U+fb01 maps to glyph 1170
macroman 223 maps to glyph 430, but U+fb02 maps to glyph 1172
macroman 226 maps to glyph 99, but U+201a maps to glyph 361
macroman 227 maps to glyph 101, but U+201e maps to glyph 361
macroman 246 maps to glyph 105, but U+005e maps to glyph 65
macroman 247 maps to glyph 117, but U+02dc maps to glyph 936
macroman 249 maps to glyph 353, but U+02d8 maps to glyph 1172
macroman 250 maps to glyph 354, but U+02d9 maps to glyph 1173
macroman 251 maps to glyph 355, but U+02da maps to glyph 1174
macroman 253 maps to glyph 357, but U+02dd maps to glyph 1176
macroman 254 maps to glyph 356, but U+02db maps to glyph 1175
macroman 255 maps to glyph 351, but U+02c7 maps to glyph 360

You can see that Apple Roman characters 212 and 213 correspond to U+2018 and U+2019, left single quote and right single quote, and the Unicode cmap subtables are mapping these two characters to the wrong glyphs.

There may be other things wrong about the Unicode cmap subtables, but this comparison just picks up the cases where they clearly differ from the Apple Roman subtable, which can't possibly be correct and will give inconsistent results.
mikeday
Sorry, I got a couple of the glyphs wrong in that last dump, as "Apple Roman" and "MacRoman" are slightly different. Here is the corrected and slightly shorter list of inconsistencies:
macroman 183 maps to glyph 413, but U+2211 maps to glyph 1168
macroman 189 maps to glyph 414, but U+03a9 maps to glyph 949
macroman 206 maps to glyph 109, but U+0152 maps to glyph 360
macroman 207 maps to glyph 121, but U+0153 maps to glyph 372
macroman 208 maps to glyph 115, but U+2013 maps to glyph 361
macroman 209 maps to glyph 116, but U+2014 maps to glyph 362
macroman 210 maps to glyph 112, but U+201c maps to glyph 372
macroman 211 maps to glyph 113, but U+201d maps to glyph 373
macroman 212 maps to glyph 110, but U+2018 maps to glyph 372
macroman 213 maps to glyph 111, but U+2019 maps to glyph 373
macroman 219 maps to glyph 98, but U+00a4 maps to glyph 127
macroman 220 maps to glyph 108, but U+2039 maps to glyph 360
macroman 221 maps to glyph 120, but U+203a maps to glyph 372
macroman 222 maps to glyph 428, but U+fb01 maps to glyph 1170
macroman 223 maps to glyph 430, but U+fb02 maps to glyph 1172
macroman 226 maps to glyph 99, but U+201a maps to glyph 361
macroman 227 maps to glyph 101, but U+201e maps to glyph 361
macroman 246 maps to glyph 105, but U+005e maps to glyph 65
macroman 247 maps to glyph 117, but U+02dc maps to glyph 936
macroman 249 maps to glyph 353, but U+02d8 maps to glyph 1172
macroman 250 maps to glyph 354, but U+02d9 maps to glyph 1173
macroman 251 maps to glyph 355, but U+02da maps to glyph 1174
macroman 253 maps to glyph 357, but U+02dd maps to glyph 1176
macroman 254 maps to glyph 356, but U+02db maps to glyph 1175
macroman 255 maps to glyph 351, but U+02c7 maps to glyph 360
nico
@mikeday: Thank you for all these details and for your time. I am sure it will greatly help.

@sladen: You will find PDF examples in my second post on this thread. And sorry if I said something wrong, my proficiency in English is limited, my mother tongue is French. By the way, may I ask you if you work in the Ubuntu Font team?