[cairo] glyph extents

[Bill Spitzak]

Jonathan Kew wrote:
> I'd like to ask for clarification of the glyph extents returned by 
> cairo_scaled_font_glyph_extents() (and related APIs that are relying on 
> the same font data). There is an issue here for the Windows back-end 
> that leads to poor visual results in certain situations.

The errors shown in the screen shots attached to this bug:

>   https://bugzilla.mozilla.org/show_bug.cgi?id=445087  (clipped drawing 
> occurs within Cairo)

Are *far* larger than I think can be explained by ClearType.

In most examples an entire vertical line has been clipped from the 
right. Thus the error is big enough that it includes the entire 
3-subpixel wide line, and not just the pixel outside including the color 
balancing filter overlay. The explanation may be that you are truncating 
all the floating point to integers, thus moving the edges of your boxes 
left (and up) all the time, so that the mistakes are always on the right.

I'm not sure why you are always clipping tightly to the text before 
drawing. It seems a better approach is to believe what Cairo says the 
extent is and not clip at all. This seems to be a far too slow way of 
updating, if there was no clipping and you just drew the graphics I 
would think Cairo would go a lot faster.

I think extents should return the dimensions of a rectangle that if 
drawn with Cairo would appear to cover the image. So the 
partially-covered pixels in the greyscale example are indicated by 
non-integer dimensions. I suspect any real implementation will return 
larger extents than this rectangle.

Cleartype applies a filter to the 3x subsampled image. I don't think 
filtering can be counted. Some filters have extremely wide extents, for 
instance what should Cairo do if the ability to pass the rendering 
through a blur is implemented?