[cairo] Re: Possible API change to handle invalid glyph indexes

[Baz]

Behdad replied (in the bug report):
>On 15/01/07, Baz <brian.ewins at gmail.com> wrote:
>> >  - Scaled font layer acts if nonexistent glyphs had extents
0,0,0,0.  We also
>> >change cairo_show_glyphs, cairo_glyph_extents, and
>> >cairo_scaled_font_glyph_extents to return cairo_status_t, and return
>> >INVALID_INDEX if at least one glyph id was such.  However, that error can be
>> >ignored.
>> Ok. Since you seem to be suggesting that each font backend decides for itself
>> what nonexistent means, I'd suggest 0x0-0xffff is the valid range for atsui -
>> while 0x0-0xfffe is the usable range, reporting INVALID_INDEX for
0xffff would
>> just trip up code ported from freetype (ie this bug all over again, with a
>> different error code). I'd handle 0xffff as a special case in the
font backend.
>
>No, the backend just needs to return UNSUPPORTED if the font doesn't have the
>glyph.  That's all.  Are you saying that with ATSUI, there's no way to figure
>out if the glyph exists or not? I don't mind you special-casing 0xffff, but a
>portable application shouldn't let that reach cairo anyway.

When using ATSU you're expecting that font substitution would have
been done by the time we hit the calls that take glyphs as arguments.
The glyph id would be 0 for any character that hadn't mapped to a
glyph - so under normal circumstances there wouldn't need to be a call
to determine if a specific glyph id existed. And as far as I can tell,
the only way you'd find out that the glyph doesn't exist would be that
you cannot get path information for it, which is what triggered the
bug in 9530 in the first place.

Addressing the '0xffff portability' issue - anything calling the
non-toy APIs is inherently doing something non-portable, since they're
getting hold of glyphids and positions in a platform-specific way.
Using ATSUI, you would expect to see 0xffff and not treat it as an
error; anything that doesn't fit in a UInt16 is an error for ATSUI
though. The patch I had in the works for 9530 doesn't actually special
case 0xffff, it just measures what ATSU draws for glyph ids with no
path info (which turns out to be zero-width, not boxes). Initially I'd
thought some bitmap fonts would trigger this path too but I haven't
seen that happen yet.

Portability only comes into it if you tried to do something like, eg,
use ATSU apis to generate glyph ids, then call cairo's non-toy api[1]
with the ft backend enabled instead of ATSU. Is that supposed to be a
supported scenario?

As far as I know, the glyph indexes were supposed to be opaque to
cairo, but the test I wrote cheats a bit, I've specified values (all
of them except for 0x1ffff and -1L are taken from the cmap though). So
testing the displayed image assumes glyph index portability, but it's
the absence of errors for the full ulong range of glyph indexes that
I'd expect to be portable.

Cheers,
Baz