[cairo] glyph extents

[Jonathan Kew]

On 16 Feb 2009, at 16:16, Bill Spitzak wrote:

>
> 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.

This could be a factor, but given that we have problems on both the  
left and right edges of glyphs, it's clear that this is not the main  
issue. The underlying problem is that Windows GDI is reporting a glyph  
"black box" that does not allow for ClearType smoothing pixels, and we  
need to add those in at some level.

>
>
> 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.

Note that such clipping occurs internally within Cairo, this is not  
just an issue for Cairo clients that may wish to clip to the glyph  
extents. The screenshot at https://bug445087.bugzilla.mozilla.org/attachment.cgi?id=359258 
  shows the results of a Cairo test program (also attached to that  
bug). The clipping seen in this screenshot is happening entirely  
within cairo_show_glyphs() and the internal Cairo functions this uses.


> 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.

But the GDI function concerned is returning *smaller* extents than are  
needed to include the "partially-covered" pixels that ClearType  
produces. So we need to do something about this (within Cairo), either  
by modifying those extents at source, or allowing for the overflow any  
time the extents are used.


>
> 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?

Well, if it's going to automatically clip glyph-painting operations at  
all (as cairo-surface-fallback.c does, for example), it would clearly  
need to account for the extent of the blur.

Maybe that particular example of clipping could be removed altogether  
(I haven't tried that), but the general problem remains. Suppose a  
client using such "blurred text" wants to invalidate the appropriate  
screen rectangle when the text changes, so that the proper area will  
be repainted; clearly it needs to know the true extent of "touched"  
pixels, including the effect of the blur filter.

JK