Bug 436505 - condensed Nimbus fonts inaccessible to applications
condensed Nimbus fonts inaccessible to applications
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: urw-fonts (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-07 11:58 EST by Bob T.
Modified: 2009-07-14 12:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:38:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test file to illustrate inaccessibility of condensed fonts in browsers. (407 bytes, text/html)
2008-03-07 11:58 EST, Bob T.
no flags Details

  None (edit)
Description Bob T. 2008-03-07 11:58:38 EST
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.
Comment 1 Bob T. 2008-03-07 11:58:38 EST
Created attachment 297217 [details]
Test file to illustrate inaccessibility of condensed fonts in browsers.
Comment 2 Nicolas Mailhot 2008-03-07 12:41:57 EST
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
Comment 3 Bob T. 2008-03-07 14:08:21 EST
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.
Comment 4 Ben Laenen 2008-03-07 15:44:06 EST
> 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).
Comment 5 Nicolas Mailhot 2008-03-09 17:49:17 EDT
>> 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
Comment 6 Bob T. 2008-03-09 19:47:16 EDT
|>>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.

 
Comment 7 Bob T. 2008-03-09 20:27:17 EDT
>|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@redhat.com> 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@redhat.com> - 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@redhat.com> 2.2-7
- change descender/ascender in "NimbusMonL" #140584

* Fri Aug 29 2003 Owen Taylor <otaylor@redhat.com> 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@redhat.com> 2.1-3
- Add some obvious missing hints that were resulting in 
  very uneven baselines (#97271)

* Fri Jun 20 2003 Than Ngo <than@redhat.com> 2.1-2
- fix Weight in Nimbus Roman No 9 L (bug #97683)


Comment 8 Bug Zapper 2008-05-14 01:51:35 EDT
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
Comment 9 Bug Zapper 2009-06-09 19:42:42 EDT
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
Comment 10 Bug Zapper 2009-07-14 12:38:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.