Description of problem: The urw-fonts package includes four Type 1 fonts with FamilyName Nimbus Sans L with Condensed in the FullName. But most current applications cannot deal with Condensed, so these fonts are simply inaccessible to them. In particular, browsers like Firefox and Konqueror do not recognize them and so web authors have no way to specify them on web pages. This is unfortunate because these fonts are installed on virtually every Linux system and there is no other condensed sans font that is widely installed. Version-Release number of selected component (if applicable): 2.4-3 How reproducible: always Steps to Reproduce: 1.Try to select Nimbus Sans L Condensed. 2. 3. Actual results: Can't be selected. Expected results: Can select them. Additional info: There seem to be three approaches to this problem. One is to insist that every application deal with condensed/expanded fonts in the same way that they deal with bold/italic/etc. This is a good long-term solution. A short-term solution is to hack the fonts in question so that their FamilyName is Nimbus Sans L Condensed; this has already been adopted by Mandriva and, apparently, Suse: https://bugzilla.novell.com/show_bug.cgi?id=367188 Another is use fontconfig to achieve the same, as in <match target="scan"> <test name="family" compare="eq"> <string>Nimbus Sans L</string> </test> <test name="width" compare="eq"> <int>75</int> </test> <edit name="family" mode="assign"> <string>Nimbus Sans L Condensed</string> </edit> </match> or variants thereof. I'll attach a simple html file which illustrates the problem. In any browser on Fedora, the two lines will be in the same fonts. When the font files are patched as suggestedb or the fontconfig snippet above installed, condensed fonts are used for the second line.
Created attachment 297217 [details] Test file to illustrate inaccessibility of condensed fonts in browsers.
Strongly NAK-ed by me, and should at least be discussed in the Fonts SIG mailing list before ending up in a Fedora package: 1. the problem is not in the font file but application-side 2. we don't do it for the distro default fonts, why should we do it for Nimbus? 3. those applications hit the very same problem for many other fonts. A single fontconfig alias is not going to solve it, alaiasing all the fonts that trigger the problem is unrealistic 4. grouping different faces under a single family name is an explicit objective of modern font formats and pushed as best practice by heavyweights like the Microsoft Typography group, so this patch is backwards and tries to stop the tide 5. GTK already proves supporting this kind of face without hacks can be done 6. OO.o is getting fixed right now 7. bugs are opened @QT & @KDE to get them fixed too 8. applying it now will only create confusion between users with aliased fonts and users of previous releases 9. and anyway this kind of change belongs upstream
Nicolas and I have argued on the fontconfig list about this: http://lists.freedesktop.org/archives/fontconfig/2008-March/date.html so I don't expect to convince him, but here are my responses. > 1. the problem is not in the font file but application-side But until all the applications are fixed, why not fix the font? > 2. we don't do it for the distro default fonts, why should we do it for Nimbus? The urw fonts are installed in the 'default' sub-directory of /usr/share/fonts. ghostscript depends on them. > 3. those applications hit the very same problem for many other fonts. A single fontconfig alias is not going to solve it, alaiasing all the fonts that trigger the problem is unrealistic Until the applications are fixed, no font should be distributed that can't be accessed by all applications. > 4. grouping different faces under a single family name is an explicit objective of modern font formats and pushed as best practice by heavyweights like the Microsoft Typography group, so this patch is backwards and tries to stop the tide I'm not trying to stop the tide. But pretending the tide has already come in is unrealistic. I see you as King Kanute exhorting the tide to come in when it is a mile away. > 5. GTK already proves supporting this kind of face without hacks can be done Good for them. What applications can take advantage of this? I've looked for the "gtk2 font selector" you've claimed has been fixed and can't find it. Of course it can be done and I support this kind of fix. LaTeX2e has had this kind of flexibility for years. > 6. OO.o is getting fixed right now Good. How does that help a web author? > 7. bugs are opened @QT & @KDE to get them fixed too Good. Perhaps konqueror will allow access to the condensed fonts. Why does that preclude making the fonts accessible to all browsers? > 8. applying it now will only create confusion between users with aliased fonts and users of previous releases Finally being able to access fonts previously inaccessible will create confusion? Should bugs not be fixed because that will only create confusion? > 9. and anyway this kind of change belongs upstream And where is "upstream" for the urw-fonts? I wasn't aware there was a fedora-fonts mail list. Bob T.
> But until all the applications are fixed, why not fix the font? Nicolas has explained a few times on the mailing list: if we "fix" the fonts there will be less of an incentive to fix the applications, and will take considerably longer to be fixed. Secondly, we cannot fix all the fonts. Buy several expensive font sets on from Linotype for example and notice that they're in OpenType nowadays with 60+ styles in one family not being an exception, and we can't possibly fix commercial fonts, so the person who has those fonts won't really be happy about the fact not being able to select them... > I'm not trying to stop the tide. But pretending the tide has already come > in is unrealistic. I see you as King Kanute exhorting the tide to come in > when it is a mile away. The tide has come in a long time now, Arial Narrow is part of the Arial family for example. The commercial fonts use it now. We at DejaVu Fonts have condensed styles now, and they're in the same family for a very long time now. (note that I probably should mention "preferred family" instead of "family" above, since there's a difference there, but fontconfig uses the former one anyway -- you could reverse fontconfig support for preferred family and you'll have those fonts the way you want them: condensed in its own family. Except with Nimbus I guess which isn't OpenType.) > Good for them. What applications can take advantage of this? I've looked > for the "gtk2 font selector" you've claimed has been fixed and can't find > it. Of course it can be done and I support this kind of fix. LaTeX2e has > had this kind of flexibility for years. If the gtk2 font selector handles it, it means that all Gnome applications handle it (except for those with own font selectors of course).
>> 2. we don't do it for the distro default fonts, why should we do it for Nimbus? >The urw fonts are installed in the 'default' sub-directory of /usr/share/fonts. >ghostscript depends on them. The way ghostscript chooses to name the directories in which it dumps its fonts has no relationship whatsoever with the distribution defaults. >> 9. and anyway this kind of change belongs upstream > And where is "upstream" for the urw-fonts? More reason not to increase the confusion > I wasn't aware there was a fedora-fonts mail list. http://fedoraproject.org/wiki/SIGs/Fonts
|>>The urw fonts are installed in the 'default' sub-directory of |>usr/share/fonts. |>>ghostscript depends on them. |>The way ghostscript chooses to name the directories in which it dumps its |>fonts |>has no relationship whatsoever with the distribution defaults. You're in charge of fonts for Fedora and you think that it's ghostscript that chose /usr/share/fonts/defaults to "dump its fonts"? ghostscript as distributed by ghostscript doesn't put its fonts in that directory. But because several packages depend on those fonts, the Fedora packagers chose to put them into the default tree under /usr/share/fonts. No doubt you mean something different by "distribution default" but I guess you prefer just being rude.
>|Nicolas has explained a few times on the mailing list: if we "fix" the fonts there will be less of an incentive to fix the applications, and will take considerably longer to be fixed. So I guess all of the following bug fixes in the past explain why the Firefox developers haven't been interested in font-stretch :+) * Wed Jan 09 2008 Than Ngo <than> 2.4-3 - update to 1.0.7pre44 - fix #426245, removes two broken lines (two invalid glyph names) * Fri Aug 10 2007 Than Ngo <than> - 2.4-1 - update to 1.0.7pre43, changed Roman glyphs in all fonts back to original metrics. bz#243180, bz#138896, bz#140584 - cleanup BR, bz#227297 * Thu Feb 24 2005 Than Ngo <than> 2.2-7 - change descender/ascender in "NimbusMonL" #140584 * Fri Aug 29 2003 Owen Taylor <otaylor> 2.1-5.0 - Add MediItal variant with fixed weight and some of the missing baseline hints (for u,t) * Wed Jul 9 2003 Owen Taylor <otaylor> 2.1-3 - Add some obvious missing hints that were resulting in very uneven baselines (#97271) * Fri Jun 20 2003 Than Ngo <than> 2.1-2 - fix Weight in Nimbus Roman No 9 L (bug #97683)
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.