OMEdit does not seem to treat UTF-8 in its Text View

[Rüdiger Franke]

Localization of models requires doc strings with non-ASCII characters, like:

model Foo
  Real mu = 1e-6 "Does OpenModelica treat UTF-8, like µ or ö in Linköping?";
end Foo;

Encoded with UTF-8, OMEdit opens the model, but scrambles the non-ASCII characters in its Text View:

model Foo
  Real mu = 1e-6 "Does OpenModelica treat UTF-8, like µ or ö in Linköping?";
end Foo;

One can edit the model and save it. One must not introduce a new non-ASCII char though, because OMEdit will replace all of them with a question mark then?

It is possible to translate and simulate the model. The Variables Browser in the plot pane treats UTF-8 encoded doc strings correctly.

Is this a bug in the Text View of OMEdit?

[Adeel Asghar]

I can't reproduce this with r23791.

I save your example model to a file and opened it. The text view looks as expected. See the attached screenshot.

[Rüdiger Franke]

That's strange. I'm using the released 1.9.1 (r22929) under Windows 7. Just to be sure: can you please check the attached file?

[Adeel Asghar]

Works fine.

[Adeel Asghar]

What is your Windows locale? German? Because I saw this is main.cpp,

#ifndef WIN32
  QTextCodec::setCodecForLocale(QTextCodec::codecForName(Helper::utf8.toLatin1().data()));
#endif

[Rüdiger Franke]

I'm using Formats from US and Location Germany. Playing around with the locale (Swedish vs. US vs. German) didn't change anything in OMEdit. I verified the correct behavior in Ubuntu though!

[Rüdiger Franke]

Does the compiler directive above mean that the Windows version of OMEdit is missing something?

[Adeel Asghar]

Replying to rfranke:

Does the compiler directive above mean that the Windows version of OMEdit is missing something?

Yes. But I guess it has nothing to do with this issue as my Windows 7 is displaying everything fine.

[Rüdiger Franke]

Just installed a fresh nightly (r23815) and the problem under Windows 7 disappeared!

[Adeel Asghar]

That's strange. I looked into the svn logs and my guess is that r23122 might have fixed this issue. I don't see any other commit that is related to this issue.