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

[Behdad Esfahbod]

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.

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.


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


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