Re: Is FT_CharMap enough? Re: [Devel] CMap support for CID driver.

[David Turner]

Hello,

Werner LEMBERG a écrit :
> 
> > In writing CID CharMap program, I think FT_CharMap is not enough
> > to handle CIDCMap files.
> 
> I agree.  It has to be extended (or an alternative structure must be
> created).
> 
> > * Do you think FreeType should support ALL CIDCMap files?
> 
> Yes.  We need a sensible method to specify resource directories to
> make /usecmap work.  Perhaps something like FT_Add_CMap_Resource_Dir()
> with a callback function provided by the application to specify the
> proper directory separators etc.
>

Actually, looking in the future a bit, I believe that it would be
a good idea to provide an efficient implementation of charmaps
(including CIDCMaps) that isn't part of FreeType itself..

I'm thinking about FT Layout, of course, but also to the fact
that it is often useful to access the charmaps without opening
a whole FT_Face object. A recent example was brought by Werner:

  when using the FreeType cache, one needs to use a charmap
  to translate character codes to glyph indices in order to
  use FTC_Image_Cache_Lookup or FTC_SBit_Cache_Lookup.

  this implies the use of a FT_Face, even if all glyphs were
  previously loaded into the cache, thus defeating some of
  the caching sub-system's purpose..

a solution to this problem is to "extract" the charmap
object from the FT_Face, this "independent" charmap could
even be stored in the cache and retrieved with something
like "FTC_Charmap_Cache_Lookup".

However, we cannot perform charmap "extraction" yet using
the current FreeType design. We could hack the library to
do so, and we could also hack it seriously to support
CIDCmaps and a few other things (like inspecting charmaps
automatically to determine which scripts/languages they
really support); finding a good interface might be _very_
tricky..

However, I'm beginning to believe that this functionality
should be placed _outside_ of FreeType, in order to be used
by other libraries, like FT Layout, and probably a few
others (e.g. font inspection / conversion / editing tools)

That doesn't prevent us from working within the FreeType
framework for now. Simply, it will probably be useful to
migrate the code to a specific library or module later..

Any comments on this ?

Regards,

- David