On Tue, Oct 14, 2008 at 12:04:59AM +0200, Uwe Stöhr wrote:
> Andre Poenitz schrieb:
>
>> According to the bug description that's not a single file but all files
>> that come from a XeTeX/kile combination.
>
> OK then some more files than one ;-) but no real solution. Could you
> please add a comment that this code is there to assume the encoding from
> LaTeX files created with a a XeTeX/kile combination?
Well, there is a comment saying
// magically switch encoding default if it looks like XeLaTeX
Feel free to change this if you think this is insufficient.
>>> You rever to bug 3035, right? This is the showstopper, but you don't
>>> fix it. Bug 4299 was marked as duplicate of this. I'm still confused
>>> what you intention was.
>>
>> Fix a bug?
>
> Yes, otherwise you would have needed an OK from 2 developers, but got
> only one from Richard ;-)
>
>> And #4299 was in the line above #3035 in your mail. Sorry for reading
>> top-down...
>
> 4299 is a duplicate of 3035, I referred to it that you see one more
> instance of the same bug.
>
>> Apart from that I still don't understand what #3035 is actually
>> refering to.
>
> There are several spacing characters in Unicode. As we currently read
> them using latin1, we loose the spaces that are only available in
> Unicode, but not in latin1 -> dataloss.
We do not handle catcodes properly, have no idea of scopes of macro
definitions, do not handle 96% of plain TeX properly, have no idea about
what happens in .sty or otherwise \included files.
Compared to that losing some spaces seems rather insignificant,
especially if .tex traditionally rather uses some 7bit clean
"description" of "things" instead of "real unicode".
So, by all means, #3035 is not "major".
Andre'
