[liblouis-liblouisxml] Re: lou_translate: unicode output?
- From: Simon Aittamaa <simon.aittamaa@xxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Sat, 17 Jan 2015 12:13:15 +0100
I agree, iconv seems to be available on OSX as well (might be an optional
packet?).
Just as Bert states, iconv would be an optional dependency, and the hack
for UTF-8 and UTF16 would still benefit users w/o iconv.
On 17 January 2015 at 12:07, Bert Frees <bertfrees@xxxxxxxxx> 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,
> >> >> > Simon
> >> 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:
