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.)
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.
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.
could you please attach the screenshots, which show the different please. thanks
Created attachment 107980 [details] Nimbus Roman No9 L, urw-fonts-2.1-7
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.)
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.
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.
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.
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.
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.
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.
Checked that this issue is still there with the latest update: urw-fonts-2.3-0.FC3.1
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!
This is still an issue in all urw-fonts >= 2.2 packages; it is not specific to any particular version of Fedora.
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.
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
*** Bug 171196 has been marked as a duplicate of this bug. ***
As Bug 171196 has been marked as a duplicate of this bug, does it mean that this will be also fixed in RHEL4?