At least for English braille in the U.S. “Grade 3” is rarely used and when it
is it is more for self-communication than publication. I’m not even sure there
is a formal standard for it. Please keep the term “full” for “grade 2”, or
really Contracted English braille. These are most commonly “English Braille
American Edition” (EBAE) or “Unified English Braille” (UEB.
Keith
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Bert Frees
Sent: Thursday, January 12, 2017 7:29 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Table metadata.
2017-01-11 18:24 GMT+01:00 Dave Mielke <dave@xxxxxxxxx<mailto:dave@xxxxxxxxx>>:
* #+contraction: Contraction grade, according to a universal meaning.
Possible values are
+ no
+ full
For English braille, I suppose "no" would mean grade 1 and "full" would mean
grade 2. But there are also grade 1.5 (partial?) and gradde 3 (shorthand?). Yet
another value could be "music".
Yes the idea is to add more values like "partial" or "shorthand". I just
haven't figured out good names/clear definitions yet. If there is a grade 3 (I
wasn't aware) that should probably be called "full", right? Or else the
definition of "full" vs. "shorthand" should be clarified.
I don't understand how "music" is a level of contraction. Can you explain?
For my Greek table, I'd like to add #+direction: with the values "forward" and
"backward". Can you think of better terminology?
That is perfect. Actually I thought I had added this to the documentation
already, but it seems I haven't.
The document also says "Note that various other metadata can be thought of, but
is not necessarily suited for discovery." But it'd still be useful. For
example, the tablet I'm writing code for offers a way to bring up a list of the
tables that shows a person-readable description of each. Right now, these
descriptions are hard-coded. It'd be much nicer to fetch them from table
metadata.
So, in addition to discovering a table based on metadata, I think there should
also be a way to return (perhaps an array of) strings for requested metadata
values.
Yes, I wanted to add this other group of metadata not suited for table
discovery in a later stage. The idea was actually to give them a different
syntax in order to distinguish. For now it's perfectly fine to add this
metadata with the only existing syntax. The more metadata the better! The
syntax can be changed later.
The human-readable description is a special case though, because things like
names and descriptions are also suitable for localisation, and I'd rather solve
the problem of localisation with a solution specially designed for that
purpose. I haven't found a good approach yet to solve this issue.
For now, it's alright to include the description like the rest of the metadata.
I also agree that an API call (and maybe in addition a command line tool) to
request the descriptions would be useful. Shouldn't be hard to implement.
