Angus> You mean things like the TOC that Angus> are generated dynamically from the Angus> LyX document? Actually, I've never Angus> really understood the problem here Angus> either. We know the encoding of the Angus> document and we know the encoding Angus> used by the GUI. We just don't convert Angus> from one to the other.
Angus> Or do I miss something? JMarc> We give to qt strings that are JMarc> 8bit-encoded. Therefore qt decides JMarc> these are iso8859-something strings. Right, but again, that's our fault isn't it? Our poor Qt frontend has to do the best it can when it generates a QString from the std::string passed to it because we should be telling our frontend about the encoding of the characters in this std::string (possibly more than one!). However, we don't pass this encoding data to the frontend so it has to do the best it can to guess it. I realize I'm thinking out aloud here and that the whole problem will go away when Unicode arrives, but I'd never really considered the problem before ;-) Anyway, all this is beside the point. Do we ever exercise libiconv on *nix? Has Tomasz discovered a latent bug in our use of libiconv, or does the problem lie in the Windows implementation of same? Regards, Angus
