Re: [ft-devel] About the Cmap format 14

[David Turner]

Another point is that the arrays returned are 0-terminated. this assumes that 0 is not a valid selector variant, but I don't see code to check for this in the cmap 14_validate function. will add these

2007/10/19, David Turner <address@hidden>:

ok, I have several issues with this patch (and I'm writing a fix right now):

-naming: I prefer all new APIs to use the "FT_Object_ActionName" template, this means I'd favor renaming the functions to things like:

  FT_Face_GetCharsOfVariant
  FT_Face_GetVariantsOfChar
  FT_Face_GetVariantSelectors
  etc...

- documentation: the API documentation doesn't make the purpose of these functions very clear. An explanation of what a variant selector charmap is would be welcomed

- some functions returns arrays that need to be "deallocated" by the caller. This is a *big* no-no because typical FreeType clients don't have access to FreeType's memory management functions, and still cannot assume that malloc/free was used to allocate the data.

it's better to either allocate the array in the FT_Face object, and reuse it on subsequent calls (if its size is likely to be small), or ask the client to provide the target buffer (while giving it the ability to query its desired size)

By the way, where can I find the spec for cmap format 14 and the variant selector things ?, I could not find anything on the Internet.(yes, I've seen the description in src/sfnt/ttcmap.c)

As I said, I'm going to submit a fix soon anyway

- David

2007/10/11, Werner LEMBERG <address@hidden>:

> >   FT_Get_Chars_Of_Variant
> >   FT_Get_Variants_Of_Char
> >   FT_Get_Variant_Selectors
>
> I like this much better (I was just trying to be consistent with the
> old interface), but this is certainly easier to use.
>
> > instead which return an array of all chars or variants,
> > respectively.  Whether this makes sense, I don't know.  Hmm.  Your
> > suggested functions are probably better in the sense of memory
> > consumption; my suggestions can cause big allocations...
>
> I don't think it will be too bad. Currently only ~260 variant
> selectors are reserved and less than 10 are actually defined.  The
> only questionable one is FT_Get_Chars_Of_Variant, but even here I
> don't think there will be any huge arrays -- my understanding is
> that even Adobe-Japan-1 has only 1222 characters with multiple
> variants.

For me it's OK.  David?

And thanks in advance for your efforts.


    Werner


_______________________________________________
Freetype-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/freetype-devel