Le 9 déc. 09 à 22:48, G. Milde a écrit :
OK, so what about just keeping the last encoding and, after finishing
the parsing of preamble, resetting this encoding to "auto" if it is
the default encoding for the language?
But what to do if not? We should rather expect the other encoding to
be used (why would it be defined otherwise) or parse the whole
document first to be sure.
We should not parse the document in advance IMO. This is too much
effort for
a case that does not seem so useful.
BTW what would be you real-world examples of multi-encoding documents?
I am interested because I suspect that we do not have the same thing
in mind.
Or just set the encoding to "auto" unconditionally?
No. I want to keep e.g. utf8x also with a round-trip.
OK. Then the document encoding unconditionally.
A question that I have is: do we to fear that documents will be wrongly
output because of encoding, or are our unicode tables good enough (in
practice) to
work around problems.
I guess my question is: is the main problem correctness of the printed
result or
keeping the same encodings to make our tex-based coauthor happy?
The problem is that we have a lossy transformation. There are less
degrees
of freedom in LyX than in LaTeX.
We could add encoding to fonts, like we do for languages. But I do not
know how
useful this would be.
The current scheme is trying its best to get working results and
round-trips without encoding change.
I failed to find the discussion and the use cases that led to this...
That's why I do not grasp it yet.
To find out which encoding setting to use:
[snip reasonable proposals]
b3) use a premble command and ERT instead of or in addition to the
LyX
encoding mechanism.
I'd really like to avoid that.
JMarc
