[cairo] nquartz line stroking, was Re: Joost-Mac font issues.

[Baz]

On 14/02/07, Andrei Kolev <akolev at theveniceproject.com> wrote:
>
>
> On 12.02.2007, at 10:45, Daniel Salber wrote:
>
>
> There's still the clock display that we need sorted out. Can you come up
> with a simple test case that we can provide as a bug reduction?
> Hi Daniel,
>
> I hope I fixed the clock display bug. Will commit in a minute, please take a
> look to make sure this is the proper way of fixing it. Here is the
> situation:
>
> When drawing the clock, we use 0.52 scaling factor for the graphic context.
> The code for mac-cairo path strokes is in the _cairo_nquartz_surface_stroke
> function in the
> mozilla/gfx/cairo/cairo/src/cairo-nquartz-surface.c file.
> The line width is taken from one of it's arguments, cairo_stroke_style_t
> *style  , style->line_width. This value, however, is not taking into account
> the context scaling. We have the context matrix as one of the arguments (*
> ctm) and we can take the scaling from it:
>
> double scale = sqrt(ctm->xx *ctm->xx + ctm->xy *ctm->xy);
>
> Then the actual scale is style->line_width * scale.
>
> Now the clock displays correctly. This should fix other possible line width
> scaling issues.

I'm not sure about this. That's just the x scale, but the ctm can
scale differently on each axis, and the line width for
CGContextSetLineWidth is supposed to be in user units, you're
transforming to device units there. I believe that the fallback
mechanism, used on other surfaces, applies the ctm internally to each
line segment produced when stroking the path in order to get this
right (but don't quote me on that, best ask Carl). The quartz
equivalent is just to use the ctm of the CGContext.

So, shouldn't CGContextConcatCTM be being called somewhere? It looks
like the ctm isn't used here at all.

CC'ing the cairo list in case anyone wants to comment on this. I'll be
unable to test the code until tomorrow night.

> Other possible solution is to expect the line width in the
> cairo_stroke_style structure to be scaled properly on input, but I doubt
> that it should contain scaled value -- it will be difficult kept in sync
> when scaling.
>
> Regards,
> Andrei

Cheers,
Baz