Georg Baum wrote:
Abdelrazak Younes wrote:
The question is: should this conversion happens in C++/LyX or
externally? I am all for only utf8 export from LyX.
If that would be possible that would really be great, but see below for
possible problems.
The conversion from LateX utf8 to some other encoding can happen
afterwards thanks to some (python) scripts. I cannot see any degradation
of performance doing that as the conversion would be in any case an
order of magnitude faster than for example the conversion to dvi.
I don't think either that there would be a performance problem. What might
be a problem is that an inset knows more about its content (and, more
importantly, about the context) and could do a better conversion than an
external converter could do. For example, I am 100% sure that ucs4
characters exist that need to be translated to different LaTeX macros in
math mode and in text mode. In LyX we always know whether we are in text or
math mode. An external script would need to parse LaTeX, and if you think
that that is easy have a look at tex2lyx (which btw is far from perfect).
I understand... but IIRC Jose said at one point that he intended to
rewrite tex2lyx in python... ;-)
lyx2lyx knows already a lot about lyx internals doesn't it? Wouldn't
that be enough to convert these special cases with a special lyx2lyx
mode? Just asking, I obviously don't enough know enough on this matter.
In summary and IMHO: let's keep the core C++ LyX simple and only support
utf8.
With my proposal the core would be simple and not even know about utf8, only
ucs4, except for the cases like the example above.
IMO we do not need to answer now the question whether the conversion will be
external or not if we follow my proposal. I really would like to know what
others think.
If your solution is not going to complicate the core more than needed
then I say go for it. You are probably the best knowledgeable developer
in this field around here...
Abdel.
