Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.acorn.programmer > #1531
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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