Summary: | [cairo] Rendering with PANGO_GRAVITY_EAST leads to different results with image and vectoriel buffer (pdf) | ||
---|---|---|---|
Product: | cairo | Reporter: | tristan <kiwitargetgranule> |
Component: | pdf backend | Assignee: | Adrian Johnson <ajohnson> |
Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | freedesktop |
Version: | 1.8.6 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
pangocairo_testcase_and_resultingfiles
Same behaviour with compilation with git trunk |
Please attach each file as a separate attachment. This looks very similar to bug 10118. Pango is passing invalid glyph positions for glyphs 2 to 6. {index = 2173, x = 1000.0000000000001, y = -939.99999999999989} {index = 2240, x = 103399.90625, y = -939.99999999999989} {index = 2186, x = 205799.8125, y = -939.99999999999989} {index = 2307, x = 308199.71875, y = -939.99999999999989} {index = 2329, x = 410599.625, y = -939.99999999999989} {index = 12655, x = 512999.53125, y = -939.99999999999989} Adrian, so you can reproduce this? Pango doesn't make up extents. One can see what's wrong by checkout output of cairo_scaled_font_extents() and cairo_scaled_font_glyph_extents(). cairo_show_glyphs is called 3 times. font extents: ascent: 90.000000 descent: 30.000000 height: 129.000000 max_x_adv: 0.000000 max_y_adv: 129.000000 glyph extents: xbearing: 10.906250 ybearing: -42.750000 width: 78.093750 height: 85.500000 x_adv: 102399.906250 y_adv: 0.000000 glyph extents: xbearing: 13.000000 ybearing: -32.046875 width: 74.000000 height: 64.093750 x_adv: 102399.906250 y_adv: 0.000000 glyph extents: xbearing: 8.593750 ybearing: -30.906250 width: 82.703125 height: 61.796875 x_adv: 102399.906250 y_adv: 0.000000 font extents: ascent: 90.000000 descent: 30.000000 height: 129.000000 max_x_adv: 0.000000 max_y_adv: 129.000000 glyph extents: xbearing: 8.906250 ybearing: -36.859375 width: 82.109375 height: 73.703125 x_adv: 102399.906250 y_adv: 0.000000 glyph extents: xbearing: 19.000000 ybearing: -38.046875 width: 61.890625 height: 76.093750 x_adv: 102399.906250 y_adv: 0.000000 font extents: ascent: 85.937500 descent: 14.062500 height: 100.000000 max_x_adv: 0.000000 max_y_adv: 100.000000 glyph extents: xbearing: 11.828125 ybearing: -50.203125 width: 101.187500 height: 100.390625 x_adv: 102400.000000 y_adv: 0.000000 x_adv: 102399.906250... Can you set a breakpoint in _cairo_ft_scaled_glyph_init() and see what's going wrong? at _cairo_scaled_glyph_set_metrics (scaled_glyph, &scaled_font->base, &fs_metrics); fs_metrics has the value: $6 = {x_bearing = -0.32046875000000002, y_bearing = 0.13, width = 0.64093750000000005, height = 0.73999999999999999, x_advance = 0, y_advance = 1023.9990625} The y advance is coming from: fs_metrics.y_advance = DOUBLE_FROM_26_6 (glyph->linearVertAdvance) * y_factor; where y_factor is 0.01 and *glyph is $8 = {library = 0x9f6bec8, face = 0x9faf368, next = 0x0, reserved = 0, generic = {data = 0x0, finalizer = 0}, metrics = {width = 4102, height = 4736, horiBearingX = 1197, horiBearingY = 4883, horiAdvance = 6400, vertBearingX = -2051, vertBearingY = 832, vertAdvance = 6400}, linearHoriAdvance = 6553594, linearVertAdvance = 6553594, advance = {x = 6400, y = 0}, format = FT_GLYPH_FORMAT_OUTLINE, bitmap = {rows = 0, width = 0, pitch = 0, buffer = 0x0, num_grays = 0, pixel_mode = 0 '\0', palette_mode = 0 '\0', palette = 0x0}, bitmap_left = 0, bitmap_top = 0, outline = {n_contours = 1, n_points = 59, points = 0x9fd7c08, tags = 0x9fd80d0 "\001", contours = 0x9fd7bf8, flags = 0}, num_subglyphs = 0, subglyphs = 0x0, control_data = 0x0, control_len = 0, lsb_delta = 0, rsb_delta = 0, other = 0x0, internal = 0x9fb21b0} and face is $9 = {num_faces = 1, face_index = 0, face_flags = 2585, style_flags = 2, num_glyphs = 2398, family_name = 0x8708fe0 "FreeSerif", style_name = 0x8709000 "Bold", num_fixed_sizes = 0, available_sizes = 0x0, num_charmaps = 3, charmaps = 0x8709050, generic = { data = 0x86e0b00, finalizer = 0xb7c1abd0}, bbox = {xMin = -560, yMin = -488, xMax = 1860, yMax = 1173}, units_per_EM = 1000, ascender = 900, descender = -300, height = 1290, max_advance_width = 1880, max_advance_height = 1290, underline_position = -125, underline_thickness = 50, glyph = 0x8709108, size = 0x8709248, charmap = 0x8709080, driver = 0x86c2f90, memory = 0x86c2eb0, stream = 0x8706338, sizes_list = {head = 0x8709380, tail = 0x8709380}, autohint = {data = 0x0, finalizer = 0}, extensions = 0x0, internal = 0x87066a8} Can you figure out which font, which version of the font, and which version of freetype this is? pmap'ing the process may help. Thanks. The font is FreeSerifBold.ttf on Debian Lenny. You can obtain the exact same font from http://ftp.us.debian.org/debian/pool/main/t/ttf-freefont/ttf-freefont_20080323-3_all.deb Use ar to unpack the deb. The freetype version is 2.3.7. This page has a link to the exact version and Debian specific patches: http://packages.debian.org/lenny/libfreetype6 Fixed: commit 4232719af968ed05636fe34f2ffe2520dc02d737 Author: Behdad Esfahbod <behdad@behdad.org> Date: Sat May 30 23:03:55 2009 -0400 [ft] Fix vertical advance metrics of bitmap fonts (#21985) diff --git a/src/cairo-ft-font.c b/src/cairo-ft-font.c index 8a6b4a2..6c64284 100644 --- a/src/cairo-ft-font.c +++ b/src/cairo-ft-font.c @@ -1979,7 +1979,7 @@ _cairo_ft_scaled_glyph_init (void *abstract_font, if (hint_metrics || glyph->format != FT_GLYPH_FORMAT_OUTLINE) fs_metrics.y_advance = DOUBLE_FROM_26_6 (metrics->vertAdvance) * y_factor; else - fs_metrics.y_advance = DOUBLE_FROM_26_6 (glyph->linearVertAdvance) * y_factor; + fs_metrics.y_advance = DOUBLE_FROM_16_16 (glyph->linearVertAdvance) * y_factor; } } Created attachment 26340 [details]
Same behaviour with compilation with git trunk
try patch with
GLIB_VERSION:2.20.1
PANGO_VERSION:1.24.2
CAIRO_VERSION:1.9.1
same behaviour
Adrian, can you check too? (In reply to comment #10) > Created an attachment (id=26340) [details] > Same behaviour with compilation with git trunk > > try patch with > GLIB_VERSION:2.20.1 > PANGO_VERSION:1.24.2 > CAIRO_VERSION:1.9.1 > same behaviour > Works for me. The PDF you attached was created with cairo 1.8.6. |
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.
Created attachment 26281 [details] pangocairo_testcase_and_resultingfiles When rendering the following japanese utf-8 layout "おろしポン酢" with PANGO_GRAVITY_EAST, the pdf result is just the first char (CASE define) while the image result is the entire string.