Dear Kornel,

On 2016-12-01, Kornel Benko wrote:

> Tests with unicodesymbols gave me many errors in iconv part. Debugging
> shows correct values in calls to open_iconv(), still there are
> exception events. My lyx was created using 3rdparty/libiconv, so I
> recompiled without the provided iconv.

> This version works, here the results of 'ctest -j12 -R unicodesymbols'

> 99% tests passed, 4 tests failed out of 1034
...
> The following tests FAILED:
>       379 - 
> export/export/latex/unicodesymbols/005-7-ipa-modifiers-combining_cp437_pdf2 
> (Failed)
>       447 - 
> export/export/latex/unicodesymbols/008-greek-and-coptic-with-textalpha_iso8859-6_pdf2
>  (Failed)
>       897 - export/export/latex/unicodesymbols/077-mathops_cp437de_pdf2 
> (Failed)
>       1274 - 
> export/export/latex/unicodesymbols/125_152-modifiers-presentation_cp850_pdf2 
> (Failed)
> Errors while running CTest

Out of these for, only 447 fails here, because I don't have Arabic support
installed (iso8859-6.def file missing).

The others work here and (afaik) for Scott.

447 is testing Greek with an arabic input encoding, so it would not be an
urgent problem if this did not work. Also, Scott reported it works.



> Can someone on linux check if using 3rdparty/libiconv is a bad idea?

>From your previous posts I suppose that the lower case of the encoding names
is a problem for the 3rdparty iconv. It may be worth testing if this is a
bug or just a more narrow interpretation of the arguments. If libc-iconv
support both cases, we could change the iconv names in lib/languages...

G√ľnter

Reply via email to