New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ship a display table mapping dots to brl/brf character set #503

Closed
rimas-kudelis opened this Issue Jan 3, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@rimas-kudelis
Copy link
Contributor

rimas-kudelis commented Jan 3, 2018

From the little info I found on the internet, it seems that BRL/BRF files are using pretty much a standardised mapping of dots to 8-bit characters.

Thus I want to suggest to officially ship a separate display table which would allow conversion of text to "quick and dirty" Braille code.

The idea came to me after checking out how Send to Braille works. To make it work properly with non-English texts, it will likely be necessary to use a display table specific to the format, but no table seems to be officially designated as such.

I managed to make the conversion work both ways for Lithuanian, by specifying text_nabcc.dis,lt-6dot.tbl as the table to use in both Send to Braille's batch files, but text_nabcc.dis is marked as obsolete, so I suppose it might be removed anytime, which would make it difficult to convert between normal text and brl/brf. So I suggest to rename it instead of removing.

@rimas-kudelis

This comment has been minimized.

Copy link
Contributor Author

rimas-kudelis commented Jan 3, 2018

This should also play well with the idea expressed in #307, as I don't suppose there are that many different (and at the same time useful) display modes for Braille dots. At the same time, I assume they are mostly independent of the locale in use, and if that assumption is correct, it would make sense to ship one table designated as "ASCII Braille" or "BRF/BRL Braille" or whatever, instead of expecting that people will somehow know that they have to include text_nabcc.dis in their tables.

In fact, even now that I found this table, I'm still not sure whether or not I should include it in my Lithuanian tables. What is the desired result lou_translate should produce when forward translating with just one language-specific table?

@bertfrees

This comment has been minimized.

Copy link
Member

bertfrees commented Feb 12, 2018

I don't know who made text_nabcc.dis obsolete and why. I never thought of removing it. NABCC is indeed a much-used mapping for BRF files. But it's not the only mapping used. So shipping one display table names "ASCII braille" would be confusing I think. "ASCII braille" has no single meaning, it is a collective term for of all sorts of mappings.

To the question whether or not to include text_nabcc.dis in your Lithuanian table, I can be clear: I think ideally no table should include any display tables, and the display table should be specified explicitly when using a tool like lou_translate. This is what I'm trying to say with #307. However at the moment it is still allowed to include display tables, and a lot of tables do it. So it's up to you.

@rimas-kudelis

This comment has been minimized.

Copy link
Contributor Author

rimas-kudelis commented Feb 12, 2018

Ah, thanks for finally responding here! :) In the meantime, I myself have accumulated a little bit more information.

First of all, I think text_nabcc.dis, as it is now, is somewhat defective. The reason why I say this is that it maps multiple characters to same dot combinations using display rules (this is most visible if you look at mappings of uppercase and lowercase letters to dots, which are same). When forward-converting, the output is all lowercase, which I suppose will work for 6-dot users, but not so well for 8-dot users. If that table is to be the true NABCC table, it should map uppercase letters appropriately.
I just googled for "The North American Braille Computer Code", and one of the fist links points to a BRLTTY page. If that mapping is correct, I could gladly submit a patch for text_nabcc.dis, or just a new table, if that one should stay as is (although it's name would be misleading in such case).

Regarding Braille ASCII: there is a ton of information on this particular character encoding, and some converters (for example, Dolphin EasyConverter) are producing BRF files using it. I think a separate display table to convert to and from this encoding might be useful, especially in back-translation, to preserve letter case. Perhaps the lack of this separate table is the reason why text_nabcc.dis maps uppercase letters to wrong dots?

@bertfrees

This comment has been minimized.

Copy link
Member

bertfrees commented Feb 12, 2018

OK, yes please provide that patch. But just modify text_nabcc.dis, don't create a new table.

A table for "braille ASCII" would be welcome too. At least, if it doesn't exist yet. en-us-brf.dis may be exactly it. In any case, if you create a new table, put "US" somewhere in the name, or "North American", so that it's clear which "braille ASCII" it is we're talking about.

Thanks!

@rimas-kudelis

This comment has been minimized.

Copy link
Contributor Author

rimas-kudelis commented Feb 12, 2018

I would actually prefer not to include region codes in the names of these tables, or at least not in front of the file name. After all, they're used by hardware, and quite likely in a locale-dependent fashion, at least that would be my guess.

@rimas-kudelis

This comment has been minimized.

Copy link
Contributor Author

rimas-kudelis commented Feb 12, 2018

Indeed, en-us-brf.dis is the Braille ASCII table. With a name like this, it's easy to miss... :)

@bertfrees

This comment has been minimized.

Copy link
Member

bertfrees commented Feb 12, 2018

What do you mean exactly with "used in a locale-dependent fashion". It is an American mapping, so why not put it in the name? An alternative would be to use the name "SimBraille".

@rimas-kudelis

This comment has been minimized.

Copy link
Contributor Author

rimas-kudelis commented Feb 12, 2018

I suppose since I'm not creating new tables after all, I'll just keep their current names.

Should I sync text_nabcc.dis with the respective BRLTTY table? Apparently, real NABCC [https://en.wikipedia.org/wiki/Computer_Braille_Code](only defined 95 mappings), and even these were using 6 dots only, with 32 multi-cell mappings, so that file name might as well be inaccurate.

My idea here was to produce a table which could be used to convert files to and from BRL format used in semi-autonomous Braille displays and notetakers. This is also what I meant by "locale-independent fashion": I doubted that these BRL files would look differently when produced on an American version vs some European version of the same model. Although now I've just looked at the user manual of a BrailleEdge 40 device, and it seems you might be right: at least that device seems to interpret BRL files depending on chosen locale. Then again, there's only a handful of locales available, and all others would have to convert to/from one of these.

@bertfrees

This comment has been minimized.

Copy link
Member

bertfrees commented Feb 12, 2018

OK I see, so apparently NABCC is a complete braille code, not just a simple dots-to-character mapping.

The display table we have in Liblouis is just a dots-to-character mapping that is partly based on the NABCC code. But besides the 95 characters from NABCC, the table also contains characters from the Nemeth code, and some mappings have just been made up in order to obtain a table that contains all the 256 combinations. So maybe NABCC isn't the best name. However I can't immediately come up with a better name so let's leave it for now.

I'm not sure why the table maps uppercase letters to wrong dot patterns. The table has this comment but it doesn't match the actual rules beneath it:

# The 26 uppercase letters A-Z) are the same as their lowercase counterparts 
# except that dot7 is added:

I think probably a mistake has been made when converting the BRLTTY table. Yes, I think syncing it again would be good.

@rimas-kudelis

This comment has been minimized.

Copy link
Contributor Author

rimas-kudelis commented Feb 13, 2018

Alright then, I'll make a PR later today or this week.

@bertfrees bertfrees added this to the 3.5 milestone Feb 18, 2018

@bertfrees bertfrees self-assigned this Feb 19, 2018

@egli egli closed this Mar 5, 2018

@bertfrees

This comment has been minimized.

Copy link
Member

bertfrees commented Mar 5, 2018

Fixed by #513

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment