I agree, I think it is a good idea to have it that the table is self contained (IE. it has all these properties defined in itself). This simplifies it should a user want to add a table, just put the table in the table directory, no editing data files.
Localisation is something else. Michael Whapples On 21/10/2014 17:21, Bert Frees wrote:
It's not a bad idea and it's an approach that I and others have been using in our applications. But whether we put this information in the table file itself or in central file is really not that crucial. What matters is that a table can have a lot of properties, and we need a good mechanism to select tables based on a number of parameters. And, most important, that we're all using the same tables across applications. For the selection criteria, I would say put them in the table file itself because then when looking for tables you're not limited to the ones that are included in the main distribution (unless you can have several such "index cards", as you call them, on your table path). Also, I think it's nice to have all the information about a table right at the top. For localization strings, I'm not sure yet if we should put them in the table, because there can be a lot of them so it could bloat the table. By the way, Ken, here are some links to related conversation we've had in the past (can't find them all). //www.freelists.org/post/liblouis-liblouisxml/Translatable-table-names-in-Liblouis-independent-with-screen-readers-now-used-methods-possible-doing-this //www.freelists.org/post/liblouis-liblouisxml/Grouping-tables-according-to-language-and-Braille-code //www.freelists.org/post/liblouis-liblouisxml/List-of-Braille-tables-standalone,15 //www.freelists.org/post/liblouis-liblouisxml/Table-of-human-readable-tables Ken Perry writes:If not xml it still is not a bad idea to have this in an index card. I just can't see why you would want this in the top of every table. So whatever you want to call the file that would be fine with me. Ken -----Original Message----- From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy Sent: Tuesday, October 21, 2014 10:16 AM To: liblouis-liblouisxml@xxxxxxxxxxxxx Subject: [liblouis-liblouisxml] Re: Liblouis table header Ken. As an XML fan I like the idea but really since LibLouis doesn't use XML anywhere else it makes more sense to me to keep it as a simple key/value table. Why add XML dependencies to something that has no compelling need to use it? -----Original Message----- From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Perry Sent: Tuesday, October 21, 2014 9:55 AM To: liblouis-liblouisxml@xxxxxxxxxxxxx Subject: [liblouis-liblouisxml] Re: Liblouis table header I wonder though if this would not be better done as an extra xml file like an index card sort of like how a daisy book is done. For example the xml file could have all the info for a certain set of tables. It could also list all the tables that are included in the grouping for example for ueb it could have all the latten files and the braille pattern file listed as files to include if you want contracted ueb. Thus the xml tool could be used not only as a pretty way to show the name of the tables but also a way to group sets of tables together so you know what tables are affected when you make changes. An index card could also show relationships between different tables. And you wouldn't have to have info at the top of every table just a card for each language or braille type. KenFor 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
