andersa@kuling.UUCP (Anders Andersson) (02/07/86)
Referring to linkers and alike not being able to recognize symbols
written with different fonts, you do have a point there... If we
haven't done it already, I suggest that we differ between characters
used for representation of natural language text, and those used
within computer software to denote symbols, filenames and alike.
Software dealing with all the properties of national characters will
probably be huge, and I wouldn't like to include it in my operating
system just to get my file listings sorted "alphabetically". Now I
refer primarily to traditional, "low-level" operating systems. In a
window-oriented, database, user-friendly, <whatever> system things
might be different, though.
What I'm saying is that ASCII95 will probably have to stay in some
way or another, together with whatever Kanji Word Processor Standard
will be created. Sorry if this has been discussed and/or agreed upon
already.
--
Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden
Phone: +46 18 183170
UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)tuba@ur-tut.UUCP (Jon Krueger) (02/10/86)
In article <882@kuling.UUCP> andersa@kuling.UUCP (Anders Andersson) > Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden > Phone: +46 18 183170 > UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa) > writes: >Software dealing with all the properties of national characters will >probably be huge, and I wouldn't like to include it in my operating >system just to get my file listings sorted "alphabetically". This is exactly my point. And was the point of my first, :-) qualified, posting. It's silly to support the constructs for twenty major world languages within utilities and environments that don't need them. Unix's human interfaces are text-oriented. Programmers and users create and manipulate text. Word processing applications and such need multiple fonts and native character sets. Programming languages don't. The question is how to integrate the two environments with maximal ease of use and minimal overhead. Up to now, most of what has been proposed in this newsgroup could be achieved by a a document processing package and a few conversion utilities. This just doesn't justify major mods to Unix and horrible space and time overhead at runtime. I'd like to see integrations proposed which are so worthwhile they do justify it. I suspect a good way to generate such proposals is to ask not what Unix can do for internationalism, but what internationalism can do for Unix.