Mail Archives: opendos/1997/03/18/05:41:45
There's an xstrings command in unix where a table of
messages written correctly in a foreign language can overlay the
system's
normal messages. I've read about this solution being used in minuet so
perhaps
it might also be made to work in opendos as well.
On Tue, 18 Mar 1997,
Alaric B. Williams wrote:
> On 17 Mar 97 at 19:38, yeep wrote:
>
> > > How to minimize the amount of information presented where the user isn't
> > > overwhelmed with everytime being presented at once. While that would
> > take
> > > care of the GUI manager, what about the programs to run under them?
>
> > It would be one helluva challenge!!!
>
> Indeed.
>
> > Because Micro$oft declared that they'll no longer support DOS, I assume
> > they'll only support Windows, a GUI!!!
> > So how do they handle this?
> > Or do they just don't care about the sight impaired?
>
> It would seem so.
>
> Technology exists to enable. JCBs mean disabled people can happily move mountains.
> mputers are perhaps the greatest technological leap we have ever made; since
> they process information, they should be able to present information to people
> who have problems accepting information (because they can't see, or they speak
> a foreign language, are the two main reasons applicable here). They should
> make it no harder for a blind person to work in an office than for a seeing person.
>
> They don't! And whose fault is it? Not the programmers as such - they
> don't have time to make their software work with many different
> output technologies.
>
> IMHO, it's the platform developer's fault; people who design GUI APIs, people who
> design character sets and operating systems, and the people who design language
> standard libraries.
>
> Well, here we stand. We have the sources of a DOS kernel emerging. We have
> an unparalleled opportunity to shape a computing platform that already works
> on most machines out there.
>
> So let's not waste it. Let's design a platform that provides the kind of GUI that
> will be of some use to blind people.
>
> Foreign people are a different matter altogether; we can but provide OS and library
> level support for language files, so it's trivial (unavoidable?) for the programmer
> to write software that deals with different languages easily.
>
> EG: OpenDOS extended linguistic API features
>
> - Provide sorting tables for current character set and all that stuff DOS does anyway
> - Standard LANGUAGE environment variables, takes 2 letter code like
> KEYB (UK, US, GR, FR, etc)
> - C library routines (libopen.a?) to access language file:
>
> char *od_string(char *ID);
> - usage: puts(string("TEXT:out of memory");
> (entire printf family redefined w. extended API)
>
> - Utility to scan source files for the string "TEXT:*", to extract a list of all language
> ID strings and autogenerate an empty language file containing them. This makes it real easy
> to add language strings; otherwise, the programmer has to synchronise the names in his source and
> the language files himself
>
> - The printf family is redefined thus:
>
> od_printf("The address of %s:name% is %s:address%","name","Alaric","address","alaric AT abwillms DOT demonc DOT co DOT uk");
>
> Thus, the same argument ordering can be used with format strings in a language that expects
> the words in a different order - more general than standard printf positional notation.
>
> This printf could intelligently decide when to use direct screen writes or connect to
> fast 32 bit stream drivers, also.
>
> - The C library automatically opens a language file based on the language code it finds in
> the environment, and the name of the application, when this call is made:
>
> od_init_international("app name");
>
> ABW
>
>
> --
> Alaric B. Williams (alaric AT abwillms DOT demon DOT co DOT uk)
>
> ---<## OpenDOS FAQ ##>---
> Plain HTML: http://www.delorie.com/opendos/faq/
>
>
jude <jdashiel AT eagle1 DOT eaglenet DOT com>
- Raw text -