[liblouis-liblouisxml] Re: Grouping tables according to language and Braille code
- From: Mesar Hameed <mesar.hameed@xxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Tue, 24 Jul 2012 23:28:17 +0100
Hi John,
On Tue 24/07/12,15:42, John J. Boyer wrote:
> This is a good start. For BrailleBlaster it would be nice to have an
> explicit statement of the language and the braille code. For example,
>
> table en-us-g2.ctb, English-us, Grade 2
Yes, one is provided by the first touple element, and the description as the
second element, Or did I miss understand you?
The reason why its two elements rather than one, is that the second is
localizable and can not be relied upon to pick the right table.
For example if I use nvda or orca, and i look at the list of tables i should
see the following:
en-gb-g2 (used internally by program)
English UK grade 2
Lets say this is now selected.
I now switch nvda or orca to show its interface in swedish, I should see:
en-gb-g2 (again used internally to match the selected table)
Engelsk StorBritanian grad 2
the first element of the touple needs to always be the same so that orca or
nvda do not get confused when i reset their respective interfaces,
also good for saving user preferences.
@Jamie, have I overlooked anything?
> This list could be quite lengthy. The lou_listTables function would need
> two parameters, a pointer to an area where the list should be stored and
> the length of the area.
I am not sure about this, because the caller does not know how many tables that
the function will be returning, or the size of the strings.
A better approach might be for the function to check how many actual files it
has access to, then do a calculation based on that.
Maybe tableName and tableInfo could have a max length for each, making the
estimation of the required size easier.
Then this amount of memory could be allocated using malloc, and populated.
Then the function returns the pointer to this area to the caller, who is also
responsible for freeing the block when they finnished using it.
> What is the license for gettext? LGPL is fine, but not GPL. Can gettext
> be included in the liblouis build, like gnulib?
Yes, infact it is part of gnulib, and the header file is here:
trunk/gnulib/gettext.h
From the recipe here:
http://www.gnu.org/software/gettext/FAQ.html#integrating_howto
It looks quite straightforward to integrate into an existing project.
Thanks,
-- Mesar
> John
>
> On Tue, Jul 24, 2012 at 06:25:20AM +0100, Mesar Hameed wrote:
> > Hi John,
> >
> > What do you think about the following alteration:
> >
> > 1. we add new opcodes, tableName and tableInfo
> > tableName en-gb-g2 # probably the same as the actual filename of the table.
> > tableInfo English UK grade 2
> > These should be defined as the first non-comment lines of any table, so
> > that they dont get overridden.
> >
> > 2. A new function is added to liblouis: listTables(localizationLang)
> > The function iterates over the defined table paths, extracting the
> > information and builds up a list of pares.
> > tableName, localizedTableInfo
> >
> > The localizedTableInfo is obtained using a call to gettext, which if no
> > localization was found for the given string simply returns the english
> > default.
> >
> > If I am not too mistaken, this should address the requirements for Blaster,
> > NVDA and Orca.
> > The particular package can restrict the data as it wishes depending on
> > comboboxes etc.
> >
> > This solution also has the advantage that minimal maintenence is required.
> >
> > Thoughts?
> >
> > -- Mesar
> > On Mon 23/07/12,13:53, John J. Boyer wrote:
> > > For BrailleBlaster we are planing to give users a choice first of
> > > supported languages and then of the Braille codes for each language.
> > > Something like this has already been discussed on this list. Perhaps
> > > there could be a file in the tables directory with two columns, the
> > > first for a human-readable table name and the second for the actual name
> > > of the table file. This file could be divided into sectgions acording to
> > > language. Of course this would also be useful for NVDA and Orca. The big
> > > question is who is going to maintain it.
> > >
> > > John
> > >
> > > --
> > > John J. Boyer; President, Chief Software Developer
> > > Abilitiessoft, Inc.
> > > http://www.abilitiessoft.com
> > > Madison, Wisconsin USA
> > > Developing software for people with disabilities
> > >
> > > 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
>
> --
> John J. Boyer; President, Chief Software Developer
> Abilitiessoft, Inc.
> http://www.abilitiessoft.com
> Madison, Wisconsin USA
> Developing software for people with disabilities
>
> 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:
