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.
