Hi Carlos,
[snip] >The patch didn't break support for gtk+ 1.2.x . It just adds support for >Unicode when using gtk+ 2.x, and leave things as they were when using >gtk+ 1.2.x . It can be found at: >http://archives.seul.org/geda/dev/Oct-2003/msg00071.html I was hesitant to apply the full patch because gtk+ 1.2.x did not use unicode but rather used the native character encoding. Somehow my tests were showing breakage which I wasn't sure how to deal with. Now that gtk+ 1.2.x is out of the picture, I am willing to state: "Unicode characters are allowed inside of schematics and if you want to use existing schematic with the old encoding, then convert them using iconv". Now we just need to get libgeda to support unicode better. :) >Just reviewing what I wrote (I don't trust my memory after so much >time ;-) ), it improves libgeda to handle the first page of unicode. >Currently, there is defined a font_set array holding all supported >characters. Supporting Unicode with this scheme means having an array of >2^32 bytes in memory, which has no sense for me. >I strongly feel that string support needs to be improved, and it means >changing the font_set scheme. Any ideas? I think your suggestions to use a hash table sounds good. The key into the table is the unicode character (gunichar). Then we would need to populate the hash table with the mapping between unicode characters and gschem font definition files (the ones in font/). This can be accomplished by a font map file which would be read in and parsed by libgeda. Comments? -Ales
