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

[Andrea Canciani]

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 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. It should be
possible to fix _cairo_recording_surface_get_bbox so that it only calls
_recording_surface_get_ink_bbox when needed (i.e. when the transformed
bbox is not tight).

I expected the user-font code to record a glyph in font space and then transform
it when replaying the recorded surface, 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.

>
>
>>>> I don't completely understand what
>>>> _cairo_matrix_compute_basis_scale_factors is supposed to do.
>>>> It is only used in font code and its documentation seems to be font-oriented
>>>> and incorrect. Was it supposed to be an SVD?
>>>
>>> The Return value docs are wrong for sure, but the rest is correct.  No, it's
>>> not SVD.  It's mostly used to compute det(M) / |M*(1,0)'|, which is the line
>>> height of the font in user space when applied on the font matrix.
>>
>> Ok, the geometrical insight was very useful (it also explains why 0,0 should
>> be a correct answer when det(M)==0).
>
> For the div-by-zero case you're right.  For the other case it doesn't make
> sense.  The det(M)==0 path needs to be removed.  If we want to get correct
> glyph advance with 1rank matrices we need non-zero x_scale out of that
> function I guess.

Uh, sure, if the basis_scale_factors are used to compute the advance, the
"major" result should always be computed as M v'.

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

Andrea