Details
-
Bug
-
Resolution: Out of scope
-
P2: Important
-
None
-
4.8.0
-
None
-
Fedora Linux, X11, KDE
Description
When QFont is handed a comma-separated list of font family names, it successfully uses the first font from the list it can find.
An example: On a system with both "Linux Libertine" and "Tahoma" installed, this will succeed in using "Linux Libertine":
QFont("Linux Libertine,Tahoma");
It also succeeds with leading family names that are not installed in the system, i.e. this will still succeed in using "Linux Libertine":
QFont("Fakefamily,Linux Libertine,Tahoma");
Now, QFont also offers the ability to add substitutions. This will set up a substitution of "Fakefamily" with "Linux Libertine":
QFont::insertSubstitution("Fakefamily", "Linux Libertine");
Afterwards, this will succeed in using "Linux Libertine":
QFont("Fakefamily");
Now the bug. Despite the substitution, this will NOT succeed in using Linux Libertine:
QFont("Fakefamily,Tahoma");
This is a problem in the real word. CSS 3's @font-face rule allows specifying custom names for underlying document-supplied font files. KDE's KHTML browser engine adds such font files using QFontDatabase::addApplicationFont(), and then sets up substitutions for the document-specified custom names. However, if a CSS rule refers not only to that custom name but includes a list of several families, the comma-separated string KHTML builds and hands to QFont will not work, as explained above.