The font stack triggers the PK font auto-installer for stuff like N'ko or Ancient Persian for which fontconfig has no orthography Therefore, those calls will never succeed and the user is bothered for no good reason fc-query/cache should also generate PK metadata for unicode blocks, so that when the font stack needs a glyph which is not part of an orthography, PK can search for fonts that cover the corresponding unicode block (stuff like symbols will probably never make it in an orth)
(In reply to comment #0) > The font stack triggers the PK font auto-installer for stuff like N'ko or > Ancient Persian for which fontconfig has no orthography > > Therefore, those calls will never succeed and the user is bothered for no good > reason This is surely a bug. And easy to fix, in at least two ways on the PK side: 1) Only show a dialog if there's any font supporting that language. This was supposed to be the default. Not sure why it wasn't implemented this way. 2) In the GTK+ module, use FcLangGetCharset() to check whether fc knows about the language. IMO both of them should be done. > fc-query/cache should also generate PK metadata for unicode blocks, so that > when the font stack needs a glyph which is not part of an orthography, PK can > search for fonts that cover the corresponding unicode block (stuff like symbols > will probably never make it in an orth) Not a huge fan of this. Lets add orth's where missing.
(In reply to comment #1) > (In reply to comment #0) > > The font stack triggers the PK font auto-installer for stuff like N'ko or > > Ancient Persian for which fontconfig has no orthography > > > > Therefore, those calls will never succeed and the user is bothered for no good > > reason > > This is surely a bug. And easy to fix, in at least two ways on the PK side: > > 1) Only show a dialog if there's any font supporting that language. This was > supposed to be the default. Not sure why it wasn't implemented this way. PK asks for permission to search for fonts, and since it has not searched yet, it does not know if there's any font supporting that language yet
(In reply to comment #1) > 1) Only show a dialog if there's any font supporting that language. This was > supposed to be the default. Not sure why it wasn't implemented this way. We're working with the yum guys to make this possible. > 2) In the GTK+ module, use FcLangGetCharset() to check whether fc knows about > the language. At what point should the module call FcLangGetCharset? Somewhere like http://cgit.freedesktop.org/packagekit/tree/contrib/gtk-module/pk-gtk-module.c#n229 ? Richard.
(In reply to comment #1) > (In reply to comment #0) > > fc-query/cache should also generate PK metadata for unicode blocks, so that > > when the font stack needs a glyph which is not part of an orthography, PK can > > search for fonts that cover the corresponding unicode block (stuff like symbols > > will probably never make it in an orth) > > Not a huge fan of this. Lets add orth's where missing. So if I submitted a fontconfig rfe to add an .orth for math symbols, engineering symbols, dingbats, ancient persian, etc would it be accepted? If yes what namespace should be used for those orths? I think ancient scripts have standardised ids ISO-side, but symbols?
Created attachment 366524 [details] Untested patch
(In reply to comment #4) > (In reply to comment #1) > > (In reply to comment #0) > > > > fc-query/cache should also generate PK metadata for unicode blocks, so that > > > when the font stack needs a glyph which is not part of an orthography, PK can > > > search for fonts that cover the corresponding unicode block (stuff like symbols > > > will probably never make it in an orth) > > > > Not a huge fan of this. Lets add orth's where missing. > > So if I submitted a fontconfig rfe to add an .orth for math symbols, > engineering symbols, dingbats, ancient persian, etc would it be accepted? > If yes what namespace should be used for those orths? I think ancient scripts > have standardised ids ISO-side, but symbols? Oh, that's what you meant. I believe there's a bug upstream about it? That's a separate issue and we need to figure it out, yeah.
Please can you try the build of PackageKit here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1776157 You will need to reboot your computer to ensure the packagekitd process has been restarted. Please provide feedback to whether this build fixes this bug. Thanks. Richard.
Tag has been requested
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping