Synthetic emboldening/italic/italic-bold fails for single-styled fonts

[Qianqian Fang]

Binary package hint: firefox

Ubuntu 9.10, firefox 3.5.3 is unable to print bold Chinese sans characters.

Steps to duplicate:
1. if you set desktop language to Chinese, ttf-wqy-zenhei will be automatically installed as the default Sans Serif font, if you use other languages, simply install ttf-wqy-zenhei via atp-get first

2. in firefox, select Edit\Preference\Content\Font & Color, select the default font as "sans-serif"

3. browse any Chinese web page with bold face, for example http://forum.ubuntu.org.cn/

4. print page

Expected results:
the emboldened titles shall be printed in bold face

Actual results:
both the titles and text are printed with the same weight. English bold characters look fine on the print though.
Bold Chinese characters prints ok with OpenOffice 3.1.1

[Micah Gersten (micahg)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, according to this report, you are not using the most recent version of this package for your Ubuntu release. Please upgrade to the most recent version and let us know if you are still having this issue. Thanks in advance.

[Qianqian Fang (fangq)]

Problem persisted in Jaunty and Firefox 3.5.3. The attached PDF file was generated by browsing http://cnbeta.com in firefox and printing as a PDF. All the sub-titles should have bold Chinese and Latin, but only the Latin face are bold.

[Qianqian Fang (fangq)]

Tested in Karmic and had the same problem.

[Qianqian Fang (fangq)]

update package from 3.0 to 3.5

[wlx (wangliangxu)]

Confirmed in karmic, firefox 3.5.3

[Aron Xu (happyaron)]

@Mozilla Team
Could somebody drop an eye on this bug?
I think it is an important thing for users to print their web pages correctly using firefox after all, :)

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Created an attachment (id=416048)
PDF Printout using Mozilla built-in PDF Generator

Upstreamed from launchpad:

Ubuntu 9.10, firefox 3.5.3 is unable to print bold Chinese sans characters.

Steps to duplicate:
1. if you set desktop language to Chinese, ttf-wqy-zenhei will be automatically installed as the default Sans Serif font, if you use other languages, simply install ttf-wqy-zenhei via atp-get first

2. in firefox, select Edit\Preference\Content\Font & Color, select the default font as "sans-serif"

3. browse any Chinese web page with bold face, for example http://forum.ubuntu.org.cn/

4. print page

Expected results:
the emboldened titles shall be printed in bold face

Actual results:
both the titles and text are printed with the same weight. English bold characters look fine on the print though.
Bold Chinese characters prints ok with OpenOffice 3.1.1

I tested this with Firefox 3.5.5 (Ubuntu) in a new profile, Firefox 3.6b4 (Ubuntu), Firefox 3.6b3 (Mozilla), and 3.7~a1~hg20091202r35410 (Ubuntu) with the same results.

[Daniel Holbert (dholbert)]

Does this work in Ubuntu 9.10 with older versions of Firefox?

[Daniel Holbert (dholbert)]

Also: does this problem affect print preview, too?

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

