Diacritics problem switching from Express to Pro

[prauz]

I recently switched from Express to Pro. Just now I noticed that some characters with diacritics in a document which I created in Express look different in Pro. In particular:

LOWERCASE E ACUTE was changed into CAPITAL A DIAERESIS
LOWERCASE A ACUTE was changed into LOWERCASE C CEDILLA
LOWERCASE I DIAERESIS was changed into LOWERCASE O GRAVE
LOWERCASE I ACUTE was changed into CAPITAL AE

These are the transformations I noticed offhand. Not all of my documents seem to suffer from this, so it may well be something in my style settings - that's why I hesitate to flag this as a bug. If I open the same document in Express the characters look okay again, so it's something Pro does.

Is there any information on this? Known problem? Something I could look at to fix this?

Thanks for any information!

[prauz]

Forgot the numbers:

Nisus Writer Express 2.7
Nisus Writer Pro 1.1
Mac OS X 10.4.11

[Groucho]

Hi, prauz.
Looks like you are having problems with text encoding. Are you using .rtf files, that is are you saving documents in NW default format, or are you dealing with plain text ones? How do you open the files in NWPro?

Cheers, Henry.

[prauz]

Hey Henry,

"Encoding problem" was my first thought as well. But I always thought RTF took care of that. I use NW default format for all my documents...

[Groucho]

I'm at my wit's end, then.
I'd suggest you send a file of yours over to Nisusland. They can see better than I.
Curious, though, that this happens between NWE and NWP. If you were moving from Word, or Mellel, or WhatHaveYou to NWP, maybe…

Greetings, Henry.

[martin]

In general your intuition is correct, RTF should take care of any encoding issues. If you can, please do send in your document (as saved by Express) via the menu Help > Send Feedback so we can take a look, thanks.

[prauz]

Feedback submitted. Thanks, Martin & Groucho!

[martin]

Thanks for the file, we've reproduced the bug and isolated it as an issue with Express 2.7. That version emits some incorrect text encoding information for the file's default font, which causes Pro to misinterpret the characters. You can work around the issue by changing the font in 2.7 before you save the file. We're looking into allowing a future update of Pro to transparently read and fix these kinds of documents. Until then, sorry for the extra work.