I do see disadvantages.If it is optional with a fallback when not taking the option, we have two ways of doing one thing. May be one option offers more, but nevertheless some functionality has multiple implementations.
This sounds like more stuff to maintain. Do we have a maintainer for all this? Who will maintain the fallback code? Will everyone need to respect the fallback code or is it fair game to break that code as you don't use it and so have no responsibility to ensure it works, the maintainer of the code has to handle the breakage (if a maintainer even exists).
My fear is that the fallback could easily become an unmaintained piece and soon become the pile of unmaintained junk like the MSVC build script which is only there to cause one to get ones hopes up and end in disatisfaction when it does not work.
Just my thoughts, take what you will from them, may be those things are not a concern to the project as a whole.
Michael Whapples On 17/01/2015 11:07, Bert Frees wrote:
It would be an optional dependency. So for Windows users nothing will change except they can get utf16 encoded unicode braille on the command line. However by using iconv on Linux we get encoding in the user's LOCALE for free. A lot of programs have optional dependencies to enable optional features, I don't see any disadvantages. John J. Boyer writes:I don't think that using a dependency that is available only on *noix is a good idea. Probably liblouis is most used with Windows, to say nothing of OSX. I would like to see liblouis with no dependencies. John On Sat, Jan 17, 2015 at 11:00:04AM +0100, Bert Frees wrote:Oh. Right. Yes it's only UTF-8. Using iconv and falling back on a very simple encoder sounds very reasonable. Encoding unicode braille as UTF-8 or UTF-16 are just oneliners. And we'll add some automake checks for iconv. What branch are you working on? Simon Aittamaa writes:Hi Bert, That patch is only for UTF-8 output, unless I missed something? My patch is based on iconv, which I would say is preferable on *nix systems... As I suggested earlier, we could introduce a new function, showStringUnicode() which in turn could use iconv (if available), and fallback on hand-crafted UTF-8 on encoder on *nix and hand-crafted encoder for UTF-16 on windows (or simply use the windows API). Since we are _probably_ only going to output a limited subset of Unicode, i.e. U+2800..U+28FF, we don't have spend that much time on handling edge-cases, we can simply error-out on anything that isn't a braille-pattern, or? Best, Simon On 15 January 2015 at 19:28, Bert Frees <bertfrees@xxxxxxxxx> wrote:Hi Simon, I thought I had added a unicode option to lou_translate, but it was lou_trace and it's on a branch: https://github.com/liblouis/liblouis/commit/0b162ae430317713db5594d342f0a598813e79a3. Your patch is probably similar? Maybe we could combine our stuff, make sure it's done consistently etc. So if you want you can add changes to my branch, otherwise I'll assume it's okay and I just add the option to lou_translate. Thanks, Bert Simon Aittamaa writes:Hi, Is there any way to output unicode from lou_translate? For example: $ echo "Α" | lou_translate -uf unicode.dis,en-ueb-g1.ctb ⠰⠠⠨⠁ I've currently patch lou_translate for this, but I was wondering if there is a "standard" way of doing this? Best, SimonFor a description of the software, to download it and links to project pages go to http://www.abilitiessoft.comFor 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
