Peter Plessas a écrit :

• Patrice Colet pat@mamalala.org [2007-09-12 18:29]:

...

Hello, I hope I am adressing this mail to the right mailing-list.

I've got problems with finding FTGL compatible math fonts, could you help me for adding mathematica fonts support or any other efficient font for writing in gemwin the famous Maxwell equations?

Hi Patrice,

If you want to display the formula statically you could render a picture with it using [pix_image], but i am sure you already thought about that one.

lg, PP

Yes, this is my last ressource indeed, I will have to render each symbol on a picture, and then add alpha to the background. Using [text2d], or even better: [textextruded] would have been less complicated, and would have required less job, but if I have no other choice, let me do this gargantuan task...(*sighs*)...

You could try and make a vector version (inkscape?) and use blender to make it into a model. For all I know you can do text in blender also...

It would be staticish... are you wanting to animate the characters separately?

Loading a TIF with an alpha channel in Gem works fine FYI...

It would actually not be much effort to do it that way..

.b.

Patrice Colet wrote:

Roman Haefeli a écrit :

...

On Wed, 2007-09-12 at 18:21 +0200, Patrice Colet wrote:

...

Hello, I hope I am adressing this mail to the right mailing-list.

I've got problems with finding FTGL compatible math fonts, could you help me for adding mathematica fonts support or any other efficient font for writing in gemwin the famous Maxwell equations?

yo, ciao pat

excuse me, if i am talking rubbish here, but doesn't ftgl compatible just mean, that the file format of the fonts can be *.ttf? i don't know anyhting about mathematica fonts, but isn't at least one of these fonts available in the ttf-format?

roman

Hi Roman, apparently mathematica fonts seems to not get along perfectly with FTGL, I don't know why, maybe it's a freetype version issue, maybe not ...? Patco.

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

hint: i had better success in copying the matlab glyphs into the lower

of course i meant "mathematica" instead of "matlab"

fgma.dsör IOhannes

Patrice Colet wrote:

Hello IOhannes,

good to see that it helped you

From what I've understood it wouldn't be possible anyway to use ascii codes (I didn't understand how to use functions provided by the moocow patch that is supposed to convert ascii code for [textXd] class objects,

it's not that complicated. basically it is about enumeration of glyphs.

like in the ascii table you have a glyph "a" which has the number "97". this basically means that you can represent the string "aaa" as a sequence of numbers "97 97 97" and this is exactly what moocow's pdstring library does: it converts a symbol "bla" into a list of numbers "98 108 97"

this has several advantages: 1. pd normally does not use "strings" but only "symbols" which are all stored for later use; each symbol is created the first time it is used and never freed again (if you have a list "aaa bbb aaa", pd will create 2 symbols for you "aaa" and "bbb"; internally the list will be stored as 'symbol#1 symbol#2 symbol#1' (or similar); this is good as it is fast; this is bad if you are dealing with real text that has loads of different "words", as you can run out of memory... (usually this is not a big problem; but moocow is a linguist and does analysis of big text corpora...) (lists of) numbers are more dynamic and get freed properly after use. 2. since we express glyphs as numbers in an enumeration and there are plenty of numbers we can express a lot of glyphs. (more than it is possible with a keyboard). in Gem you can address about 65535 glpyhs in this way. in standardized fonts these usually map to the first 2^16 unicode glyphs. e.g. "∈" ("is element of") is defined as unicode 8712. so you can send a message "string 105 32 8712 32 87" which should render to "i ∈ N" (if your font has all the necessary characters)

mfg.asdr IOhannes

Patrice Colet a écrit :

IOhannes m zmoelnig a écrit :

...

it's not that complicated.

Hello,

The only binary that is able to load all my ttf files with the openpanel without crashing pd is gem-0.90.1-W32-i586, but moocow patch isn't applied to this one.

You can give a try with the string-test.pd patch in attached archive, just try to load twice a ttf file with openpanel, for me it systematically crashes pd with any 0.91 snapshot.

I've also attached in the archive of the last mail a text manipulation abstraction called text-test.pd, this one crashes with

gem-CVS20060914-W32-i686-bin, I've no idea why, and with

gem-CVS20060412-NT-i686-bin, there is a:

"GL: énumérant non valide" error printed into the pd console at each rendering frame.

zmoelnig@iem.at a écrit :

Quoting Patrice Colet pat@mamalala.org:

...

You can give a try with the string-test.pd patch in attached archive, just try to load twice a ttf file with openpanel, for me it systematically crashes pd with any 0.91 snapshot.

please file a bug-report at sourceforge. i believe that this has been fixed in the latest CVS version, but that one has not yet been compiled for w32 (afaik)

That's right, I've given a try on ubuntu64 with a Gem version compiled last september 12 from cvs, it doesn't crash with using openpanel, but I've discovered another bug, :D, the text is half rendered with text2d, it seems good with other text objects, we only see the half of the bottom of each glyph.