Bug 138896 - Too much vertical space in Nimbus fonts
Summary: Too much vertical space in Nimbus fonts
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: urw-fonts
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Than Ngo
QA Contact:
URL:
Whiteboard:
: 171196 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-11 20:52 UTC by Anders Kaseorg
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Fixed In Version: FC6/F7 update
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-06-15 13:32:22 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Nimbus Roman No9 L, urw-fonts-2.1-7 (31.34 KB, image/png)
2004-12-06 19:29 UTC, Anders Kaseorg
no flags Details
Nimbus Roman No9 L, urw-fonts-2.2-6 (29.31 KB, image/png)
2004-12-06 19:31 UTC, Anders Kaseorg
no flags Details

Description Anders Kaseorg 2004-11-11 20:52:04 UTC
Between urw-fonts-2.1-7 (FC2) and urw-fonts-2.2-6 (FC3), the vertical
spacing in Nimbus Roman No9 L has increased considerably. (Downgrading
to urw-fonts-2.1-7 restores it to normal.)

Comment 1 Michael Opdenacker 2004-11-29 08:27:09 UTC
Hi Anders,

Thank you for highlighting this issue and for proposing a workaround!

By the way, here are details for those wishing to downgrade:

wget
ftp://rpmfind.net/linux/fedora/core/2/x86_64/os/Fedora/RPMS/urw-fonts-2.1-7.noarch.rpm
rpm -ivh --force urw-fonts-2.1-7.noarch.rpm

I'm facing the same issue too. All my OpenOffice Impress presentations
using the "Nimbus Roman No9 L" font got screwed up because of this:
there is more space between lines and text can flow out of its
original box. As it doesn't happen on pages with just a few lines,
this can go unnoticed and you end up generating PDF documents with
some ugly pages.

This can be addressed by changing line spacing to a smaller
proportional value, for example. Anyway, whatever you do, you end up
with something that doesn't have the same aspect on Fedora Core 2.

Is this a bug or a feature in FC3?

1/ If this is a permanent change in urw fonts impacting all GNU/Linux
distributions, fine! Though it takes time, I can update my documents
accordingly.
2/ If this is a bug in FC3, and other GNU/Linux distributions won't
implement the same change, this should be fixed. My OpenOffice Impress
documents should have the same aspect on any platform, including on
Windows. By the way, I checked that my document has the same aspect in
Windows XP and in FC2.

I thank Fedora Core developers in advance for their feedback.

Thanks for everything!

Cheers,

Michael.

Comment 2 Michael Opdenacker 2004-11-29 10:24:07 UTC
Actually, downgrading is not an acceptable solution, as it has a
severe side effect. For example, when you try to open a PDF file from
Mozilla or Mozilla Mail, the Mozilla window supposed to contain this
document flashes like crazy.

Resuming to the standard version of urw-fonts for FC3 fixes this issue.

What do you think?

Cheers,

Michael.

Comment 3 Than Ngo 2004-12-06 18:32:23 UTC
could you please attach the screenshots, which show the different
please. thanks

Comment 4 Anders Kaseorg 2004-12-06 19:29:59 UTC
Created attachment 107980 [details]
Nimbus Roman No9 L, urw-fonts-2.1-7

Comment 5 Anders Kaseorg 2004-12-06 19:31:43 UTC
Created attachment 107981 [details]
Nimbus Roman No9 L, urw-fonts-2.2-6

Here are screenshots from ftview. (The increased spacing is, of course, visible
in every application.)

Comment 6 Michael Opdenacker 2004-12-07 06:06:27 UTC
Here are mine:

http://free-electrons.com/issues/nimbus_roman_dec6_2004/oo_fc2.png
http://free-electrons.com/issues/nimbus_roman_dec6_2004/oo_fc3.png

I hope this helps.
Do you think this is a bug or a permanent change in this font?

Cheers,

Michael.

Comment 7 Michael Opdenacker 2005-01-02 07:28:05 UTC
Hello,

Eventually, do you know whether this is a bug or a feature?
Because of this, I have to stay in FC2, because I have more
than 500 pages that are impacted.

