Eike wrote:

If I understand correctly, technically spoken these are script types of
existing languages.

Technically, ASL is a language of its own, not a variant of English (US). BlissSymbolics --- which I didn't ask about, because the Unicode sequence is still being determined is in the same situation.

Of the three (Braille, Moon, ASL) Braille is the only one which has a named sequence in Unicode. The other two have Unicode glyphs that are not sequential.

> nor does the ODF file format provide mechanisms for storing them.
> This will hopefully be solved in the next version of the standard.

Is there a time frame for that?

* Submit a request for Braille as an language of its own, with one
request for each grade.  [Or more likely, two requests for each grade
--- that allows for multi-lingual content in Braille.]

This could be a possibility, using RFC 3066 x-... private tags. However,
there would be no connection to the underlying "real" language then,
which I consider a major drawback.

The connection to the Locale data of the underlying "real" language might be an issue. OTOH, if a "reasonable" default locale can be set, then it is "solvable".

Would it be possible for the default Braille locale to be changed according to the language/locale of the User Interface?
EG:
An Afrikaans default Braille Locale, for an Afrikaans User Interface;
An English (UK) default Braille Locale, for an English *UK) User Interface;
An Arabic default Braille Locale, for an Arabic User Interface;

Also Moon and ASL look like script types to me, if I'm not mislead.

ASL is a language in its own right. The association with English is simply because it was developed in the US. [A case can be made that American Sign Language, Australian Sign Language, Arabic Sign Language, etc are different languages, rather than dialects of the same language. (If you can communicate in one of them, you can understand any of them, albeit with the same degree of difficulty as an American has understanding somebody speaking South African English, with a working class Glasgow (Scotland) accent.]

Moon is a writing system, that has been transcribed for roughly 400 or so languages. The only language for which it currently has extensive use is English (UK). As with Braille, a private tag could be used. I doubt anybody would have objections to Moon (at least initially) having a default locale of English (UK).

Yes, locale data would be a problem then. Note that in case OOo
supported scripts, each locale, at least for the language dependent
parts, would also need Braille locale data then. Quite an amount of new
locales.

The "easy" but probably impractical solution would be to setup a default Locale for each country, that is then modified by the language, and then by the writing system. Braille, Moon, and ASL are always read left to right. [Handwritten Braille is written from right to left. Braille from a Braille printer is printed from left to right.]

########

Something that might be pertinent, is that adding these to the Locale/language options is only half the job. The next step would be to write a driver to transform the text into something that the respective printers can accept.

For all practical purposes, "paragraph and character styles" in Braille & Moon are non-existent. Both have a standard font size.

Page styles are important, only in as much it permits one to know where the end of the page is. [Standard Braille Paper is 11 inches by 11 inches. Standard Moon Paper is 12 inches by 10 inches. (Note to self: submit RFE for those to be added as standard page options.)]

As to why not use the language, with its standard writing system, and have the driver convert from Language(standard writing system) to Braille (Grade 2.0), the major issues is that that process does not allow for changes of the grade of Braille within a document, nor does it allow one to predict home much paper will be needed. Printing out just page 10, for example, becomes all but impossible. [Given the price of Braille paper, nobody wants to print out pages that are not needed.]

xan

jonathon

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to