Bug 31878 - pdf backend produces wrong glyph instead of euro sign
Summary: pdf backend produces wrong glyph instead of euro sign
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.10.1
Hardware: Other All
: medium normal
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-23 15:55 UTC by Jan Kümmel
Modified: 2010-11-28 04:48 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
test program (900 bytes, text/x-csrc)
2010-11-23 15:55 UTC, Jan Kümmel
Details
png (1.55 KB, image/png)
2010-11-25 14:08 UTC, Jan Kümmel
Details
pdf (5.13 KB, application/pdf)
2010-11-25 14:08 UTC, Jan Kümmel
Details
Linux Biolinum O (375.06 KB, application/octet-stream)
2010-11-26 13:24 UTC, Jan Kümmel
Details
backtrace (2.31 KB, text/plain)
2010-11-27 12:25 UTC, Jan Kümmel
Details

Description Jan Kümmel 2010-11-23 15:55:09 UTC
Created attachment 40523 [details]
test program

€ signs are drawn correctly on image surfaces, but replaced by a rectangle when drawn on a pdf surface. 

Both the cairo text functions and pango are affected.

Steps to reproduce:
1. gcc euro_sign.c `pkg-config --cflags --libs cairo` -o euro_sign
2. ./euro_sign
3. compare euro_sign.png and euro_sign.pdf
Comment 1 Adrian Johnson 2010-11-24 01:00:39 UTC
It works for me.

Can you attach your PDF and PNG files.
Comment 2 Jan Kümmel 2010-11-25 14:08:20 UTC
Created attachment 40574 [details]
png
Comment 3 Jan Kümmel 2010-11-25 14:08:42 UTC
Created attachment 40575 [details]
pdf
Comment 4 Jan Kümmel 2010-11-25 14:38:01 UTC
argh, sorry, I forgot to mention that I use git master of cairo.
Comment 5 Jan Kümmel 2010-11-25 15:42:12 UTC
thanks to git bisect, I found out that commit af3b550bc186361a0b6a779df0fc57799c3f163d broke it for me.

    PDF: Add support for latin subsets
    
    Add support for Type 1 and TrueType latin subsets.
    
    CFF latin subsets are not yet implemented.


Is this a bug or a simply a consequence of those not yet implemented CFF latin subsets?
Comment 6 Adrian Johnson 2010-11-26 03:27:21 UTC
I can reproduce it now. It needs to be a Truetype font to trigger the bug.

Fixed in master:
http://cgit.freedesktop.org/cairo/commit/?id=47b81b9fea50328bd089db4e5ef8dcb1b181515b
Comment 7 Jan Kümmel 2010-11-26 13:04:32 UTC
Fix http://cgit.freedesktop.org/cairo/commit/?id=47b81b9fea50328bd089db4e5ef8dcb1b181515b works for me with "Bitstream Vera Sans Mono", but not for the opentype version of "Linux Biolinum O" (http://www.linuxlibertine.org/index.php?id=86&L=1).

For "Linux Biolinum O", this issue was introduced by http://cgit.freedesktop.org/cairo/commit/?id=ef60650bd6e0b3a354c85dc2e1be8550be6f7c91
Comment 8 Jan Kümmel 2010-11-26 13:24:38 UTC
Created attachment 40591 [details]
Linux Biolinum O
Comment 10 Jan Kümmel 2010-11-27 12:14:44 UTC
with euro_sign.c (replaced "serif" by "Linux Biolinum O"), I get

euro_sign: cairo-cff-subset.c:1549: cairo_cff_font_get_sid_for_winansi_char: Assertion `font->euro_sid >= 391' failed.


(font->euro_sid is 0)
Comment 11 Jan Kümmel 2010-11-27 12:25:58 UTC
Created attachment 40604 [details]
backtrace
Comment 12 Jan Kümmel 2010-11-27 13:41:05 UTC
The assertion failure goes away when I use CAIRO_FONT_WEIGHT_NORMAL instead of CAIRO_FONT_WEIGHT_BOLD. I dont have the bold version of "Linux Biolinum O" installed at the moment. I guess the assertion error is only triggered when bold is emulated (by freetype?).
Comment 13 Adrian Johnson 2010-11-27 17:18:33 UTC
Yes it was using a synthetic font which embeds a CFF fallback font. Fixed in master.
Comment 14 Jan Kümmel 2010-11-28 04:48:34 UTC
works for me, too. Thanks a lot!


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.