Quote:
Originally Posted by Valloric
The file probably doesn't specify an encoding. Never import such a file; Sigil (or any other application for that matter) has no idea what encoding it's supposed to use so it falls back to the system default encoding. On your machine that matches the encoding of the file (purely by accident!), but on his machine it does not.
Make sure your HTML files specify an encoding, either through a <meta> tag, a BOM mark or in the <xml> declaration.
I plan on adding a subsystem that uses heuristics to guess the encoding in such situations, but that subsystem would best be described as an airbag; even when you have one, it's still a good idea to avoid smashing into walls at 80mph.
|
Valloric:
It's entirely possible that I would do that, because my Fu can be, hmmm, hectic;
but not this guy. He would no more output html without a specified encoding than the Pope would get married tomorrow in St. Peter's to a male partner. That's not what's going on. If he uses the same file and opens it in Sigil in Windows in his VM, it works fine; if he opens it in Linux, it strips the extended characters.
We'll certainly test it some more--and, as I said, were it I we were discussing, I'd agree that the possibility is good--but it just seems wildly unlikely with this particular guy, who's so OCD he argues with me about using workarounds to accommodate Kindle in the subsequent epub-to-mobi conversion because the coding isn't ideal. {shrug}.
EDIT: Un-be-liebable. He did actually screw up, because we were working in a draft, and that's what happened--he imported sans encoding. At least if it happens again, I'll know what to look for. Hell, we have it (the encoding text) built into our NT clips--still not sure HOW it could have happened--but at least we do know WHAT it was, so I can stop having cardiac arrest about other books.
Thanks,
Hitch