Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.acorn.programmer > #1531

Re: Future Unicode support

Date 2012-03-23 20:53 +0000
From Matthew Phillips <spam2011m@yahoo.co.uk>
Newsgroups comp.sys.acorn.programmer
Subject Re: Future Unicode support
Message-ID <22fa217552.Matthew@sinenomine.freeserve.co.uk> (permalink)
References <almarsoft.3869465234381739290@news.orange.fr> <3f5fd67452.Matthew@sinenomine.freeserve.co.uk> <almarsoft.6419659065395120605@news.orange.fr>

Show all headers | View raw


In message <almarsoft.6419659065395120605@news.orange.fr>
 on 23 Mar 2012 Rick Murray  wrote:

> On Fri, 23 Mar 2012 07:07:24 GMT, Matthew Phillips 
> <spam2011m@yahoo.co.uk> wrote:
> 
> > which start off being around how keyboard input could be extended,
> 
> My personal feeling is that there ought to be another word in the 
> poll block which describes the character in a Unicode sense *in 
> addition* to the existing one.

This was very similar to the view I was promoting on the thread on the forum.

> Remember also the Wimp has attached special meaning to some codes 
> 256 (cursors, etc).

I suspect that if it hadn't, no-one would ever have thought of passing UTF-8
characters through Key_pressed events as individual bytes!

> > is how applications are supposed to know how to interpret the data in
> > files they have saved on disc, files you get from other RISC OS 
> > users, etc.
> 
> You don't. This was part of the reason for the two calls to 
> make/unmake this string Unicode. It ought to be *assumed* that the 
> majority of files will be Latin1, so files in Unicode will need to 
> explicity state that they are, in fact, so. This is the simple 
> solution.

I agree.  The difficulty comes if an old application which is still being
used (e.g. via Aemulor) starts being run under an environment where the
alphabet is now UTF-8.

Ben Avison, in the thread I mentioned, was against having transitional
arrangements of the sort you were suggesting.  He was pointing out that text
in Wimp user messages (many of which are not understood by the Wimp itself)
might have to be converted to/from UTF-8 according to whether the application
was running Latin-1 compatibility mode or not.  He was therefore advocating
complete switch-over to UTF-8 at some date in the future, rather than
long-term support for two modes of operation.

See http://www.riscosopen.org/forum/forums/3/topics/700?page=2#posts-8231

What I never got round to contributing to that thread was the following
worry:

Suppose a popular application, still used by many users, such as Impression,
continues to be used after the bit switch-over to UTF-8.  Impression knows
nothing (I assume) about the character sets in use.  It's just rendering all
its stuff in the default alphabet.  Any user starting from scratch with
Impression and creating new files might well be OK.  But there's no way
Impression could convert old files to display correctly in the new
environment without being rewritten, and frankly, to start with after the
switch to UTF-8 the user is more likely to have old files than new ones. 
Besides, the user will continue to receive Impression files from other RISC
OS users who have not made the switch.

Obviously Impression is just an example (and if it is character set aware,
then I apologise to the fore-sighted folk at Computer Concepts).  Almost any
application which saves text to disc would be affected.

In the thread I cited I was proposing a modest improvement to !Chars which
could be ignored by applications, but which would allow arbitrary Unicode
characters to be fed to applications without the whole machine having to
affected by an alphabet switch.  We have a chicken and egg situation.  Many
applications have not been rewritten to be aware of character sets, but there
is little incentive for the developer to do this when the user cannot really
take advantage and input exotic characters.  But if the user switches
alphabets then data saved by unaware applications will be interpreted oddly,
so the users don't want to switch either.  The change to !Chars would not
help input Japanese or anything really complex, but it would make it possible
for compliant applications to allow users to use the occasional unusual
character (e.g. Polish accents, snippets of Greek) when they need to.

-- 
Matthew Phillips
Durham

Back to comp.sys.acorn.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-23 07:22 +0100
  Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-23 07:07 +0000
    Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-23 14:24 +0100
      Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-23 20:53 +0000
        Re: Future Unicode support Ron <beeb@woosh.co.nz> - 2012-03-24 12:21 +1300
          Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-24 05:42 +0100
            Re: Future Unicode support Ron <beeb@woosh.co.nz> - 2012-03-24 22:53 +1300
              Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-24 14:12 +0100
            Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-24 22:11 +0000
              Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-25 12:50 +0200
          Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-24 22:10 +0000
            Re: Future Unicode support Ron <beeb@woosh.co.nz> - 2012-03-26 03:26 +1300
              Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-25 16:43 +0100
              Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-26 00:39 +0200
                Re: Future Unicode support Ron <beeb@woosh.co.nz> - 2012-03-26 12:18 +1300

csiph-web