Created attachment 25416 [details]
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.
Created attachment 25417 [details]
PNG output from testcase.c
Created attachment 25418 [details]
PDF output from testcase.c
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.
Might this be a solution? The LOGFONT structure tells us whether the font ought to be bold and/or italic. The 'head' table  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.
Fixed in git master:
We synthesize bold in the FreeType backend too. Do we need similar code there?
(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:
Ah, right. Thanks.