Re: [E-devel] Eterm and utf8

2009-02-20 Thread Kim Woelders
Sorry about that.

- It should be possible to send patch attachments to this list.
- I'm not the biggest fan of t...@$! around here.
- It seems I got the patch sneaked through now.

/Kim


On Fri, 20 Feb 2009 04:21:04 +0100, Toma tomha...@gmail.com wrote:

 Patch was not included in the email. Might be best to create a bug on
 trac.enlightenment.org/e/ and attach the patch. There may already be a
 bug open for UTF8 support...

 -Toma.


 2009/2/20 Kim Woelders k...@woelders.dk:
 Hello,

 It is annoying that Eterm doesn't handle utf8. Here is a half-baked  
 patch
 that might inspire somebody (Michael? :) ) to do it properly.

 Beware! This patch breaks things in non-utf8 locales, probably doesn't  
 work
 on big-endian platforms, and is not suited for anything except playing
 around.

 That said, things seem to work fairly well with e.g. LANG=en_US.UTF-8  
 and
 selecting a good font, e.g.
 Eterm -F  
 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

 With -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1 it  
 even
 looks like Japanese and Korean is rendered correctly but there is some
 weirdness with column stepping (every second column is skipped).

 /Kim
 --
 Open Source Business Conference (OSBC), March 24-25, 2009, San  
 Francisco, CA
 -OSBC tackles the biggest issue in open source: Open Sourcing the  
 Enterprise
 -Strategies to boost innovation and cut costs with open source  
 participation
 -Receive a $600 discount off the registration fee with the source code:  
 SFAD
 http://p.sf.net/sfu/XcvMzF8H
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



 --
 Open Source Business Conference (OSBC), March 24-25, 2009, San  
 Francisco, CA
 -OSBC tackles the biggest issue in open source: Open Sourcing the  
 Enterprise
 -Strategies to boost innovation and cut costs with open source  
 participation
 -Receive a $600 discount off the registration fee with the source code:  
 SFAD
 http://p.sf.net/sfu/XcvMzF8H
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Eterm and utf8

2009-02-20 Thread Peter Wehrfritz
Kim Woelders schrieb:
 Hello,

 It is annoying that Eterm doesn't handle utf8. Here is a half-baked 
 patch that might inspire somebody (Michael? :) ) to do it properly.

Or maybe one gsoc student :).

 Beware! This patch breaks things in non-utf8 locales, probably doesn't 
 work on big-endian platforms, and is not suited for anything except 
 playing around.

 That said, things seem to work fairly well with e.g. LANG=en_US.UTF-8 
 and selecting a good font, e.g.
 Eterm -F -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

 With -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1 it 
 even looks like Japanese and Korean is rendered correctly but there is 
 some weirdness with column stepping (every second column is skipped).

I've seen in your patch that you are converting the text to ucs-2. which 
is, as you probably know, only a subset of unicode 4.0 and hence doesn't 
cover all UTF-8 supported characters. I guess that most (probably all) 
Unicode character beyond the scope of ucs-2 aren't used widely. I doubt 
that someone uses Ancient Greek Musical Notation-characters in a 
terminal application, but wouldn't it be better to support the whole 
UTF-8 character set, even if it is only for the sake of completeness?

Peter

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Eterm and utf8

