Re: [Devel] A beginners question

[Callum Prentice]

>> FT_Set_Pixel_Sizes ( face, 64, 0 );
>
> You should provide the same width and height (ie. 64, 64), you should actually
> zero-height glyphs with this call ! :)

i thought the docs i read mentioned that you could use 0 for either width or 
height and
it would force the size to be the same as the other one - i'll go back and 
check.

> You'll have to dive into the world of 'charmaps'. Font files embed zero, one 
> or more
> charmaps. Each charmap provides a mapping from a character code using a well 
> known
> encoding (Latin1, GB2313, KOI8-R, Unicode) to the internal glyph number.

Ok, understood.

> First thing, check available charmaps in your simhei.ttf file. Quick test : 
> use the
> 'ftdump' program included in the ft2demos package. It'll display available 
> charmaps in
> a 'raw form' (using TrueType IDs in your case, lookup the TT_PLATFORM_* and 
> subsequent
> macros in <freetype/ttnameid.h>).

great - this'll help a lot.

> What's left ? If you want to support Chinese glyphs, you can still try it 
> with GB2312
> or BIG5 (rather popular over there) :
>
> /* Scan available charmaps */
> int gotcha = 0;
> for (i = 0; i < face->num_charmaps && !gotcha; i++)

yep - i tried code like this - a snippet i took from the docs - and there 
seemed to be 2
encoding schemes stored in my font - one was unicode but the other matched none 
of the
values mentioned in the header file - i'm going to go back and try again and 
also try a
different font - seems like there are a lot out there now with chinese character
support.

> Now the whole story depends on your native data format. If you're
> Unicode (UCS2 or UCS4) all the way, then you can make a
> Unicode->{gb2313, big5) on-the-fly conversion method which is
> automatically called before calling FT_Get_Char() or FT_Load_Char(). You can 
> either
> consider iconv() (part of GNU libc under Linux, fetch
> libiconv or libicu on other OSes), either setup your own tables if you only 
> have a few
> conversions to do.

yes, this is my next problem to attack.  the source text will either come from 
a text
file or be typed in at the keyboard.  the text in the file will be created by a
translation agency and i assumed i'd get a file back full of characters that 
look like
the source to a chinese/japanese web page - 2 bytes per character. still lots 
more
research to do here i'm sure.

>> 2/ speed - potentially there will be a lot of text being drawn along with 
>> some real
>> time input in text entry fields for example - i'm hoping this method will be 
>> fast
>> enough for that.
>
> This is the cache part. The API is not really straight forward. Not hard to 
> use, but
> it lacks the whole picture, ie. a tutorial. Short answer : caches are used in
> ft2demos/src/ftcommon.i, have a look. All cache have a FTC_ prefix to their 
> API. You
> basically cache both charmap and glyph lookups.

okay understood.

> I'm about to release some code based on this experience, however it's still 
> not self
> explanatory IMHO. Anyway it's already public, crawl in it if you like :
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ngl/ngl/src/font/nglFontBase_shr.cpp?rev=1.25&content-type=text/vnd.viewcvs-markup

interesting - i'll go take a look.

> It's a generic support class, I'm using it for glyph rendering under OpenGL 
> (yes, I
> know about other similar projects :)). Oh BTW, it's evil C++ :)

excellent - actually, all my stuff is to be used for rendering under opengl too 
:) take
a look at http://www.musecorp.com if your interested.  oh, and C++ is all i use 
these
days ;)

thanks again vincent.

callum.