(In reply to comment #1)
> Does this work in Ubuntu 9.10 with older versions of Firefox?

We don't ship anything older than 3.5 with Ubuntu 9.10
Do you want me to try a Mozilla build?

(In reply to comment #2)
> Also: does this problem affect print preview, too?

No, I just tried in Firefox 3,6b4 (Ubuntu) and it shows bold in the Print Preview.

[Daniel Holbert (dholbert)]

(In reply to comment #3)
> We don't ship anything older than 3.5 with Ubuntu 9.10
> Do you want me to try a Mozilla build?

Yes please -- available here:
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

(In reply to comment #4)
> (In reply to comment #3)
> > We don't ship anything older than 3.5 with Ubuntu 9.10
> > Do you want me to try a Mozilla build?
>
> Yes please -- available here:
> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/

I tried 3.0.15 with the same result. Does the PDF appear to you without the bold?

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: https://bugzilla.mozilla.org/show_bug.cgi?id=532855
I'm going to mark it as Triaged and wait for upstream to work on this. Thanks for taking the time to make Ubuntu better! Please report any other issues you may find.

[Micah Gersten (micahg)]

Nothing for translations team to do so I am marking invalid.

[David Planella (dpm)]

Thanks for your work on this, Micah! I'm reopening the ubuntu-translation task as Triaged, since we use the project to have an overview of the issues related to native language support in Ubuntu. Closing the task might mean that it falls out of our radar.

[Daniel Holbert (dholbert)]

(In reply to comment #5)
> I tried 3.0.15 with the same result.

Ok -- assuming that this wasn't broken in Ubuntu9.04/Firefox3.0, then it appears that this is related to something changing from Ubuntu 9.04 --> 9.10, since it's broken in Ubuntu 9.10/Firefox3.0

Perhaps the specific font used here is new / updated in Ubuntu 9.10?

> Does the PDF appear to you without the bold?

I think so -- the bold lines and non-bold lines look pretty similar, yeah.

[Daniel Holbert (dholbert)]

(In reply to comment #0)
> 2. in firefox, select Edit\Preference\Content\Font & Color, select the default
> font as "sans-serif"

Is this step actually necessary? I think I just reproduced the bug without this step. (leaving Firefox's default font at 'serif')

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091202 Minefield/3.7a1pre

[Daniel Holbert (dholbert)]

Created an attachment (id=416113)
screenshot showing text that's supposed to be bold vs non-bold

Here's a screenshot from a PDF printout that I just made from the Ubuntu forum site. The first four characters on the first two lines are identical, though the first line's version is supposed to be bold.

The weights do indeed look the same to me. However, the first line's four-character-string is definitely wider as a whole than the second line's, as we'd expect with bold text.... (in this case it looks like the extra width just comes from extra whitespace between characters)

[Daniel Holbert (dholbert)]

Created an attachment (id=416130)
reduced testcase

[Daniel Holbert (dholbert)]

Created an attachment (id=416131)
PDF printout of reduced testcase

[Daniel Holbert (dholbert)]

Created an attachment (id=416134)
PDF printout of reduced testcase with font uninstalled [works]

Here's a printout of the reduced testcase, after I've uninstalled "ttf-wqy-zenhei". This works fine -- shows & prints chinese character in a different font, with a visible distinction between normal & bold.

So this appears to be something specific to ttf-wqy-zenhei.

[Daniel Holbert (dholbert)]

Vlad, do you know what could be causing this?

[Jfkthame (jfkthame)]

Is there any actual bold weight of the ttf-wqy-zenhei font? (I'm guessing there isn't.)

[Daniel Holbert (dholbert)]

Well, we do display the bold characters in the browser. Does that mean the font has a bold weight?

[Jfkthame (jfkthame)]

If there's no bold weight, we "fake" it by drawing twice with a slight offset. You should be able to tell the difference between this and a true bold face by zooming in; the fake bold will appear relatively less noticeable as the size increases. (Aside: we really should be using a better technique for this.)

I'm suspecting that it may be this fake bold effect that's not working in the PDF output.

[Daniel Holbert (dholbert)]

I can't really tell from zooming in -- is there a function e.g. "DrawFakeBold" that I could break on to tell if we're drawing the fake-bold characters?

[Jfkthame (jfkthame)]

According to fontconfig, there isn't a bold face of WenQuanYi Zen Hei, only a "medium" face:

jonathan:~$ fc-list | fgrep -i zen
WenQuanYi Zen Hei Mono,文泉驛等寬正黑,文泉驿等宽正黑:style=Medium,中等
WenQuanYi Zen Hei,文泉驛正黑,文泉驿正黑:style=Medium,中等
jonathan:~$

So what you're seeing in the browser is a "fake" bold. (Incidentally, it looks like we do this differently on Linux than we do on Mac and Windows.)

Apparently this isn't being handled in the print path. But I'm not sure yet whether to blame gecko, fontconfig, freetype, pango, cairo, or what....

[Jfkthame (jfkthame)]

Just to confirm, this is not in any way specific to the Chinese font mentioned; the same issue will appear with any font where the system only has a single weight, and the browser uses algorithmic "fake" bold.

For a simple example with Ubuntu 9.10, try

data:text/html,<p style="font-family:Furat;font-size:36pt;">hello world<br/><b>hello world</b></p>

Note that the Furat font (part of the Arabeyes collection, package ttf-arabeyes in Ubuntu) is only available in a single face. On screen and in Print Preview, the second line is clearly emboldened; but when printing to a PDF file, the glyphs are painted without the bold effect (but still with extra spacing).

[Karlt (karlt)]

cairo-ft-font uses FT_GlyphSlot_Embolden to do synthetic bold.
Bug 490475 comment 5 makes me suspect that the emboldened glyph outlines are not embedded.

There are two fonts embedded, one for each of regular and bold weights

/f-0-0 1 Tf
[<0102>-1<030304050406>-1<0307>]TJ
/f-1-0 1 Tf
0 -1.694444 Td
[<01>-83<02>-84<03>-84<03>-83<04>-83<05>-84<06>-84<04>-83<07>-84<03>-84<08>]TJ

but AFAIK the two fonts might be the same. I don't know whether there is any way to tell the PS/PDF interpreter to embolden one of these by any particular amount suitable to match the metrics from FT_GlyphSlot_Embolden.

The backend used on NT uses GDI to do synthetic bold, so I suspect the same issue may exist there. (If it doesn't then maybe that provides some clues on how to fix this for the FreeType backend.)

[Karlt (karlt)]

Created an attachment (id=418696)
PostScript output with Furat

PostScript output from:
data:text/html,<p style="font-family:Furat;font-size:36pt;">hello world<br/><b>hello world</b></p>

[Jfkthame (jfkthame)]

(In reply to comment #19)
> cairo-ft-font uses FT_GlyphSlot_Embolden to do synthetic bold.
> Bug 490475 comment 5 makes me suspect that the emboldened glyph outlines are
> not embedded.
>
> There are two fonts embedded, one for each of regular and bold weights
>
> /f-0-0 1 Tf
> [<0102>-1<030304050406>-1<0307>]TJ
> /f-1-0 1 Tf
> 0 -1.694444 Td
> [<01>-83<02>-84<03>-84<03>-83<04>-83<05>-84<06>-84<04>-83<07>-84<03>-84<08>]TJ
>
> but AFAIK the two fonts might be the same.

Yes, they are identical in the PostScript output. This suggests that the expectation is that emboldening is meant to be achieved via a painting effect rather than by actually modifying the glyph outlines. (That makes sense.)

> I don't know whether there is any
> way to tell the PS/PDF interpreter to embolden one of these by any particular
> amount suitable to match the metrics from FT_GlyphSlot_Embolden.

One way to create "synthetic bold" is to paint the glyphs with both stroke (of some appropriate thickness) and fill. This looks similar to the effect we're seeing on-screen in the browser on Linux (and is better than simply painting the filled glyphs twice with a slight offset). However, PostScript type42 fonts don't offer a PaintType value to directly implement this; it's either 0 (fill) or 2 (stroke), but not both together. So this approach would mean generating the text twice, using two versions of the font with different PaintType values.

And I don't know what metrics FT_GlyphSlot_Embolden is using; the glyph spacing we're seeing on the "bold" line seems rather excessive to me.

[Adrian Johnson (ajohnson-redneon)]

PS and PDF do not support synthetic fonts. To get synthetic bold when printing we need to embed the synthetic font outlines. GDI does provide the synthetic outlines (via GetGlyphOutline). I have not done any testing to check if FreeType provides the synthetic outlines (via FT_Outline_Decompose).

If FreeType does provide the outlines then it is just a case of forcing the fallback path in cairo when the font is synthetic. With FreeType fonts this is easy as we can check for the CAIRO_FT_OPTIONS_EMBOLDEN flag. On GDI this is harder as I don't know of any way to test if GDI is synthesising a font.

See also:

https://bugs.freedesktop.org/show_bug.cgi?id=21543

[Qianqian Fang (fangq)]

I am changing the bug title to "Synthetic emboldening/italic/italic-bold fails for single-styled fonts" as it appeared to be more serious than failed to print bold text in Firefox. As pointed out by several people in the mozilla-bugs #532855, this seems to be linked to a deficiency somewhere in the font rendering pipeline (can be freetype, fontconfig, pango ...). It does not only effect Chinese font bold faces, but also any fonts without bold/italic/italic bold faces. Because this bug is located in the rendering pipeline, I am not surprised to see that many graphics software are effected, including Scribus (1.3.3.13 or later), GIMP, Inkscape etc. In these software, if a font does not have dedicated bold/italic/italic bold faces, you may either not be able to select this style (Scribus, GIMP), or when you select it, it won't work (Inkscape).

I would like to suggest giving a higher priority to this bug.

[Aron Xu (happyaron)]

Raising importance from Medium to High for the reason Qianqian Fang had stated.

[Mrj-h (mrj-h)]

Created attachment 8379642
HTML page that makes use of a @font-face font, demonstrating that bold text is shown in print-previews but is normal weight in PDFs.

I think this is the bug I'm seeing in Firefox 27.0 for Linux.

The attached HTML page uses a single-weight CSS @font-face font sourced from Google Fonts. The second row of text, set "font-weight: bold", displays bold, print-previews bold, but prints normal weight.

Google Chrome prints the bold text correctly.

[Adrian Johnson (ajohnson-redneon)]

This has been fixed in cairo since 1.12.0

[Mrj-h (mrj-h)]

Thanks Adrian. I've read-up on Cairo and Azure, but still don't understand the implications of this switch for the problem I'm having with bold text printing of single-weight @font-face fonts. Is this bug still live, or should I file a new one, or is there something I can do to avoid the problem in current Linux Firefox versions?

[Murz (murznn)]

I have the same problem with displaying Bold fonts in PDF in Firefox 38.0 on Ubuntu 14.10, here is screenshots of PDF file (attached):
PDF view on tab: http://i.imgur.com/mptr8fd.png
Print preview: http://i.imgur.com/zr90wox.png

On Windows 8 all looks normally.

[Murz (murznn)]

Created attachment 8636477
132782.pdf

[Murz (murznn)]

On Google Chrome (Chromium) on same Ubuntu Linux system this PDF file displays normally.

[Daniel Holbert (dholbert)]

Murz: Thanks for the report -- but I think it's actually a different issue from this bug, though.

This bug is about bold text being rendered as non-bold (and only when printed), whereas it looks like your issue is about bold text being *completely missing* (based on your first screenshot), which is different and quite bad. (Also, it sounds like this bug may be fixed, per comment 24... not sure)

Could you file a new bug on the PDF rendering issue issue, here:
 https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=PDF%20Viewer
Thanks!

[Laszlo-bialis (laszlo-bialis)]

Created attachment 9005195
print prev vs pdf.png

[Laszlo-bialis (laszlo-bialis)]

Hi!

I've encountered the following issue on Ubuntu 16.04 x32, printing the following attachment: https://bug1318845.bmoattachments.org/attachment.cgi?id=8816724 the print preview looks ok, but when printing the file with a physical printer or to a .pdf file the fonts from the bold column don't seem to be bolded anymore (see also "print prev vs pdf.png" attachment), whereas the fonts from the column header seem to bee bold even after print.

Is the above issue related to this bug or should I file a new one?

[Daniel Holbert (dholbert)]

That sounds like this bug, I think.

[Daniel Holbert (dholbert)]

Given that this bug was from over a decade ago, and we've done substantial printing improvements & re-investigations over the past few years which could conceivably have fixed this, and this hasn't come up recently, I think we can consider this "worksforme" at this point.

(It sounds like comment 24 had a strong suspicion that there was a particular cairo change that would've fixed this over 5 years ago, too; and this has been mostly silent since then.)

If anyone can still reproduce a version of this bug (bold text missing on Linux), it's probably best to track that in a new bug at this point, since there's a good likelihood it'd be a new/different issue from what was originally going on here.