[cairo-bugs] [Bug 10067] quartz surface does not use device glyph extents

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=10067





------- Comment #11 from Brian.Ewins at gmail.com  2007-03-15 14:47 PST -------
On the pixel snapping - yes, its only something you'd do with glyph surfaces.

I've confirmed that the bug is in _cairo_atsui_font_text_to_glyphs, I printed
out what the x coord is set to and the  x advance; summing these should give
the next x (roughly). The x advances are being calculated from the glyph
metrics, independently of the positions, and summing the advances is how the ft
font backend calculates the positions; so we should get comparable numbers. 

This results look correct in the text-antialias-none test printing "cairo":

0 + 8 = 8 (this should be rougly the same value as the start of next line)
7.61719 + 3 = 10.6172
10.9512 + 8 = 18.9512
18.3047 + 7 = 25.3047
24.9023 + 7 = 31.9023

but in the text-pattern test, with a non-identity ctm, its all gone wrong:
3.2 + 7 = 10.2
17.275 + 8 = 25.275 
32.9625 + 3.5 = 36.4625
40.075 + 5.5 = 45.575
50.0375 + 8 = 58.0375
In this case I've scaled x 2, but it looks like the x positions on the left
have the advance added twice. Scaling x4:
1.6 + 3.5 = 5.1 (1.6 + 4 * 3.5 = 15.6 - matches next line)
15.675 + 4 = 19.675 (15.675 + 4 * 4 = 31.675, ditto)
31.3625 + 1.75 = 33.1125
38.475 + 2.75 = 41.225
48.4375 + 4 = 52.4375

... so the scale causing us to see multiples of the advance. Most likely the
style includes the normally-identity ctm somewhere.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.