(Part 3 is a summary of my view on the discussed topics concerning libgft, just in
case we are all saying the same thing or
you just don't have the time/patience... :-))
1) About character encodings and tranlation to Unicode:
> > (..)
> > 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).
> Don't limit the range to 0-255. Use the long-type in the API everywhere to
> allow to handle _each_ kind of font-type/charset.
> > (...)
> Using the long-type would allow to handle _every_ case as I said above.
[I never meant to store the character code in a variable of type "char"; actually, the
"ugly" solution I originally proposed
to Lee to solve the practical problem I was experiencing while using libgft relied on
using a uint32 for the char code!]
I didn't mean to limit the acceptable value range to 0-255, either:
> And use _only_ ASCII as default, because this one should work _everywhere_.
>
> If the user want to use any other charset, he _has_ to set it.
I propose libgft accepts any code between 0-2^16 and just passes it along to FreeType
(i.e., assume the programmer is using
Unicode) if no charmap has been specified.
What I meant in this quote (and in the post-post-scriptum) was that defaulting to
Unicode when no charmap was specified (something
which I think you agree with) actually meant that libgft will gladly accept ASCII and
Latin-1, too, because of that overlap...
I don't understand why libgft should force the user to state that she wishes to use
the Latin-1 or the Unicode encoding instead
of "vanilla" ASCII, when libgft can provide default support for the _three_ of them
without any work at all... just by defaulting
to Unicode!
The first 255 Unicode values are the same as the ones in ASCII and Latin-1 because
probably it was considered highly desirable
by the Unicode committee that the mapping between the first two and Unicode was direct
and didn't involve any extra work
from the programmer; why should we think differently and make things more complicated
then they need be for that huge majority
of programmers?
> > 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.
> This is a good idea as long as you can convert each charset/font-type you > > want
>to support in libgft.
>From the libiconv homepage:
----
It provides support for the encodings:
European languages
ASCII, ISO-8859-{1,2,3,4,5,7,9,10,13,14,15,16}, KOI8-R, KOI8-U, KOI8-RU,
CP{1250,1251,1252,1253,1254,1257}, CP{850,866},
Mac{Roman,CentralEurope,Iceland,Croatian,Romania},
Mac{Cyrillic,Ukraine,Greek,Turkish}, Macintosh
Semitic languages
ISO-8859-{6,8}, CP{1255,1256}, Mac{Hebrew,Arabic}
Japanese
EUC-JP, SHIFT-JIS, CP932, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-JP-1
Chinese
EUC-CN, HZ, GBK, GB18030, EUC-TW, BIG5, CP950, BIG5HKSCS, ISO-2022-CN, ISO-2022-CN-EXT
Korean
EUC-KR, CP949, ISO-2022-KR, JOHAB
Armenian
ARMSCII-8
Georgian
Georgian-Academy, Georgian-PS
Thai
TIS-620, CP874, MacThai
Laotian
MuleLao-1, CP1133
Vietnamese
VISCII, TCVN, CP1258
Platform specifics
HP-ROMAN8, NEXTSTEP
Full Unicode
UTF-8
UCS-2, UCS-2BE, UCS-2LE
UCS-4, UCS-4BE, UCS-4LE
UTF-16, UTF-16BE, UTF-16LE
UTF-7
JAVA
----
2) About font support, lib organization, etc:
Christoph wrote:
> libgft have to be useable even when freetype-lib is [not?] installed on the machine.
[Christoph, I assume you meant when freetype is not installed, sorry if I
misunderstood you:]
I thought that libgft was meant to explicitly rely on FreeType, so that idea never
bothered me much. But perhaps that's because
I haven't been around that long... :-)
Anyway, TrueType fonts are more or less unanimously considered "better" (more
"pleasant") than the standard X fonts, I think,
and FreeType seems to offer a solid, portable (ANSI C, they say) font engine licensed
in the BSD style.
Besides, if that tutorial I mentioned is correct, the fact that TrueType font files
(almost) always include a Unicode map
means that supporting multiple character encodings in libgft becomes almost trivial
(e.g., just use libiconv), something
which I (very personally) suppose is "more important" than supporting multiple font
types...
>From personal experience, the problem that nagged me (while attempting to use libgft
>for some trivial "print-to-screen" jobs)
concerned char encodings, not downloading FreeType and obtaining some .ttf font
files...
And since I greatly appreciate the result :-), I worry more about the encodings than
the possibility of using other font
types.
But I understand that this sort of reliance on a single, independent lib (FreeType)
might go against the established GGI
"policy", so I can't say anything else.
3) Summary:
[0- I believe that relying on FreeType and focusing on TrueType fonts is fine.]
I humbly propose that libgft handles char codes the following way:
1- Type of char_code: unsigned int;
2- Allow the programmer to specify a character encoding to use, else default to
Unicode ("default to Unicode" doesn't require
any action at all - see below);
3- For each character code, do
3.a- Test to see if the programmer passed libgft a negative value, if so convert it to
the equivalent value in the 0-255
range.
I.e., for libgft, negative values would mean that the programmer is using signed chars
(e.g., default gcc behaviour under
linux when you use type "char") and trying to print a non-ASCII char of the character
encoding she is using. (I can think
of no other situation in which libgft would be passed a negative value.)
libgft can just do the test
if (char_code > 2^16)
char_code = (unsigned char)char_code;
[Note that this neither disturbs the support for Unicode nor performs any "default"
translation! It just allows the programmer
not to worry with the fact that her machine uses signed chars - just as it happens
with stdio.h - whatever the charmap she
uses. Unicode support would be left untouched, but libgft would be as simple to use as
stdio.h - all that "signedness mess"
would be handled internally. libgft would work in machines using both signed and
unsigned chars _with the same function calls_.]
3.b- With char_code now in the range (0;2^16), see if a character encoding was
specified. If not, just use that value without
further conversions (as explained in the first part of this email, this will allow
immediate support for ASCII, Latin-1 and
Unicode _by default_); else, call libconv and map that value to Unicode before using
it.
Sorry for any possible misunderstandings (and the length of the email... :-),
Manuel
