[cairo] Quartz bug with right-to-left and bidirectional text

[Ben Schmidt]

OK. Take some of that back.

It looks like it may be a Pango bug after all. Looks like Pango must
conditionally compile different code depending on whether the Cairo
Quartz backend is present or not. I had presumed it just linked to the
library and made the same API calls regardless of the Cairo backend.

I have managed to come up with a small test case. It's a pretty dirty
hack; it doesn't clean up after itself at all properly or anything like
that. It's kinda just relevant chunks of code from Vim, API docs and
examples all cobbled together with whatever variables seemed necessary
to make it work. I have barely any idea how it works. But it does work,
and it does expose the bug, and with few lines of code.

It seems the bug is that pango_shape ignores analysis.level of a Pango
itemisation, so this cannot be set to force text to be treated as
un-embedded and therefore force left-to-right rendering. The bug only
occurs when the Cairo Quartz backend is compiled in, though.

I suppose it's a somewhat unusual use case, but it is an important one,
and certainly the rendering should be backend-independent.

I'd appreciate it if someone could help ascertain whether this is indeed
a Pango bug (in which case I'll hop over and report it there) or a Cairo
bug. If it's a Cairo bug, I'd love it if we could get it into the bug
tracker and if it supports it, have me CCed when any progress is made on
it.

Test case attached (includes non-ASCII UTF-8 text), as well as
screenshots of the rendering with and without the Quartz backend.

Cheers,

Ben.



Ben Schmidt wrote:
> G'day, Vlad,
> 
> Yes, Pango is being used, but the problem goes away as soon as Cairo is
> compiled without the Quartz backend and just uses the regular X backend,
> so it is definitely a Cairo problem.
> 
> I suspect the problem is that some Quartz API is smarter than we want it
> to be, and is adding some kind of bidi support that we don't want. IIRC,
> it renders single glyphs just fine; it's only when multiple glyphs are
> rendered at a time that they get messed up.
> 
> What kind of test case are you after? I'm not really a Cairo/Pango/GTK
> programmer, but just a user, so I might struggle to provide more. The
> images and text file I provided at the link I gave form a pretty small
> test case. I realise they require Vim as I formulated them, but they
> probably actually don't--I suspect anything that renders the provided
> text file in a window would show up the problem. And a tester need know
> nothing about Hebrew--if the rendering of the Quartz backend can be made
> to match that of the non-Quartz backend, it should indicate the bug is
> fixed.
> 
> Cheers,
> 
> Ben.
> 
> 
> 
> Vladimir Vukicevic wrote:
>> Hey Ben,
>>
>> Can you provide a testcase for this?  The quartz surface backend itself 
>> just deals with positioned glyphs; if you're using the cairo toy font 
>> backend, I don't think it provides any guarantees about support for RTL 
>> or bidi text.  Are you using pango?
>>
>>     - Vlad
>>
>> On Oct 27, 2008, at 5:49 AM, Ben Schmidt wrote:
>>
>>> Hi,
>>>
>>> The Quartz backend, presumably because of bidirectional support in 
>>> Quartz which
>>> doesn't behave as Cairo expects, renders right-to-left and 
>>> bidirectional text
>>> differently to other Cairo backends. Since Cairo output should be 
>>> independent of
>>> the backend, this is of course a bug.
>>>
>>> I noticed it using a GTK+2 GUI version of Vim which I use for reading 
>>> and writing
>>> Hebrew text. When the Cairo Quartz support was enabled, the output 
>>> went wrong! I
>>> requested a +no_quartz variant to the MacPorts Cairo installation and 
>>> attached
>>> screen shots and a text file to demonstrate the bug here:
>>>
>>> https://trac.macports.org/ticket/16778
>>>
>>> It would be good if this could be added to your bug tracker and CC me 
>>> regarding
>>> changes/progress. Or if this is a known bug, if you could CC me on 
>>> that, it'd be
>>> great. I did a quick search of the bug database and couldn't spot it 
>>> there
>>> already, though. I don't intend to stay subscribed to this list for 
>>> more than a
>>> few days to field replies to this report.
>>>
>>> Thanks very much.
>>>
>>> Ben.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: small.c
Url: http://lists.cairographics.org/archives/cairo/attachments/20081123/0491edf9/attachment-0001.c 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: small_no_quartz.png
Type: image/png
Size: 8808 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20081123/0491edf9/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: small_quartz.png
Type: image/png
Size: 9647 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20081123/0491edf9/attachment-0003.png