[bt-devel] font bug

[Joachim Ansorg]

Hi Martin!

I noticed a strange thing on my side. Try to display the Tisch module which 
has BstGreek set together with a normal module. On my side greek text is 
shown properly for the table, but in single-module-chapter view it's not 
displayed as greek.

COuld you please check this?

Joachim


> Hi,
>
> I tried to work around the font problem.
> CModuleInfo will now return a font with AnyCharSet, and the optionsdialog
> displays this font correctly, also greek.
>
> The displayers still do not show the correct font. IMO the problem is that
> there are several QApplication::font() calls in the QRichtext sources,
> which return a font with the wrong encoding. Using QTextView::setFont() is
> not enough, because the parser will change the encoding of passages with a
> <font> tag because of these QApplication::font() calls. Am I clear?
>
> IMO we have 2 options: (1) hacking the qrichtext sources directly to fit
> our needs or (2) inheriting from the proper qrichtext objects.
> The first one is the quick and less difficult one, but after doing that we
> can't update the qrichtext sources any more.
> The second one  would be better for future, since we have to do it anyway
> when implementing ThML support. But it might be very complicated, even
> impossible.
>
> Maybe there are better solutions?
> For future the best would be that sword would change from creating the
> modules based on FONTS to creating them based on ENCODINGS.
> This is something that should really happen, because it is just sensible.
> What do you think?
>
> FYI: our problem with the fonts is basically that the greek text is not
> encoded with the proper encoding iso88859-7 but rather with some
> fontspecific encoding based on a module font, which is definitely the less
> good approach. The problems occur because Qt uses unicode internally and
> maps all fonts into unicode. Qt does now refuse to use fontspecific
> encodings, except you set the Font charset to AnyCharSet, which is not
> possible application-wide due to locale problems and not possible locally
> due to the problems described above. We need a quick solution for now,
> before 1.0 comes.
>
> Martin