On Sat, 24 Nov 2007 18:29:48 +0300
"Vasily I. Volchenko" <[EMAIL PROTECTED]> wrote:
> > did you notice
> > Office applications also use Unicode for storage and nobody seems to
> > complain about it
> OK, office applications do so. It was some (or it is better to say -
> a lot of) problems with them, so when MSOffice 97 was introduced,
> most people had it with an old office. And these problems were only
> with badly saved old files, or files with wrong fonts. But that
> situation was very good because of 1. Backward compatibility.
> 2. Changing encoding type was concerned only with internal office
> format. Office (and other applications to) was able to use either
> plain text or unicode, and unicode is not used at all.
> You are trying to break both things: no compatibility and
> autoconversion is made for old (or delphi/kylix) projects and you are
> forcing saving text (.pas) files in the new encoding. Is it so good?
About autoconversion:
Changing the encoding of text files is pretty easy. For example: use
the 'recode' tool. An alternative would be to extend the IDE to
load/save files of other encodings and extend the compiler to auto
convert the strings.
After that you must check all places, where fixed visual character
widths are used. In lazarus only synedit and parts of the widgetsets
were affected. So, although is not difficult, this part can not be
done automatically.
>> [...]instead of having 2 sets of components for each encoding,
> > Ansi and UTF16 and options to use UTF8 instead
> > of Ansi,
>[...]
> (you must be sure, both students and
> post-graduates will be strongly disappointed if they will see English
> messages, and they will be disappointed much more if they would see
> somewhat like ЪЪЪЦЪЪЪЪЪЪ).
This is the current situation (as soon as you switch to another OS).
That's exactly what the switch to one encoding should fix.
>[...] OK, you will make UTF8 support on Windows, but I am not
> sure that it won't conflict with system encoding. For example, are
> you sure that ShowMessage('Ваша оценка - '+IntToString(mark));
> written in UTF8 will really shows correct message?
It will reasonably work. For example you can not expect that the
current windows font supports all languages. But this can not be fixed
by the LCL anyway.
> And the same will
> be with Application.MessageBox? If you are, how will it be with those
> who have a tons of code (easily converted to UTF8, as you say) full
> with Windows.MessageBox(Handle,...) which means MessageBoxA?
AFAIK the call to Windows.MessageBox is not the problem, but the non
UTF-8 strings stored in databases.
> And you
> say that it is not reasonable to make them a choice, to use or not to
> use UTF8 in their programs.
Conclusion:
Switching to UTF-8 means writing i18n programs becomes much easier and
writing system specific programs becomes harder. It breaks
compatibility. Some people would like a simple switch and that the LCL
should support both, but lazarus has not the man power to support this.
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
