Hi Keith, On Wed 27/08/14,13:35, Keith Creasy wrote: > I wish LibLouis only represented Braille as Unicode. You are not alone in this sentiment, and both new maintainers and product developers such as yourselves want this to happen. The issue at the moment is that the code is quite brital and code functions have many and unforseen side effects due to heavy use of variables in the global namespace. Before we start digging into rewriting certain parts or implementing new features it is important to have an extensive test coverage, that way at least we can see if/when/how something breaks. It is no good implementing new features and unintentionally breaking old functionality, which we have seen happen in the past. Think of it as a very slow rewrite/cleanup with Scaffolding. > You'll need to be careful because converting BRF to Unicode is still > basically converting ASCII to Braille. Duxbury creates BRF's in all > caps even though that isn't what they really intend (including a dot-7 > in every char). A normal ASCII to Unicode conversion (assuming you use > 8-dot Unicode) results in Unicode that includes dot-7. I worked around this by mapping both uppercase and lowercase a-z to the same dot Representation. > Using all caps is a legacy contrivance to support older embossers as far as I > know, > at least I don't know of any other reason for it. Yes, this is my understanding too. This should not force liblouis into lowest common Denominator, but infact should be a preprocessing step before sending to the older hardware, i.e. translate this document, and apply this dis file for non-standard output. > Using Unicode for test data is perfect but you'll have to be sure the > Unicode is correct. its not so much the unicode output, but the input that one starts off with. :-) Mesar
Attachment:
signature.asc
Description: Digital signature
