[liblouis-liblouisxml] Re: Liblouis table header
- From: Larry Skutchan <lskutchan@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Tue, 21 Oct 2014 10:16:32 +0000
Those are some excellent points.
It might also be useful to have a way to specify a table type. Types might
include literary, math, and music.
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of James Teh
Sent: Tuesday, October 21, 2014 12:19 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Liblouis table header
Hi Bert,
As I've noted in the past, I'm very much in favour of something like
this in principle. I like your proposal. It's probably the most
versatile and extensible so far. However, it's always the tricky details
that we never quite manage to iron out.
I have two major concerns:
1. I don't think the concept of grade applies well to all braille codes.
For example, grade 1 in English is uncontracted and grade 2 is
contracted. I believe there are other languages where grade 1 is
actually contracted. I think we need to come up with a concept that
applies more universally; e.g. computer braille, uncontracted,
contracted, special purpose. Of course, a given code might have more
than one table in each category, so the "grade" concept might still be
useful, but perhaps not as a primary means of searching.
2. Some tables cover multiple locales; e.g. UEB would probably specify
multiple locales. Nothing in your proposal prohibits this, but it needs
to be taken into account as far as searching goes.
3. Minor, subjective point: Can we have display_name or friendly_name
instead of pretty_name? :)
4. It would certainly be good to take localisation of
pretty/friendly/display names into account as you have suggested. This
eliminates the need for every project to localise these itself (making
for wasteful duplication of effort) as is currently the case. Going
forward, one concern would be how to get these names localised. While
NVDA and other projects have translators, these use more standard
formats and have established workflows. We'd need to find some way to
make it easy for existing translators to provide localised table names.
5. It's also worth noting that putting the localised names in the table
file would mean a fairly significant (potentially 50+) number of
key/value pairs in each table. Might this cause performance problems?
Jamie
On 21/10/2014 12:49 AM, Bert Frees wrote:
> Hi all,
>
> I want to bring this subject up again because we've been discussing it so many
> times and I think it's about time we finally do something. To recap, we need
> to
> develop a header format that can contain metadata about the table, and an API
> for extracting metadata and querying tables.
>
> Greg's proposal with the single-line comment on the first line was a good
> start. But I'd like to have something a bit more flexible/extensible. I have
> worked out something and I'd like to have you guy's opinions and suggestions.
>
> For my DAISY Pipeline 2 work I have been nurturing the idea of selecting
> translators based on some kind of "translator query". The use case is quite
> the
> same as we have here for liblouis. The syntax I am proposing for DAISY
> Pipeline
> is inspired by CSS media queries. A query is basically a list of key-value
> pairs
> or keywords. I'm not proposing to use exactly the same syntax for liblouis,
> but
> I believe we need something similar/mappable.
>
> Let's take Greg's example:
>
> #afr#1#Afrikaans Uncontracted#za#Afrikaans ongekontrakteerde
>
> It consists of 5 metadata fields. 3 of them can be used for automatic table
> selection. The two other are for pretty printing in graphical user
> interfaces. Combining the two locale fields (language and country) into a
> single
> tag, the corresponding CSS query would look like this:
>
> (locale:af-ZA) (grade:1)
>
> The same key-value pairs could be put in liblouis table headers. I like the
> idea
> of having the metadata in special comments, in order to assure backwards
> compatibility of new tables with old library versions, and so that
> implementations of the liblouis table format can choose whether or not they
> support metadata.
>
> A possible syntax could be `#+<KEY>: <value>`
>
> #+LOCALE: af-ZA
> #+GRADE: 1
> #+PRETTY_NAME: Afrikaans ongekontrakteerde
> #+PRETTY_NAME_EN: Afrikaans Uncontracted
>
> (This is org-mode's syntax by the way.) The keywords would be
> case-insensitive. Some keywords will be standard, such as LOCALE, GRADE and
> PRETTY_NAME, but I wouldn't restrict the allowed keywords in any way, in order
> to keep the system flexible.
>
> The CSS query syntax also allows single keywords, without a value. For
> example:
>
> (ueb) (grade:2)
>
> This could be reflected in a `#+TAGS` field with a list of space-separated
> "tags":
>
> #+LOCALE: en-US
> #+GRADE: 2
> #+TAGS: ueb
>
> I haven't really thought about the API yet. It would be nice if one could
> provide a list of key-value pairs and/or single keywords, together with a
> table
> path, and get a table name back. The keys could possibly be sorted by
> importance, and the API could possibly return some kind of "matching quotient"
> that indicates whether the table is a good match for the query or not.
>
>
> Thoughts?
> Bert
> For a description of the software, to download it and links to
> project pages go to http://www.abilitiessoft.com
>
--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: jamie@xxxxxxxxxxxx
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
