Lars Gullik Bjĝnnes wrote:
> Gürer Özen <[EMAIL PROTECTED]> writes:
>
> | I think there are two solutions for this problem. Best one is modifying
> | buffer code to accept and understand utf8. This will make it possible
> | to generate and use utf8 encoded files (something we aim in our
> | distribution). Other one is doing charset convertion in navigation menu
> | and inset render code. This will be simpler to implement, and solves ui
> | problems, but doesn't allow utf8 encoding in actual lyx/latex files.
>>
> | I'm interested in hearing your opinions and maybe development plans. I
> | couldn't see it in your roadmap.
>
> We are planning for utf8 (ucs4 internally) support, not in 1.4.
> Possibly in 1.5 (quite likely).
Hi, Gürer
Lars' answer means that you should think about the alternative, "charset
conversion in navigation menu" route. It's possibly as simple as passing
the input codec to 'toqstr' in src/frontends/qt2/qt_helpers.C:
QString const toqstr(char const * str)
{
QTextCodec * codec = QTextCodec::codecForLocale();
return codec->toUnicode(str);
}
Perhaps you'll experiment a little, but I'd suggest changing to something
like:
QString const toqstr(char const * str,
QTextCodec * codec = QTextCodec::codecForLocale())
{
return codec ? codec->toUnicode(str) : QString(str));
}
and specifiying the codec explicitly when translating stuff from the LyX
buffer.
You'll probably have to change the interface to these functions too:
QString const toqstr(string const & str)
{
return toqstr(str.c_str());
}
QString const qt_(char const * str)
{
return toqstr(_(str));
}
QString const qt_(string const & str)
{
return toqstr(_(str));
}
HTH,
--
Angus
