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

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.

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

Also: does this problem affect print preview, too?

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

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

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

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

(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

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)

Created an attachment (id=416130)
reduced testcase

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

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.

Vlad, do you know what could be causing this?

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

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

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.

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?

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

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

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

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>

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

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

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.

This has been fixed in cairo since 1.12.0

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?

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.

Created attachment 8636477
132782.pdf

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

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!

Created attachment 9005195
print prev vs pdf.png

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?

That sounds like this bug, I think.

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.