Speakin' of weird: Linux build eating accented chars.

[Hitch]

Hey, kids (Valloric!):

Don't try THIS at home. One of my guys is running Xubuntu 10.04. VM is XP SP3. 64-bit. When he imports perfectly good html into Sigil, what gets exported vis-a-vis accented characters is that the accented chars get eaten, entirely...so that "Déjà vu" comes out as "dj vu." It happened on other words, like resume, cafe, etc., so that you get resum, caf, and the like. Oddly enough, my authors are a bit perturbed about this, the ingrates.

FWIW, the html editor he uses outputs Windows-1252 (another convert to NoteTab!), but I don't think that's playing into it, since I use the same editor.

We've tested it with both of using the same html file...and it works fine in my Sigil, which is plain jane Windows 32-bit, but the Linux is just sucking the tasty accented vowels right outta there.

Anyone else experiencing this? Anyone else even notice it? We're going to test some more snippets before we put in a bug report, but I didn't see anything else that suggested that it had been noticed by anyone else.

It's actually problematic for me...some of my sub-contractors use Linux, and I can't be giving them books if I have to get ulcers over this, which isn't going to help their income stream, either. Thoughts? Confirms?

Hitch

[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.

[Hitch]

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