On 9/11/2009 10:41 PM, Christian Egli wrote:
First we will have to agree on the format of a header line in
tables containing the necessary information.
The question is what constitutes the necessary information. If we agree
on the struct then the format of the header line can be deduced.
While I have no problem with the header line, a question I have raised
in the past is why we couldn't include all of the necessary
information in the filename. This would certainly make scanning much
faster. See below for an example. Note that we would still need to
include the table's descriptive name in the header line; e.g. "Unified
English Braille Code grade 1".
struct table_info {
char iso_language[2]; /* ISO 639-1 */
char iso_region[3]; /* ISO 3166 */
short grade;
I don't think grade is enough here. Computer braille is also a form of
"grade" which doesn't fit into the normal idea of grades. Also, in
English, computer braille is sometimes called grade 0, whereas this is
not the case in some other languages; e.g. if I recall correctly,
grade 0 in German is not computer braille. Having said that, we could
just always give computer braille a grade value of -1. Another thing
to consider is that I think the concept of computer, uncontracted and
contracted braille is often more useful than grades.
Given this structure, we can have filenames as follows:
iso_language-iso_region-grade-[-extra].extension
where extension is: ttb for computer (text) braille, utb for
uncontracted braille and ctb for contracted braille. extra is for
differentiating two similar tables; e.g. braille codes from different
years.
Examples:
* en-US-comp6.ttb
* en-US-comp8.ttb
* en-US-g1.utb
* en-US-g2.ctb
* en-unified-g1-UEBC.utb (Note the use of unified in place of the ISO
region)
This last one looks a bit obscure, but it's a start...
The questions remain how we deal with 6 and 8dot tables, with computer
braille and with UEBC?
See examples above.
Jamie
