Georg Baum wrote:
Abdelrazak Younes wrote:

So, I will think a bit more about this and try to find a correct
solution for 1.5.0. Right now, the simplest solution I can think of is
to generate the correspondence table between ucs4 and the different
encodings using iconv and distribute that.

I also thought of that. I don't really like this solution, because not all iconv implementations behave alike (was discussed in bugzilla, but I forgot
the number), so a table that is valid for one implementation does not need
to be valid for another.

OK, then see below.

Another possibility that avoids this problem is to define the maximum UCS4
code point (and maybe minimum, too) for each encoding in lib/encodings. I
guess that this would speed up the table generation a lot, since all the
exotic code points do not need to be tested.

Yes, I thought about that too but I was too lazy to do the research for all encodings.


Or generate them on first use in Encoding::init().

??? This happens!

I mean on first use Encoding::init() i.e. on first LyX instance:

We can generate the correspondence table file on first use of the encoding and put that file in the resources directly. The next time LyX is launched day, Encoding::init() will first look at that file; if it is not there, LyX will re-generate it.

Abdel.

Reply via email to