You probably have some good points.
However, in Windows I do only forward translation, although I need the
input/output pointers.
My input is 16 bits, not UTF, so that should give no problems, although because
of this Unicode characters outside the 16 bit range are not supported.
The output is 8 bits braille at the maximum (16 bits if the braille characters
in the Unicode table are being used), so it should also not present any
problem. In the past I have worked with all kinds of code pages and multibyte
conversions, including Japanese.
Conversion from 16 bits to 32 bits would not be a problem if restricted to the
conversion from text to braille.
Arend
From: Michael Whapples (Redacted sender "mwhapples" for DMARC)
Sent: Tuesday, January 5, 2016 12:30 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Using liblouis within an Android app.
As i suggested though, you still should be doing some validation/conversion due
to the differences of UTF16LE and UCS2, one being variable width and containing
characters the other cannot. May be one can get away with it in most cases, but
possibly not always.
So for that reason I say if things are done correctly then 32-bits would be
little additional work.
Equally on many Unix systems they use 32-bits for unicode, so having liblouis
set only to 16-bits would just move the problem on to those platforms.
If liblouis were to use UTF-16 (the variable width encoding) instead of UCS2,
or at least for the function calls, then much of this would go away. Embedded
developers would be happy as bytes are not wasted (or at least compared to what
they have now with UCS2), those who need to represent characters which need
32-bits still could, there would be a single definition of widechar, etc. Well,
actually if being as lean as possible on bytes then it should be UTF-8. I am
ignoring the encoding/decoding work as that is needed by some already anyway
and is achieved simply with existing libraries.
Michael Whapples
On 05/01/2016 11:16, Arend Arends wrote:
I meant 16 bits instead of 32 bits, as Michael pointed out.
Arend
From: Arend Arends
Sent: Tuesday, January 5, 2016 12:09 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Using liblouis within an Android app.
My preference is that the define for widechar is kept in the code. It would
be easier if it would be contained in a (separate) header file. If not, I would
still try to define it as 32 bits. Else I would have to convert the in- and
output strings to 32 bits, which is not a big problem, but is extra work
anyway, with possibly a provision needed for values outside the 32 bits range.
Arend Arends
From: Davy Kager
Sent: Tuesday, January 5, 2016 12:02 PM
To: mailto:liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Using liblouis within an Android app.
The choice of specific data types, not just signed int for everything can
definitely cause some trouble. As far as I’m told on a desktop system they all
expand to 32-bit or 64-bit memory slots anyway. On embedded devices this is
probably very different.
That having been said, we seem to get more (static) variables with every
release. Maybe developers aren’t aware enough of the requirements for embedded
systems? I’m not criticizing past decisions, but I would like to get a better
grasp of what’s required and what to keep an eye on when coding.
Van: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] Namens Michael Whapples
Verzonden: dinsdag 5 januari 2016 11:53
Aan: liblouis-liblouisxml@xxxxxxxxxxxxx
Onderwerp: [liblouis-liblouisxml] Re: Using liblouis within an Android app.
I have raised that question in the past and it always gets the reply that
embedded device developers who use liblouis need to keep it small, even to the
point where every byte matters. I think I have only ever heard one concrete
example of such a user of liblouis.
I guess there still is the question, can one library really be suitable for
all situations and do them all really well? What I mean by that is that if
someone has to use it in an environment where every byte matters, do they
really want to use something which also gets used on desktop systems. It goes
equally the other way round, something which wastes no bytes, is it really
going to make the most of a desktop system? Will such a jack of all trades be
easy to maintain?
Michael Whapples
On 05/01/2016 10:40, Davy Kager wrote:
Probably (do we even need multiple sizes, is the overhead of UCS4 that
much?).
Van: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] Namens Bert Frees
Verzonden: dinsdag 5 januari 2016 11:37
Aan: liblouis-liblouisxml@xxxxxxxxxxxxx
Onderwerp: [liblouis-liblouisxml] Re: Using liblouis within an Android app.
Yes but I guess applications might want to know at build time?
2016-01-05 11:29 GMT+01:00 Davy Kager <DavyKager@xxxxxxxxxx>:
> How are other libs going to know the size of widechar?
In liblouis.h.in we also have this function, which may help judging by
its documentation:
int EXPORT_CALL lou_charSize ();
/* Return the size of widechar */
-----Oorspronkelijk bericht-----
Van: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] Namens Christian Egli
Verzonden: maandag 4 januari 2016 11:35
Aan: liblouis-liblouisxml@xxxxxxxxxxxxx
Onderwerp: [liblouis-liblouisxml] Re: Using liblouis within an Android
app.
On 12/29/2015 08:54 PM, Dave Mielke wrote:
> I have liblouis building with the Android NDK now.
Cool. Did you write a java wrapper or did you use one of the existing
ones?
> There are two fixes that could be made:
>
> First, the simple one: I'm probably compiling with more warnings
> enabled. I'm
> getting:
>
> liblouis/compileTranslationTable.c: In function 'resolveTable':
> liblouis/compileTranslationTable.c:4650: warning: passing argument 1
of 'copyStringArray' from incompatible pointer type
> liblouis/compileTranslationTable.c:4629: note: expected 'const char
**' but argument is of type 'char **'
>
> This, of course, could easily be fixed. I can do it. Would you prefer
> that I post a patch to this mailing list, or would you be willing to
> add me (github user DaveMielke) as a developer so that I can push it.
> Or, maybe, you'd prefer some other method.
I've seen this warning but haven't been bothered by it hard enough to
figure out how to fix it. I'd be very happy if you could provide a patch either
directly to the mailing list or preferably via a pull request on github.
At the moment I'm a bit reluctant to just hand out push access to the
repo.
> Now, for the more complicated one: The liblouis.h header needs to be
> derived from liblouis.h.in for exactly one small reason:
>
> #define widechar @WIDECHAR_TYPE@
>
> Is this because having liblouis.h include config.h is seen as
> undesirable? As I see it, either liblouis.h could include config.h or
> it could include some other very small header that just #defines
> widechar. This would eliminate the need to save a whole separate copy
of liblouis.h just for that one line.
Hm, I had never thought of that solution. If I understand correctly we
would have to define a config.h.in and define WIDECHAR_TYPE in there or
alternatively we would have to AC_DEFINE widechar in configure.ac, because at
the moment it doesn't seem to be defined in config.h. Also presumably config.h
will not be installed. How are other libs going to know the size of widechar?
That would direct towards your second suggestion of extracting the #defines
widechar into a very small header file.
Thanks
Christian
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
For a description of the software, to download it and links to
project pages go to http://liblouis.org
DISCLAIMER:
De informatie verzonden met dit e-mail bericht is uitsluitend bestemd
voor de geadresseerde. Indien u niet de beoogde geadresseerde bent, verzoeken
wij u vriendelijk dit aan de afzender te melden (of via:
info@xxxxxxxxxx<mailto:info@xxxxxxxxxx>) en het origineel en eventuele kopieën
te verwijderen.
The information sent in this e-mail is solely intended for the individual
or company to whom it is addressed. If you received this message in error,
please notify the sender immediately (or mail to
info@xxxxxxxxxx<mailto:info@xxxxxxxxxx>) and delete the original message and
possible copies.
For a description of the software, to download it and links to
project pages go to http://liblouis.org
DISCLAIMER:
De informatie verzonden met dit e-mail bericht is uitsluitend bestemd voor
de geadresseerde. Indien u niet de beoogde geadresseerde bent, verzoeken wij u
vriendelijk dit aan de afzender te melden (of via: info@xxxxxxxxxx) en het
origineel en eventuele kopieën te verwijderen.
The information sent in this e-mail is solely intended for the individual
or company to whom it is addressed. If you received this message in error,
please notify the sender immediately (or mail to info@xxxxxxxxxx) and delete
the original message and possible copies.
DISCLAIMER:
De informatie verzonden met dit e-mail bericht is uitsluitend bestemd voor de
geadresseerde. Indien u niet de beoogde geadresseerde bent, verzoeken wij u
vriendelijk dit aan de afzender te melden (of via: info@xxxxxxxxxx) en het
origineel en eventuele kopieën te verwijderen.
The information sent in this e-mail is solely intended for the individual or
company to whom it is addressed. If you received this message in error, please
notify the sender immediately (or mail to info@xxxxxxxxxx) and delete the
original message and possible copies.
