Bug 28583 - PDF glyph_path() inaccuracies
Summary: PDF glyph_path() inaccuracies
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.8.6
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
Depends on:
Reported: 2010-06-17 08:13 UTC by Ian Britten
Modified: 2018-08-25 13:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Sample C program that reproduces the glyph_path() PDF problem (5.47 KB, text/x-csrc)
2010-06-17 08:13 UTC, Ian Britten
Resulting PDF output (1.30 KB, image/png)
2010-06-17 08:14 UTC, Ian Britten
Good (expected) Image output (1.68 KB, image/png)
2010-06-17 08:15 UTC, Ian Britten

Description Ian Britten 2010-06-17 08:13:38 UTC
Created attachment 36336 [details]
Sample C program that reproduces the glyph_path() PDF problem

There appears to be some inaccuracies from cairo_glyph_path(), when written to PDF.  Note the problem may only be noticeable when the text is tiny/small (which is the case I encountered).

Use cairo_glyph_path() to convert a glyph to a path, then stroke() it with a thick lineweight.  Then, do a show_glyphs() directly after (Different colour, but same position/size/etc).  In the resulting PDF, the 'halo' outline isn't evenly aligned around the text, as would be expected.  However, rendering the same data to an image surface produces the expected output.

Attached is a stand-alone test program that demonstrates the problem.  The single glyph is rendered at the centre of the output files.
[ WARNING - It produces a *huge* PNG for comparison, in addition to the PDF.  Disable the PNG if desired ]

This has already been investigated some by Chris Wilson (ickle) on IRC.  He has triaged the problem some, and says: "... mention that I think it is due to the Tm matrix".  He also suggested CC'ing Adrian
Comment 1 Ian Britten 2010-06-17 08:14:25 UTC
Created attachment 36337 [details]
Resulting PDF output
Comment 2 Ian Britten 2010-06-17 08:15:04 UTC
Created attachment 36338 [details]
Good (expected) Image output
Comment 3 Jiri Drbalek 2018-05-22 09:19:37 UTC
I've tried the test program as I was after similar bug. I could reproduce it on my Gentoo system, but not with the latest upstream Cairo.

The reason why Gentoo version was causing the bug is the following Gentoo-specific patch.

--- cairo-1.7.6-orig/src/cairo-ft-font.c	2008-09-29 21:43:13.000000000 +0100
+++ cairo-1.7.6/src/cairo-ft-font.c	2008-09-29 21:52:19.000000000 +0100
@@ -1705,7 +1705,9 @@
 	options->base.subpixel_order = other->base.subpixel_order;
-    if (options->base.hint_style == CAIRO_HINT_STYLE_DEFAULT)
+    options->base.hint_style = CAIRO_HINT_STYLE_DEFAULT;
+    if (other->base.hint_style != CAIRO_HINT_STYLE_DEFAULT)
 	options->base.hint_style = other->base.hint_style;
     if (other->base.hint_style == CAIRO_HINT_STYLE_NONE)

Therefore the problem is related to hinting. I could fix the test program by disabling hinting:

diff --git a/halo_test.c b/halo_test.c
index cd12925..8863cff 100644
--- a/halo_test.c
+++ b/halo_test.c
@@ -90,7 +90,7 @@ int main(int argc, char *argv[])
         FT_New_Face(ftLib, "/usr/share/fonts/liberation-fonts/LiberationMono-Regular.ttf",
                     0, &ftFace);
         cairo_font_face_t *cFace = cairo_ft_font_face_create_for_ft_face(
-                ftFace, 0);
+                ftFace, FT_LOAD_NO_HINTING);

         // Font info
         const double userSize = 0.0030594270330026917;
Comment 4 GitLab Migration User 2018-08-25 13:30:24 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/38.

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.