If this is a feature, it will be worth spending time
updating my documents accordingly. If this is a bug,
I will wait until this is fixed in FC3 or in FC4.

Thank you in advance for your feedback,

Cheers,

Michael.

Comment 8 Michael Opdenacker 2005-01-19 09:32:12 UTC
Hello,

I'm afraid it's eventually a permanent change, not a bug.

I compared the sources of urw-fonts-2.1-7 and urw-fonts-2.2-6, and I
think I found the difference:

urw-fonts-2.1-7/n021003l.pfb:
/FontBBox [-168 -281 1031 924 ]readonly def

urw-fonts-2.2-6/n021003l.pfb:
/FontBBox {-168 -281 1031 1098 }readonly def

You see, a value which is probably the height has increased
from 924 to 1098 (+19%).

I checked in the latest sources
(ftp://ftp.gnome.ru/fonts/urw/release/urw-fonts-1.0.7pre40.tar.bz2),
and the value is still the same.

Cheers,

Michael.

Comment 9 Anders Kaseorg 2005-01-19 20:36:26 UTC
That doesn't mean it isn't a bug. The new spacing is very clearly
wrong. Try comparing it to any other font (that isn't in
urw-fonts-2.2-6, as all of these except Dingbats and Standard Symbols
L have the same problem).

BTW, since we posted the requested screenshots weeks ago, this
shouldn't be NEEDINFO anymore unless more information really is needed.

Comment 10 Than Ngo 2005-02-24 11:32:36 UTC
It seems that the increased interline space happens after the VN
glyphs added in new version. I have tried to contact the urw-fonts
author but have not got any respond from him. I think it's a bug and
is still on his TODO list.

Comment 11 Kamil Iskra 2005-04-16 12:39:37 UTC
Let me stress the severity of this problem (this comment also applies to bug
#140584).

urw-fonts are used as a free replacement for "base 35" Adobe fonts.  ghostscript
uses them this way, and so does TeX.  To make this scheme work, the fonts MUST
be metrics-compatible with standard Adobe fonts such as Times, Courier etc. 
Otherwise, existing PostScript or PDF documents that don't have the fonts
embedded simply won't draw correctly in ghostscript, for example.

Hence, ANY such changes to the metrics are BUGS, and NEVER features.

If characters from some language require more space, it's too bad for that
language.  Of course, people are free to change the metrics and add the
characters, but they should save the fonts under new names, since they are NOT
compatible with Adobe fonts anymore.

Basically, whoever is responsible for this so-called new and improved urw-fonts
2.2, simply didn't realize the consequences of his/her work.  This release is
harmful and should be dealt with accordingly.


Comment 12 Michael Opdenacker 2005-04-19 16:30:29 UTC
Checked that this issue is still there with the latest update: urw-fonts-2.3-0.FC3.1

Comment 13 Matthew Miller 2006-07-10 23:16:59 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!


Comment 14 Anders Kaseorg 2006-07-10 23:37:49 UTC
This is still an issue in all urw-fonts >= 2.2 packages; it is not specific to
any particular version of Fedora.

Comment 15 Owen Taylor 2007-01-25 20:14:01 UTC
This probably is the #1 improvement we could make to make our display of
websites and documents look better. Looking at Nimbus Sans L, 

   EM size:         1000
   ascent:          1196
   descent:         -285

Basically, for a font to work correctly the EM size should equal the
ascent + descent. (Ignore the - sign on the descent for this purpose).
So, for Nimbus sans, we have almost 50% excess line spacing! I suspect
the problem here was the addition of Vietnamese glyphs in the upstream
version of the fonts.


Comment 16 Than Ngo 2007-06-15 13:32:22 UTC
1.0.7pre41 upstream now includes the fix. I will build urw-fonts-2.3-7.fc6 in 
FC6/F7 update soon. Thanks for your report

Comment 17 Than Ngo 2007-06-15 13:35:22 UTC
*** Bug 171196 has been marked as a duplicate of this bug. ***

Comment 18 Nigel Jewell 2007-06-15 17:55:29 UTC
As Bug 171196 has been marked as a duplicate of this bug, does it mean that this
will be also fixed in RHEL4?


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