Oh, I forgot the other reason I have heard.
Windows uses 16-bit unicode, so if liblouis were to use UCS4 then it
requires converting for every call of liblouis on windows. This may
actually be invalid, I have read that Windows is using UTF-16LE and not
UCS2 for its unicode so can have surrogate pairs to represent any 32-bit
unicode character which is not valid for the fixed width UCS2. Therefore
strictly speaking on Windows a conversion/validation of every string
passed to liblouis still should be done.
Isn't there a standard C unicode data type? One thought is wchar_t, but
I read that is compiler specific so may lead to issues should liblouis
be compiled with one compiler and the application with another.
I still feel a single definition of widechar is the best way forwards.
Michael Whapples
On 05/01/2016 10:53, Michael Whapples (Redacted sender mwhapples for
DMARC) wrote:
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 <mailto:DavyKager@xxxxxxxxxx>>:
> How are other libs going to know the size of widechar?
In liblouis.h.in <http://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>
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
<mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx>] Namens
Christian Egli
Verzonden: maandag 4 januari 2016 11:35
Aan: liblouis-liblouisxml@xxxxxxxxxxxxx
<mailto: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 <http://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
<http://config.h.in> and define WIDECHAR_TYPE in there or
alternatively we would have to AC_DEFINE widechar in configure.ac
<http://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><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><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: <mailto:info@xxxxxxxxxx>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 <mailto:info@xxxxxxxxxx>info@xxxxxxxxxx) and delete the original message and possible copies.
