[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA: Unicode support
Hi Ales,
El dom, 23-01-2005 a las 23:21 -0500, Ales Hvezda escribió:
[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.
Mmmmm.... I was thinking in a user using gtk+1.2 or gtk+2.0, but not
both with the same schematic. Certainly a gschem compiled with gtk+1.2
will not be able to properly display a schematic containing Unicode
texts....
If there were a function which could check if a string is unicode or
not, then one possible solution can be warn the user if he is using
gschem/gtk+1.2 and such string is found, or use iconv to translate the
string.
I'm not sure if it is worth trying to do it now gschem is dropping
support with gtk+1.2 .
> 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. :)
Ok, doesn't seem difficult to support it better, but maybe it is if we
want to fully support it. See below.
> >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?
>
So the task can be divided into two steps:
- Put the hash table into libgeda, and have the font map hardcoded,
like it is now.
- Load the hash table from a file.
I have one aside question regarding font implementation in gschem...
this may have been answered before, so sorry if it's repeated.
I was wondering what's the purpose of needing a special font for gschem.
I think most apps out there use the already available fonts, instead of
each needing its own font, and they are able to print to postscript, and
so on....
So, I wonder:
- what are the advantages of gschem using its own font?.
I ask this because if gschem is moving to unicode, it only will have
FULL unicode support when it uses gtk (and therefore pango) for text
rendering. I think it's not too difficult to change libgeda internals so
it can use unicode, but I can't see support for asian, cyrillic, (they
will have to build a font for just using gschem) or right to left
writings without using gtk for it.
- how much effort could be to have gschem using GTK text rendering?.
- advantages or disadvantages? could it be worth or not?
Regards,
Carlos
--
Carlos Nieves Ónega <cnieves@iespana.es>
---Publicidad--------------------------------------------------------
Nuevo Messenger Multimedia de Yahoo ¡ Descárgalas Gratis !
http://tracker.tradedoubler.com/click?p!420&a38692