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