Bug 21543 - wrong font weight for some Win32 fonts in PDF output
Summary: wrong font weight for some Win32 fonts in PDF output
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.8.6
Hardware: All Windows (All)
: medium normal
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-04 07:33 UTC by Elmar Braun
Modified: 2010-11-22 13:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
testcase.c (2.11 KB, text/plain)
2009-05-04 07:33 UTC, Elmar Braun
Details
test.png (5.63 KB, image/png)
2009-05-04 07:34 UTC, Elmar Braun
Details
test.pdf (43.12 KB, application/pdf)
2009-05-04 07:35 UTC, Elmar Braun
Details

Description Elmar Braun 2009-05-04 07:33:15 UTC
Created attachment 25416 [details]
testcase.c

PDF output on Windows (using the cairo_win32_font_face_... functions) emits some (not all) fonts with a non-bold font weight, even though the font was created as bold, and shows up bold on other surfaces.

A test case is attached to this bug report. It prints a four lines. The first line is Arial non-bold; the second is Arial bold; the third is "Arial Unicode MS" non-bold; the fourth is "Arial Unicode MS" bold. In the PNG output, the second and fourth line are visibliy bold. In the PDF output, only the second line is bold. The fourth is incorrectly not bold.
Comment 1 Elmar Braun 2009-05-04 07:34:04 UTC
Created attachment 25417 [details]
test.png

PNG output from testcase.c
Comment 2 Elmar Braun 2009-05-04 07:35:00 UTC
Created attachment 25418 [details]
test.pdf

PDF output from testcase.c
Comment 3 Adrian Johnson 2009-05-05 06:43:48 UTC
As there is no Arial Unicode Bold font, Windows synthesises the bold from Arial Unicode. In the PDF backend the fonts are embedded by obtaining the TrueType font data from Windows. The problem here is that when the TrueType font data for a synthetic font is requested, Windows provides the font data for the base font that was used to create the synthetic font.

Testing your example with TrueType font subsetting in cairo disabled produces the correct result since it forces cairo to embed a new font created from the outlines returned by GetGlyphOutline(). This suggests that disabling TrueType subsetting for synthetic fonts would be a reasonable solution. However I am unable to find any way of determining if the selected font is synthetic.
Comment 4 Elmar Braun 2009-05-06 01:39:58 UTC
Might this be a solution? The LOGFONT structure tells us whether the font ought to be bold and/or italic. The 'head' table [1] in the TrueType font data contains a bitfild that tells us whether the font is bold and/or italic. Compare the two, and disable 'TrueType font subsetting' in case of mismatch.

[1] http://www.microsoft.com/typography/OTSPEC/head.htm
Comment 6 Behdad Esfahbod 2010-11-22 07:52:26 UTC
We synthesize bold in the FreeType backend too.  Do we need similar code there?
Comment 7 Adrian Johnson 2010-11-22 12:53:08 UTC
(In reply to comment #6)
> We synthesize bold in the FreeType backend too.  Do we need similar code there?

Already implemented in the previous commit:

http://cgit.freedesktop.org/cairo/commit/?id=7f0029c31e15dfd34f57bdeca18f27e9e7b8f9aa
Comment 8 Behdad Esfahbod 2010-11-22 13:10:17 UTC
Ah, right.  Thanks.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.