A.J. Venter wrote:
One problem, however, is what to do on Windows 9x and on Gtk 1. We
would need to convert utf-8 to iso. But to which iso? A easy solution
is to just convert to western european iso.
Actually there must be ways of getting the current running environment's
preferred character
On 5/14/06, Mattias Gaertner [EMAIL PROTECTED] wrote:
The question is: should the LCL use the 'native' string type and let the
applications write three times the code. Or should the LCL use UTF-8 and map
internally in the interfaces and let the applications write once and compile
anywhere.
One problem, however, is what to do on Windows 9x and on Gtk 1. We
would need to convert utf-8 to iso. But to which iso? A easy solution
is to just convert to western european iso.
Actually there must be ways of getting the current running environment's
preferred character set. Under Linux you
Mattias Gaertner wrote:
Can you define, what a BIDI property should do?
- When working with bidirectional text, the characters are still interpreted
in logical order--only the display is affected. The display ordering of
bidirectional text depends upon the directional properties of the
On Wed, 17 May 2006 13:55:31 +0300
Al Boldi [EMAIL PROTECTED] wrote:
Mattias Gaertner wrote:
Can you define, what a BIDI property should do?
- When working with bidirectional text, the characters are still
interpreted in logical order--only the display is affected. The display
ordering
Mattias Gaertner wrote:
Al Boldi [EMAIL PROTECTED] wrote:
Mattias Gaertner wrote:
Can you define, what a BIDI property should do?
- When working with bidirectional text, the characters are still
interpreted in logical order--only the display is affected. The display
ordering of
UTF-16 is multibyte.
There are more unicode characters than 2 byte numbers, so you won't find a
complete 2 byte unicode encoding.
I read somewhere that there was a previous Unicode format that ALWAYS uses
2 bytes for each character, but DOESN'T support all languages.
If I'm right, we can use
AFAIK you can't choose the Bidi of a font. Bidi is defined by the
characters. An 'a' is always left-to-right, while an arabic character is
always RTL, no matter what the font is called or setup.
Can you define, what a BIDI property should do?
I remember a post of a user that wanted to write
On Wed, 17 May 2006 09:52:46 -0500 (CDT)
[EMAIL PROTECTED] wrote:
UTF-16 is multibyte.
There are more unicode characters than 2 byte numbers, so you won't find
a complete 2 byte unicode encoding.
I read somewhere that there was a previous Unicode format that ALWAYS uses
2 bytes for
I'm very much ignorant about widestrings, utf-16, and internationnal
support in Lazarus. I mean, I have just no clue of what kind of work
it requires. What needs to be changed in the lcl source code.
If someone could point me to an example and the implications of the
changes, I'll see if I'm
utf-16 doesn´t have the same number of bytes for all characters. There
are also 32 bit characters on utf-16
I read somewhere in the Unicode page that there is a format with
2 bytes for all characters (monobyte/ utf-16? ) and another
that the number of bytes changes changes (multibyte / UCS-2 ?)
Take TEdit for example, which has been extended to contain properties like
the Font property.
Ok, you were making reference to the controls design,
not the character enconding...
Yes, I get, I know about OOP principles. Actually once
I try to make a TFont descendant in a visual control,
but It
On Tue, 16 May 2006 09:29:30 -0500 (CDT)
[EMAIL PROTECTED] wrote:
utf-16 doesn´t have the same number of bytes for all characters. There
are also 32 bit characters on utf-16
I read somewhere in the Unicode page that there is a format with
2 bytes for all characters (monobyte/ utf-16? )
On Tue, 16 May 2006 09:34:05 -0500 (CDT)
[EMAIL PROTECTED] wrote:
Take TEdit for example, which has been extended to contain properties
like the Font property.
Ok, you were making reference to the controls design,
not the character enconding...
Yes, I get, I know about OOP principles.
בTuesday 16 May 2006 19:08, כתבת:
On Tue, 16 May 2006 09:34:05 -0500 (CDT)
[EMAIL PROTECTED] wrote:
Take TEdit for example, which has been extended to contain properties
like the Font property.
Ok, you were making reference to the controls design,
not the character enconding...
But I would like to see that implemented via composition rather than
extension.
I have read the Unicode Standard docs. But What do you mean by
composition rather than extension.
As I remember, each (Unicode) character like Arabic, are stored a as a
sequence of data that a S.O. rendering
The question is: should the LCL use the 'native' string type and let the
applications write three times the code. Or should the LCL use UTF-8 and
map internally in the interfaces and let the applications write once and
compile anywhere.
Maybe BOTH STUFF.
There are some O.S.'es that support
On 5/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Maybe BOTH STUFF.
There are some O.S.'es that support some kind of Unicode, others no.
The idea is that utf-8 would be converted to whatever format the os
uses. Having to code twice is just like how it currently works today,
and then you
But I would like to see that implemented via composition rather than
extension.
Composition means something like this ? :
a
href=http://www.unicode.org/reports/tr17/index.html#CharacterEncodingModel;
http://www.unicode.org/reports/tr17/index.html#CharacterEncodingModel/a
-
Marco Aurelio
[EMAIL PROTECTED] wrote:
But I would like to see that implemented via composition rather than
extension.
I have read the Unicode Standard docs. But What do you mean by
composition rather than extension.
As I remember, each (Unicode) character like Arabic, are stored a as a
sequence of
What non Latin languages (such as Arabic, Chinese) do you need to be
supported ?
Chinese traditional and simplified and maybe russian and turkey unicode
regards
Christian Ulrich
_
To unsubscribe: mail [EMAIL PROTECTED]
On 5/12/06, Borut Maricic [EMAIL PROTECTED] wrote:
I agree - this is also my understanding after the recent
thread. It seems that it would be highly inefficient on
native utf-16 machines (such as WinNT+), but it should work,
in principle.
This is also very inefficient on iso systems, such as
On Sun, 14 May 2006 17:36:15 -0300
Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote:
On 5/12/06, Borut Maricic [EMAIL PROTECTED] wrote:
I agree - this is also my understanding after the recent
thread. It seems that it would be highly inefficient on
native utf-16 machines (such as
On 5/14/06, Mattias Gaertner [EMAIL PROTECTED] wrote:
The question is: should the LCL use the 'native' string type and let the
applications write three times the code. Or should the LCL use UTF-8 and map
internally in the interfaces and let the applications write once and compile
anywhere.
On Sun, 14 May 2006 17:56:13 -0300
Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote:
On 5/14/06, Mattias Gaertner [EMAIL PROTECTED] wrote:
The question is: should the LCL use the 'native' string type and let the
applications write three times the code. Or should the LCL use UTF-8 and
On 5/14/06, Mattias Gaertner [EMAIL PROTECTED] wrote:
AFAIK gtk, gtk2, carbon, qt and wince use UTF-8. So basically you test
No, gtk 1 uses either utf-8 or iso depending on the font. On my
computer and others I tested what works for Gtk 1 is iso.
wince uses utf-16, not 8.
--
Felipe Monteiro
This isn't the end of the world, but is somewhat inconvenient.
To answer which system is better, it is necessary to compare the
overhead with the benefits.
The overhead is minimal, if the LCL convert the string one time it is be set
and store it internally.
It would be nice to calculate
בMonday 15 May 2006 00:23, נכתב על ידי Felipe Monteiro de Carvalho:
On 5/14/06, Mattias Gaertner [EMAIL PROTECTED] wrote:
AFAIK gtk, gtk2, carbon, qt and wince use UTF-8. So basically you test
No, gtk 1 uses either utf-8 or iso depending on the font. On my
computer and others I tested what
[EMAIL PROTECTED] wrote:
Hi, I have a question.
Who of you need Unicode support in visula controls.
What non Latin languages (such as Arabic, Chinese) do you need to be
supported ?
Just curious.
Bidi support for Arabic would probably be critical.
But I would like to see that implemented
Hi, I have a question.
Who of you need Unicode support in visula controls.
What non Latin languages (such as Arabic, Chinese) do you need to be
supported ?
Just curious.
-
Marco Aurelio Ramirez Carrillo
[EMAIL PROTECTED] [.mx]
בFriday 12 May 2006 19:22, נכתב על ידי [EMAIL PROTECTED]:
Hi, I have a question.
Who of you need Unicode support in visula controls.
It will be great for me, my native language is Hebrew and BiDi (I have a
binding code for freebidi btw) with unicode can be great.
What non Latin languages
On 5/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi, I have a question.
Who of you need Unicode support in visula controls.
I already use Unicode support in visual controls, on Gtk 2 interface.
What is missing is adding support for utf-8 on the win32 interface.
It would probably have
It would also be great for me to have Unicode controls under
win32.
On 2006-05-12 at 19:58,
Felipe Monteiro de Carvalho ([EMAIL PROTECTED]) wrote:
What is missing is adding support for utf-8 on the win32 interface.
It would probably have to be something like this:
If Windows 9x, then convert
33 matches
Mail list logo