2009-02-20 Thread Kim Woelders
On Fri, 20 Feb 2009 20:09:30 +0100, Peter Wehrfritz peter.wehrfr...@web.de 
wrote:

 Kim Woelders schrieb:
 Hello,

 It is annoying that Eterm doesn't handle utf8. Here is a half-baked  
 patch that might inspire somebody (Michael? :) ) to do it properly.

 Or maybe one gsoc student :).

 Beware! This patch breaks things in non-utf8 locales, probably doesn't  
 work on big-endian platforms, and is not suited for anything except  
 playing around.

 That said, things seem to work fairly well with e.g. LANG=en_US.UTF-8  
 and selecting a good font, e.g.
 Eterm -F  
 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

 With -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1 it  
 even looks like Japanese and Korean is rendered correctly but there is  
 some weirdness with column stepping (every second column is skipped).

 I've seen in your patch that you are converting the text to ucs-2. which  
 is, as you probably know, only a subset of unicode 4.0 and hence doesn't  
 cover all UTF-8 supported characters. I guess that most (probably all)  
 Unicode character beyond the scope of ucs-2 aren't used widely. I doubt  
 that someone uses Ancient Greek Musical Notation-characters in a  
 terminal application, but wouldn't it be better to support the whole  
 UTF-8 character set, even if it is only for the sake of completeness?

Yes. UCS-2 is used as internal encoding in this patch. It is what I found all 
in all seemed to give best results.
It might be considered to use UCS-2BE internally to avoid some byte swapping, 
but I got in trouble with that somewhere.

I have a similar patch where the internal encoding is wchar_t and 
mbstowcs/XwcDraw[Image]String/XFontSet are used.
I found it very hard if not impossible to select a proper font set. Either I'm 
stupid or that just doesn't work properly.

I'm fairly convinced that using UCS2 is fine for all practical purposes and I 
think that implementing utf8 support at all is more important than going for 
completeness and support for ancient whatnot :)

It could also be considered to use Xft, but again, I'm having trouble selecting 
the font I want in stead of some silly antialised one. However, there are 
reasons to try and get this right (the old X11 font system kind of being on the 
road to deprecation).

/Kim

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Eterm and utf8

2009-02-20 Thread Peter Wehrfritz
Kim Woelders schrieb:

 Yes. UCS-2 is used as internal encoding in this patch. It is what I 
 found all in all seemed to give best results.
 It might be considered to use UCS-2BE internally to avoid some byte 
 swapping, but I got in trouble with that somewhere.

 I have a similar patch where the internal encoding is wchar_t and 
 mbstowcs/XwcDraw[Image]String/XFontSet are used.
 I found it very hard if not impossible to select a proper font set. 
 Either I'm stupid or that just doesn't work properly.

I hoped that maybe Xmb* or Xutf8* (maybe not very portable) functions 
could work.

 I'm fairly convinced that using UCS2 is fine for all practical 
 purposes and I think that implementing utf8 support at all is more 
 important than going for completeness and support for ancient whatnot :)

That's true :).

 It could also be considered to use Xft, but again, I'm having trouble 
 selecting the font I want in stead of some silly antialised one. 
 However, there are reasons to try and get this right (the old X11 font 
 system kind of being on the road to deprecation).

 /Kim


Sorry my ignorance, I haven't imagined that it could be such 
complicated. And of course if you have to choose between impossible 
and works for everyone, you should take the latter. :)

Peter

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Eterm and utf8

2009-02-19 Thread Toma
Patch was not included in the email. Might be best to create a bug on
trac.enlightenment.org/e/ and attach the patch. There may already be a
bug open for UTF8 support...

-Toma.


2009/2/20 Kim Woelders k...@woelders.dk:
 Hello,

 It is annoying that Eterm doesn't handle utf8. Here is a half-baked patch
 that might inspire somebody (Michael? :) ) to do it properly.

 Beware! This patch breaks things in non-utf8 locales, probably doesn't work
 on big-endian platforms, and is not suited for anything except playing
 around.

 That said, things seem to work fairly well with e.g. LANG=en_US.UTF-8 and
 selecting a good font, e.g.
 Eterm -F -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

 With -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1 it even
 looks like Japanese and Korean is rendered correctly but there is some
 weirdness with column stepping (every second column is skipped).

 /Kim
 --
 Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
 -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
 -Strategies to boost innovation and cut costs with open source participation
 -Receive a $600 discount off the registration fee with the source code: SFAD
 http://p.sf.net/sfu/XcvMzF8H
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel