Personally, if you asked me :-), I would vote for the API with "unified" functions
(i.e., no distinction between gft*Char()
and gft*Code()) for a couple of reasons:
1) maintenance;
2) ease of use: Lee could make each function default to a behaviour that pretty much
gets the programmer's intent right,
as he put it, and still
allow tranparent character encoding support without complicating the life of those who
don't need it: as Christoph suggested,
perhaps the charmap could default either to ASCII or to Latin-1 if the programmer
doesn't explicitly call an API function
to set it. This way, the functions would be just as easy to use if you only need ASCII
or Latin-1 support (as Lee meant the
*Char() functions to be, right?).
Now, as far as support for different character encoding goes, I believe that we
shouldn't leave it to the user to call FT_Select_Charmap()
for the following reason:
According to the FreeType tutorial
(http://www.freetype.org/docs/freetype2/step1.html), usually font files only have
Unicode
and Macintosh (Apple Roman) character encodings. If Lee provides the user with a
Unicode *Code() interface that relies on
the user previously calling FT_Select_Charmap() and the function itself just passes
along the provided char code to the FreeType
lib to access the glyph, the user will probably be forced to do the conversion between
the character encoding that her platform
is using and Unicode all by herself before using libgft, since the font file will most
probably only support Unicode (I suppose
Apple Roman isn't used that much) and attenpts to use a different encoding by calling
FT_Select_Charmap() with any argument
other than Unicode will probably fail.
So perhaps libgft could internally handle conversions between the specified charmap
and Unicode (since virtually *any* font
file includes a Unicode index) _if_ a charmap was actually specified by the
programmer, and else (if no charmap was explicitly
chosen) just use the charcode "as is": if it is a valid ASCII/Latin-1 charcode,
FreeType will get as the right glyph (because
of the Latin-1/Unicode "overlap" in the range 0-255 I mentioned before).
And what about the conversions?
Well, the good news is at http://clisp.cons.org/~haible/packages-libiconv.html; the
internal libgft conversion could simply
use this lib to convert between the chosen charmap and Unicode before using the
character code in a call to FreeType.
Cheers,
Manuel
PS: The casts I mentioned in my previous emails would still be necessary: none of the
possible solutions I talked about above
handles negative charcodes. Whenever the user passed libgft a negative char code, we
would still have to cast it to (unsigned
char), and *then* convert that value to Unicode using iconv but only if a character
encoding had been explicitly specified:
the default ASCII/Latin-1 character encoding wouldn't require any translation at all
(except the cast).
PPS: This is why I think that perhaps we could default to Latin-1 (and not just ASCII)
support: the casts will always have
to be present for multiple character encodings support since Linux uses signed chars
and the character encodings iconv understands
range between 0-255 (I suppose...), so the three possible situations are:
1- passed positive char code (0-255), will perform translation using iconv if charmap
was specified, else use code "as is";
2- passed negative code ((-127)-0), cast it to (unsigned char), perform translation if
charmap was specified, else use value
resulting from cast;
3- passed any Unicode code (0-2^16) without any charmap having been specified, will
use value "as is".
See? In situation 2 we can support Latin-1 _without doing anything at all_ if no
charmap was specified: we can just pass
the value resulting from the cast to FreeType and there we have it: Latin-1 support.
:-)
Lee wrote:
> I still feel obligated to keep the PrintChar functions because of their
> simplicity and are what somebody would intuitively look for. Blindly using
> these routines should get you the "right" result.
> > int gftGetCharset(enum charset_t *charset);
> >
> >
> OK this is already an option to the the user through the freetype call
>
> FT_Select_Charmap(font, map);
>
> Calls to gftPrintCode(vis, font, code) would then map using the desired
> code.
