Re: gEDA: Unicode support

[Ales Hvezda <ahvezda-at-NOSPAMmoria_dot_seul_dot_org>]

Hi Carlos,

[snip]
>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....=20
>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 .

	Yeah, there is such a function in gtk (or glib, I can't remember)
which validates the string as utf-8.  However, yeah, I don't want to
invest any time in doing this (unless it is virtually free).

[snip]
>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.
>

	Yeah, that's what I had in mind.

>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....


	Ah, yes, the special vector font (courtesy of Tim Edwards of XCircuit
fame).  Don't forget that 1) gaf was started in the days when 486 and
Pentiums rein supreme, so almost all the rather odd things, including
the vector font, were done to make things faster.  At first I was using
regular X fonts for the text, but I found that to be too slow.


>So, I wonder:
>	-  what are the advantages of gschem using its own font?.=20

	Mainly performance, but the primary disadvantages are the extra
maintainance headaches and the slight mismatch between what's drawn and
what is rendered into the postscript.


>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


	Yeah, in order to fully support all of unicode, we would have to
drop the vector font and switch to pango/freetype.  Not impossible, but
would require a significant rewrite of the entire text engine and probably
a good chunk of the rendering engine as well.  I would like to save this
task for the next generation program.


>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?.

	Quite a bit and I'm not 100% convinced that I would be able to
squeeze the necessary performance out of the existing rendering engine
without completely rewriting it.  Something I've been tempted to do, but
haven't because there are bigger fish to fry.

	I think for now, as the next stepping stone, we should get libgeda
to read/write unicode characters and create the above mentioned lookup
table to handle the conversion from unicode character to custom vector
font.  I don't see this as a viable long term approach but rather as a short
term fix which will get us past the current broken behavior.


>	- advantages or disadvantages? could it be worth or not?

	
	My biggest question with regard to this would be:  Would people
be really that interested in adding and manipulating i18n text in the
schematic?  Granted gschem supports that to some degree now and I've never
been happy with it, but do people really want to create i18n schematics?
Are there any other schematic capture systems out there where are fully
i18n (I'm talking about unicode here and all the nice feature that come 
with it)?

								-Ales