[cairo] [PATCH] Improve handling of degenerate font matrices

[Andrea Canciani]

On Mon, Feb 7, 2011 at 11:38 PM, Behdad Esfahbod <behdad at behdad.org> wrote:
> On 02/07/11 12:20, Andrea Canciani wrote:
>> On Mon, Feb 7, 2011 at 5:40 PM, Behdad Esfahbod <behdad at behdad.org> wrote:
>>> On 02/07/11 04:51, Andrea Canciani wrote:
>>>
>>>>> I took a quick look to see if we can completely remove scale_inverse.  It may
>>>>> be possible, but I check the current uses and they are mostly harmless, so its
>>>>> not a big deal.
>>>>
>>>> I had a commit performing that. It should be quite trivial as soon as
>>>> I manage to get rid of it in cairo-user-font.c
>>>
>>> I have a feeling that we are using the wrong matrix there.  I have a feeling
>>> that we should be using ctm_inverse, not scale_inverse there, since our target
>>> is to have user-space extents.
>>
>> It could be.
>
> I've studied the code again, and no, it's correct.  More below.
>
>
>> I just started looking at the code around it and noticed that
>> _cairo_recording_surface_get_bbox probably contains the problem pointed out in
>> http://lists.cairographics.org/archives/cairo/2008-May/014152.html
>>
>> _recording_surface_get_ink_bbox seems to avoid that problem.
>
> No.  get_bbox calls get_ink_bbox.  The problem lies in analysis-surface.c's
> design of extent collection.  If you are asking for an operation's extent
> without passing down the ctm, that's the bug.  And it's all over that code.

I see. I expected _cairo_analysis_surface_set_ctm (called by
_recording_surface_get_ink_bbox) to do the trick.

>
> That said, our scaled-font code also has a variety of this problem.  But it's
> less severe since rotated font matrices are not that useful.

Yes, this problem is not strictly related to the degenerate matrix handling,
so it can be tackled independently.

>
>
>> I expected the user-font code to record a glyph in font space and then transform
>> it when replaying the recorded surface,
>
> That would have been really nice... Except that with things like hinting, we
> can't do that.  We have to record/render it in real device space :(.
>
>
>> but I see that the documentation
>> specifies that users are allowed to change the matrix to draw directly in user
>> space. This means that (if the scale matrix is degenerate) glyphs can have
>> infinite font-space extents, which breaks the assumptions I was making.
>
> Right.  But that can also be called a user error...
>
> Ok, the reason for the whole extent_scale matrix in cairo-user-font is that we
> record in device space, but _cairo_scaled_glyph_set_metrics() expects numbers
> in font space, just to convert them to user space itself.  If we changed that
> function (or added a new one) to take extents in user space directly, we can
> clean up things a bit.  But then need to add ctm_inverse to scaled-font or
> user-scaled-font.  No big deal since at least for now ctm is always invertible.

Wouldn't it be possible to keep the font extents in device space?
This would completely avoid the ctm and font_matrix inversion problem, except
when the user queries the font extents, in which case we can probably return
an error.

Andrea

>
>
>>>> I'll try to fix the doc and maybe inline
>>>> a couple of comments expaining the geometrical meaning of the
>>>> computations.
>>>
>>> Feel free to rename it, and remove the case of x_basis==FALSE as the output
>>> looks inverted and wrong for that case, and we don't currently use that case
>>> anyway (may do in the future for vertical text).
>>
>> You mean for laying out vertical text in the toy font API?
>
> Not exactly sure when we would need it.
>
> behdad
>
>> Andrea
>>
>