[PD] FTGL

timon timon at botezco.com
Thu Apr 19 15:14:43 CEST 2007


>> Hi, I posted a question last week on why [textextruded] wasnt  
>> working. I
>> got the answer, GEM must be compiled with FTGL.
>> So why was it changed in the first place? It seemed to be running  
>> fine
>> (or sort of) and now it aint working at all. And sadly I dont know  
>> how
>> to compile GEM with FTGL.
>
> please note that [textextruded] was only introduced into Gem  
> because of
> FTGL (the old fontrendering library used was GLTT which had no such
> thing as extruded text).
>
> so the answer is: in order to have [textextruded] working, you must
> compile Gem with FTGL; there have never been another way to get  
> extruded
> text.
>

The versions I have been using has all that working. And from what  
your saying, this version was compiled with FTGL.:
GEM: ver: 0.90
GEM: compiled: Mar  8 2006



This one is not:
GEM: Graphics Environment for Multimedia
GEM: ver: 0.91-cvs
GEM: compiled: Apr 14 2007

So what your saying is that the current version of GEM is not  
compiled with FTGL. I guess what Im trying to get an answer to is why  
the current version of GEM is not compiled with FTGL? Are there any  
plans for doing that (very impatient I know)?

>>
>> Whats the reason for this grand change? Any future benefits? Will it
>> support a full UTF-8 character map?
> like chris has said, there has not been a grand change regarding fonts
> for years.
> and yes, the text-objects in current CVS support full Unicode (well  
> not
> full: only the first 65000 or so) characters.
>

With regards to full character set... I did some tests a while back,  
with the older version (see above) which I posted on the list  
(without much interest). The character mapping then was a bit messed  
up. Importing UTF 8 format into PD is fine, but spitting it out to  
any text object in GEM gets the characters jumbled up (the ones  
outside the first 128). Also, it was not happy doing japanese, which  
showed up fine in the symbol atom box. The only format it mapped  
correctly was Windows Latin 1252 (all 256 characters - not really the  
extended set I was hoping for). I did extensive tests on re- 
formatting the fonts as well. Again, this came out with the same  
result - correct for 1252 only. Beats me. Could this be an OS issue?  
Im on OSX - whatever latest update.

T.


> mfga-sdr
> IOhannes





More information about the Pd-list mailing list