Hi Alex,
> * in some cases best readability is the target [best user experience]
> * in some cases exact string representation is the target [copy+paste, debug]
> * in some other cases you simply want to be fast [viewing text/binary files]
...
> for exact representations any sort of escaped chara
My personal summary on the practical aspect is:
* in some cases best readability is the target
* in some cases exact string representation is the target
* in some other cases you simply want to be fast
in the first case you are probably targetting for best user expirience.
in the second case you
is DPMI out of the question?
From: Eric Auer
To: freedos-devel@lists.sourceforge.net
Sent: Wed, December 1, 2010 2:59:56 PM
Subject: Re: [Freedos-devel] ASCII to unicode table
Hi Christian,
Using UTF-8 CON with a codepage based app or vice versa
is worse for
Hi Christian,
Using UTF-8 CON with a codepage based app or vice versa
is worse for block graphics than just using the wrong
codepage, as not only the shape but also the number of
displayed characters will change: Everything outside of
basic ASCII takes 2 or more bytes in UTF-8, so display
on code
> You would need an Input Method driver which lets you type
> complex key sequences or combinations to type in a language
> which has more than the usual few dozen chars of alphabet.
Yes. The (keyboard) input and (screen) output appears to be the most
complicated exercise here. DBCS or UTF-8 sup
> Combined with, for example, a UTF-8 enabled Super-NANSI to
> make the step from strings to their display, of course. The
> problem would be loss of "ASCII" art block graphics in apps
> which are not using Unicode.
But that happens for some code pages anyway. (For example, CPs 858 and 850
drop
On Wed, 1 Dec 2010, Eric Auer wrote:
> Compatible apps would be apps which only display ASCII out
> of themselves and which make no serious assumptions about
> one byte being equal to one character. A good example are
> MORE and TYPE: If you TYPE an UTF8 text with a special CON
> driver which expe
Hi Christian,
>> Should the translation be "accurate" or should it be "useful"?
That depends a lot on which languages we are talking about.
For the DISPLAYING of already existing strings such as file
names on some USB stick made by somebody using Linux, MacOS
or Windows, if your language is "so
Hi Christian,
> Just noticing that this grows quite large. If someone finds this
> unbearable for this list, please speak up to let me know I should cut down
> the off-topic stuff on my public mails!
No problem :-) I would hope that people talk more about the
"big font" approaches - Having eithe
> I think your attitude is not very constructive. We have to keep this
> idea as simple as possible or nobody implements it.
I think some of that is important, even if you only want to implement a
simple translation. Besides, of course it isn't very constructive to
*discuss* an idea. Go use
I think your attitude is not very constructive. We have to keep this idea as
simple as possible or nobody implements it.
I think it is not needed to make tables UNICODE to ASCII.
It is sufficient to make ASCII to UNICODE.
Simple table - on one side 256 bytes - on second side 256 words.
That is al
> UniCode is not the panacea it's purported to be.
No, but you have to give them that it's certainly an improvement.
>> UTF-8 is independent of byte-order. The exact encoding (and byte-order)
>> should always either be implicit (in the interface's or format's
>> definition) or be marked in some w
Christian Masloch wrote:
>
> I think it should be accurate for file systems. Such a "useful"
> translation is a good concept for displaying output (maybe even that of
> the DIR command) but not for actually working with the file system.
> Keyboard input can't map one key to several characters a
> Should the translation be "accurate" or should it be "useful"?
I think it should be accurate for file systems. Such a "useful"
translation is a good concept for displaying output (maybe even that of
the DIR command) but not for actually working with the file system.
Keyboard input can't ma
I think there's an even larger question than the technical implementation, in
summary: Should the translation be "accurate" or should it be "useful"?
Officially, I believe there is a precise one-to-one relationship between
ASCII and Unicode, but there are dozens of Unicode characters that "look
l
On Sat, 27 Nov 2010, Eric Auer wrote:
> You could even have a separately loaded CON driver that
> keeps a full unicode font in XMS (with some caching of
> recently used sections in faster memory maybe?).
That would be something like what DOS/V does. It switches to VGA 640x480
mode and emulates
> Now programs do it self by looking into own datafiles with .TBL
> extension. Look at DOSLFN or Volkov commander 4.99. They have few files
> like cp852uni.tbl, cp866uni.tbl and so on.
> It is a very good solution but problem is that here is no way now how to
> determine which file should be
Hi Ladislav,
> I think we should discuss how to implement unicode.
There already is some interface for double byte chars
in DOS, which we could implement. However, it was made
for Chinese as far as I remember and needed support by
more drivers even if you had a DBCS-enabled DOS version.
> In th
I think we should discuss how to implement unicode.
In the fact only one small thing is necesarry: we need a mechanism for
translating unicode chars into ASCII chars and vice versa.
Now programs do it self by looking into own datafiles with .TBL extension. Look
at DOSLFN or Volkov commander 4.99
19 matches
Mail list logo
