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-20 Thread Kim Woelders
On Fri, 20 Feb 2009 20:09:30 +0100, Peter Wehrfritz  
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:
> 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
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  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 :
>> 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-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 :
> 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


[E-devel] Eterm and utf8

2009-02-19 Thread Kim Woelders

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