[Qt-interest] Fontconfig rule matching bug in Qt-4

[Thomas Frenzel]

Hello everybody,

I have found a possible bug in Qt-4 regarding fontconfig rule matching.
I'm a German native speaker but try to learn some Chinese from time to
time. As my display has a lower resolution and i'm much better in
guessing Latin characters at small font sizes than Chinese ones, i
created a fontconfig rule matching some Chinese fonts and defining a
relatively large minimum pixel size for them. That way Latin characters
should be rendered normal while Chinese characters should be rendered
with the larger pixel size. My match element works with Gtk/Gnome and
Qt-3.3/KDE-3.5, but fails with Qt-4.5/KDE-4.2.

My fontconfig rule is as follows:

<match target="font">
    <test compare="eq" name="family" qual="any" >
        <string>ar pl kaitim big5</string>
        <string>ar pl kaitim gb</string>
        <string>ar pl zenkai uni</string>
        <string>ar pl mingti2l big5</string>
        <string>ar pl sungtil gb</string>
    </test>
    <test compare="less" name="pixelsize" qual="all" >
        <double>18</double>
    </test>
    <edit mode="assign_replace" name="pixelsize" >
        <double>18</double>
    </edit>
</match>

I also created a screenshot of the bug from Zenity (Gtk/Gnome) and
KDialog with Qt-3/KDE-3 (working) and Qt-4/KDE-4 (not working) side by
side. The screenshot can by downloaded here:
http://m20s08.vip-server.net/fontconfig.png

Please note that Qt-4.5 actually seems to invert my rule, rendering
Latin characters large and Chinese ones small/standard. The bug is not
in KDE as Qt-only apps show the same problem. The Qt-4 window in the
screenshot uses QGtkStyle, but the problem exists with any Qt-style
tested so far. I tried to look into the fontconfig-related code of
qt-gui, but i'm not a Qt-Developer nor very familiar with GUI
programming at all, so i would gratefully accept any hints.

I opened a bug about the same issue almost a year ago here:
http://www.qtsoftware.com/developer/task-tracker/index_html?id=212579&method=entry
But i fear this bug is considered very low priority ;)

regards,
Thomas