Red Hat Bugzilla – Bug 497984
[qt] [pa_IN] Lohit Punjabi font showing empty square boxes in kde whereas same font works fine in gnome
Last modified: 2013-07-02 20:51:43 EDT
Description of problem:
installed gnome desktop in maithili (mai_IN), later install punjabi-support (pa_IN).
and tried to login gnome-desktop Punjabi, kde applications are not showing fonts, but square box
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. add punjabi support (yum groupinstall punjabi-support)
2. logout and login Punjabi locale
3. run kate or kwrite
actually showing square box instead of font glyph
proper font glyph should shown
Fresh install of rawhide 20090428 with kde desktop, then bug exist with kde
All Applications for KDE is not working!
OK, let's pull those over to qt then, hopefully someone there can take a look.
1) while using only qt application (qtconfig-qt4) for check font, it also have problem.
1) Interface (GUI) can be used in english, but input is more important, which is also square box only
qt-4.5.0-14.fc11 - Not working
qt-4.5.0-14.fc10 - Working
where only Build tag is different (fc11 or fc10).
Can it be depends upon something else?
2) qt-4.5.0-12.fc11 also has problem
3) various language tested (zh_CN, or_IN, ja_JP, ml_IN, ur, kn_IN, ta_IN), all those working fine.
Suspecting a miscompilation by GCC 4.4.
sorry but I didn't get meaning of miscompilation here.
we have new fontconfig in rawhide (F-11), it causes this issue
Are we sure it's not a graphics driver issue, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=495323 ?
I tested those on 3 machines with Intel, ATI and nvidia graphics and issue remains same. So it may not be graphcis driver. will update about fontconfig today
(In reply to comment #10)
> will update about fontconfig today
Thanks - if you could also test F11 Beta and Preview that would be helpful to know when this regression started.
ok, Beta Test.
Issue was present in F11-Beta with following version:
Is someone could check 11-Alpha too might be good - we don't seem to have a copy here, otherwise I can download F11Alpha Kde Live.
ok, Alpha-11 Results are here (working fine):
Hmmm, a lot of things different there: Qt was 4.4.3, it's 4.5.0 in Beta, fontconfig was 2.6.95, was 2.6.99 in Beta and it's also before the mass rebuild with GCC 4.4.
> sorry but I didn't get meaning of miscompilation here.
Miscompilation = the C/C++ code gets compiled into invalid assembly due to a GCC bug. If that's indeed what's happening, it'd explain why the same build works on F10.
Has anybody tried using the F10 qt-x11-4.5.0-14.fc10 build on F11 (in particular, with the F11 fontconfig)? That said, I think that won't easily work because OpenSSL has a different soname in F11 than F10.
It's neither graphics driver nor miscompilation by GCC 4.4. It's a regression in fontconfig in F11 that causes this problem. I fixed the pa orthography file and the problem is gone.
The new package was built in F11-scratch, you can download from the link.
yes. fontconfig got many orth files splitted and added new orth files in recent fontconfig releases.
so does Punjabi also got splitted from pa.orth to pa_IN.orth and pa_PK.orth.
Not sure what where goes wrong in pa orthography. But pa.orth from fontconfig-2.6.95 is same as http://cgit.freedesktop.org/~behdad/fontconfig/tree/fc-lang/pa_in.orth. And also from http://cgit.freedesktop.org/~behdad/fontconfig/commit/?id=4d7412a28b834830d0d1749852115846b3554932, it looks nothing got changed in pa.orth.
Will check scratch build rpms tomorrow.
This is ridiculous. You first say everything other than English renders to squares. Then it turns out it's just one language not working.
Someone please give me an update of what the real issue is, before I can take any action. The fact that GNOME works, but not KDE makes it hard to qualify it as a fontconfig bug, even if the issue was introduced by a fontconfig change.
Finally, please do a "fc-cache -f" as root and test again.
AFAICS, This bug exists for Punjabi language in KDE only.
Aalam and Parag, can you please test Than's build.
I have tested Than's build and looks Punjabi is working fine. But still question for me remains what change required in orthography file?
(In reply to comment #18)
> This is ridiculous. You first say everything other than English renders to
> squares. Then it turns out it's just one language not working.
have you read description? Punjabi (pa_IN) is ONLY mentioned language
> Someone please give me an update of what the real issue is, before I can take
> any action. The fact that GNOME works, but not KDE makes it hard to qualify it
> as a fontconfig bug, even if the issue was introduced by a fontconfig change.
Than's build working fine!
Thanks Than for help.
> Finally, please do a "fc-cache -f" as root and test again.
This did not work. forgot to mention before, sorry.
You can get the SRPM with Than's fix here:
See the fontconfig-2.6.99-pa-in.patch in that SRPM. Looking at it, he simply replaced the new pa-in.orth by the original 2004 version of pa.orth.
Created attachment 342592 [details]
Here's the fontconfig-2.6.99-pa-in.patch from Than's SRPM.
I see, thanks - however that still doesn't really answer Behdad's question on why his current fontconfig is breaking pa in KDE.
Rahul, could you review the orth changes to see why it would be breaking in qt?
Actually, I compared the file Than's patch added with the new one:
They're identical. (I got confused by the copyright notice, but it's still 2004 even in the new file.)
So Than's patch doesn't actually revert any changes to the .orth file itself, all it does is rename pa_in.orth to pa_orth. The file name appears to be the magic.
Also look at the upstream commit introducing the change:
There were no semantic changes between the old pa.orth and the new pa_in.orth, it's the rename which Qt chokes on.
See the languageForWritingSystem hack in this file:
for what I suspect to be the source of the breakage.
In short, AFAICT (and if I'm not mistaken), this tries to look up "pa" in fontconfig, and if the lookup fails, it concludes Gurmukhi script is not supported.
Should this be patched to use "pa_IN", "pa_in" or "pa-in" instead of "pa" in that lookup table?
Setting NEEDINFO on Behdad, but maybe one of the i18n folks is also qualified to answer this.
(In reply to comment #28)
> Also look at the upstream commit introducing the change:
> There were no semantic changes between the old pa.orth and the new pa_in.orth,
> it's the rename which Qt chokes on.
Thanks. Thought its scratch build and I will not able to see SRPM. Actually,
I already got that thing that the only way to have Than got working his build
is to revert back to pa.orth from pa_IN.orth.
As I already given my analysis on comment #17, pa.orth and pa_IN.orth are
identical. So question remains now where the problem exists??
(In reply to comment #29)
> See the languageForWritingSystem hack in this file:
> for what I suspect to be the source of the breakage.
> In short, AFAICT (and if I'm not mistaken), this tries to look up "pa" in
> fontconfig, and if the lookup fails, it concludes Gurmukhi script is not
I think it should succeed as
[parag@rawhide ~]$rpm -q --provides lohit-punjabi-fonts
lohit-fonts-punjabi = 2.3.8-1.fc11
lohit-punjabi-fonts = 2.3.8-1.fc11
> Should this be patched to use "pa_IN", "pa_in" or "pa-in" instead of "pa" in
> that lookup table?
> So question remains now where the problem exists??
Please see comment #29: search for languageForWritingSystem in the linked file (which is src/gui/text/qfontdatabase_x11.cpp from Qt 4.5.1, but that code has been in Qt for ages) and I think you'll realize what's going on... At least I'm fairly sure the problem is there (it looks for "pa", so if fontconfig only knows "pa_IN", it won't find it and conclude the Gurmukhi script is not available).
The RPM Provides are irrelevant, it's what fontconfig finds on lookups which is important. (And rebuilding the font package might actually change the Provides.)
(In reply to comment #33)
> > So question remains now where the problem exists??
> Please see comment #29: search for languageForWritingSystem in the linked file
> (which is src/gui/text/qfontdatabase_x11.cpp from Qt 4.5.1, but that code has
> been in Qt for ages) and I think you'll realize what's going on... At least I'm
> fairly sure the problem is there (it looks for "pa", so if fontconfig only
> knows "pa_IN", it won't find it and conclude the Gurmukhi script is not
Yes. I see that code. And you are right that code has been in Qt for ages. I even tested few new Indic languages based on Devanagari script successfully in QT where that code file has no mention for those new Indic languages like maithili language.
Ok. your point looks also right that it looks for "pa" and fontconfig currently knows only pa_IN.
> The RPM Provides are irrelevant, it's what fontconfig finds on lookups which is
> important. (And rebuilding the font package might actually change the
Ok. Lets wait for Than and Behdad then.
Yep, that's it. Very ugly. I suggest patching Qt and filing a bug upstream.
What's the correct way to look up the language? pa_IN (the locale's official name)? pa_in (the name of the .orth file)? Or pa-in (like zh-cn and zh-tw which appear to work)?
"pa-in" is fine. I'll think about this later and see if renaming it back in fontconfig makes sense. Here's the bug that introduced the change:
So pa_IN.orth should be renamed to pa-in.orth?
No. Either Qt patched to use "pa-in" instead of "pa", or pa-in.orth renamed back to pa.orth.
Maybe renaming it back in fontconfig is the best solution? This is a compatibility issue, and while I can easily patch our Qt, it won't help for third-party stuff statically linked against upstream Qt.
FYI, Qt 3 appears not affected, no hardcoded languages there:
But that's not surprising, as Qt 3 doesn't properly support Indic and other hard-to-render languages at all.
So this is only about Qt 4. (But most of the Qt stuff nowadays is Qt 4, of course.)
(In reply to comment #39)
> No. Either Qt patched to use "pa-in" instead of "pa", or pa-in.orth renamed
> back to pa.orth.
I see its pa_in.ort in fontconfig. Correct me if I am wrong.
(In reply to comment #42)
> (In reply to comment #39)
> > No. Either Qt patched to use "pa-in" instead of "pa", or pa-in.orth renamed
> > back to pa.orth.
> I see its pa_in.ort in fontconfig. Correct me if I am wrong.
sorry should be read as pa_in.orth.
Patched qt here (4.5.0-15.fc11):
Should we get this tagged into dist-f11 (if it's not too late yet)?
Ahh! I already have updated qt-4.5.1 from build http://koji.fedoraproject.org/koji/buildinfo?buildID=99514
Do I need to forcefully remove qt rpms to have your build installed in f11?
You can use rpm -Uvh --oldpackage to downgrade.
I could also build a new 4.5.1-based build, but 4.5.0-15.fc11 is the most likely candidate to make it into dist-f11.
I submitted a qt-4.5.1-3.fc11.1 build too: http://koji.fedoraproject.org/koji/taskinfo?taskID=1340046
Most likely we'll also want to sync the changes from Rawhide, but at this point I wanted to get a build with what's currently in F-11 CVS first.
Bug fixed with 4.5.0-15.fc11 package.
Tag request for qt-4.5.0-15.fc11 here:
So, should we treat this as fixed or is a fontconfig change (back to pa.orth) still being considered?
fontconfig (which is build by than) need to rollback. I used rawhide fontconfig
(fontconfig-2.6.99.behdada.20090318-1.fc11) then only this build package
(qt-4.5.0-15.fc11) was working.
(In reply to comment #46)
> You can use rpm -Uvh --oldpackage to downgrade.
> I could also build a new 4.5.1-based build, but 4.5.0-15.fc11 is the most
> likely candidate to make it into dist-f11.
Thanks. That worked. Tested successfully fix for this bug using qt-4.5.0-15.fc11 and fontconfig-2.6.99.behdada.20090318-1.fc11
(In reply to comment #49)
> Tag request for qt-4.5.0-15.fc11 here:
> So, should we treat this as fixed or is a fontconfig change (back to pa.orth)
> still being considered?
Fixed in qt. no change needed to fontconfig for now.
Thanks for tag request. Added comment there for tagging F11-final.
Re comment #50: I'm not sure I understand you. Do you mean that the patched Qt will NOT work with a fontconfig which uses pa.orth? (I need to know this because it means I have to conditionally apply the patch only on F11 and above.)
1)The fontconfig build I tested is fontconfig-2.6.99.behdad.20090318-1.fc11.x86_64
2) I checkout its source and looked into fontconfig-2.6.99.behdad.20090318/fc-lang/
3) I found following files starting pa_*
4) so with this new qt-4.5.0-15.fc11 build we are using pa_in.orth to see Punjabi font.
And yes the patched Qt will NOT work with a fontconfig which uses pa.orth.
Actually when you gave this new qt build, I was already using Than's fontconfig build. Then I found after updating qt to 4.5.0-15.fc11, I still see empty square boxes not only while giving input in Punjabi but also its translated strings in kate.
Ugh, this means there's no way that patch can be upstreamed. Qt needs to support older fontconfig as well. Maybe a safer solution would be to use the "sample character" trick Qt is using for some other languages?
At this stage I'm not sure tagging that patched Qt build into dist-f11 is a good idea at all, I wonder if I shouldn't withdraw my tag request.
(I think fontconfig should change to pa.orth instead, and ASAP, to prevent stuff from starting to expect the new name and breaking when it's changed back.)
What further confuses these matters is that most speakers of Punjabi are in Pakistan, but making pa_pk.orth the default pa.orth is also going to break Qt, as Qt expects a lookup of "pa" in fontconfig to find the Gurmukhi script, whereas pa_PK is written in the Arabic script.
Thats what I already got and dunno what to say. But afaik pa is actually pa_IN and not pa_PK. I need someone to confirm me.
the patch breaks the compatibility with old fontconfig. I don't think it's good idea to have it in qt. IMO it's a regression in fontconfig and should be fixed in fontconfig.
Kevin could you please withdraw your tag request?
Tag request withdrawn. Bouncing back to fontconfig.
"Change the default content in the metadata so that pa_IN is the default content
so 'pa' can be just link or copy of 'pa-IN' safely.
Update on this. No qt changes needed. I'll fix in fontconfig.
Built fontconfig-2.6.99.behdad.20090508-1.fc11. Can someone request tagging it please.
Tag request is here: https://fedorahosted.org/rel-eng/ticket/1767
fontconfig-2.6.99.behdad.20090508-1.fc11.x86_64 Package is available and FIXED the issue.