Red Hat Bugzilla – Bug 166280
TrueType fonts that display correctly don't print with correct font -- Comic Sans MS changed to Helvetica-Bold
Last modified: 2008-08-02 19:40:34 EDT
Description of problem: installed the msttcorefonts rpm so as to better display and work with websites for development purposes. fonts are found in /usr/share/fonts/msttcorefonts/*.ttf the page has a screen/all and print stylesheet such that when printing, only the form itself is sent to the printer or *.ps file. However, on viewing the resulting .ps file, the "Comic Sans MS" font specified by the client as being absolutely required for the h2 headers fails to be included in the .ps file (the ultimate goal is the generation of a .pdf file for downloading a 'printer-friendly-version' of the page form. Version-Release number of selected component (if applicable): mozilla-1.7.10-1.5.1, firefox-1.0.6-1.1.fc4 How reproducible: every time Steps to Reproduce: 1. open mozilla or firefox and browse the url specified above 2. print the page to file : $HOME/mozilla.ps is the default Actual results: view in evince, or gsview, and note the absence of the comic-sans-ms font. Expected results: postscript file should include the font Additional info: konqueror has no trouble including the font in the .ps file, nor does oowriter or even gvim. Everything else is functioning as expected WRT this font. I've set this as severity high, as 'incorrect font' counts as "loss of data" insofar as I am concerned.
Created attachment 117874 [details] postscript file output by mozilla's 'print to file' feature.
I looked at the PS file generated by firefox and it displays the text using Helvetica-Bold. IMHO, the Mozilla PostScript module (rv:1.7.10/2005072014) should embed fonts other than the standard 35 Type 1 PostScript fonts. It is simple to embed TrueType fonts as Type42 PostScript fonts. In case the PostScript cannot handle Type42 (most Level 2 PS interpreters can including all Ghostscript versions since 2.6.1), put the 'definefont' in a 'stopped' context and only use the default font (like Helvetica-Bold) if the definefont fails. For example: mark { << % embed the Type 42 font dictionary here (or a subset) >> (Comic Sans MS) cvn exch definefont } stopped { cleartomark % Load the substitute the default font (like Helvetica-Bold) } if /F4 exch def % save whichever font we loaded to use in the document.
This is a duplicate of bug 130697, isn't it? Even after moving to the "GNOME" printing interface, "Truetype" fonts that are rendered correctly on the screen are still not printed accordingly, whereas other "GNOME" applications such as "abiword" handle "Truetype" fonts without any hassle. Instead, plain "PS" fonts are used by "epiphany". To work around this limitation, I have rebuilt the "X.org" RPMS with "Xprint" support and enabled the "Xprint" backend in "mozilla". Not really elegant to switch between the two browsers, but at least, it works.
This bug is related to Bug #112879. Red Hat developers refuse to enable "FreeType2". I have no idea why they are doing that. Apart from my original report bug #130697, I also filed a bug report at: http://bugs.gnome.org/show_bug.cgi?id=323892 The "epiphany" developers decline any responsability. According to them "FreeType2" printing works, once it is enabled in the underlying "mozilla" build. Quote: ".. this is a bug in your distribution's mozilla package. FC* builds mozilla with --disable-freetype2, which disables truetype printing".
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Ghostscript (and therfore gsview) has a documented font lookup process (see doc/Use.htm##Font_lookup). Unless you tell it to look in /usr/share/fonts/msttcorefonts/ with -sFONTPATH=/usr/share/fonts/msttcorefonts/ command line option or GS_FONTPATH=/usr/share/fonts/msttcorefonts/ environment variable, gs doesn't know to look there. Thus we use a 'best guess' substitution (Helvetica) when Comic Sans MS is not found.
Distribution against which this bug was reported is no longer supported; could you please reproduce this with the updated version of the currently supported distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. Thanks in advance.
Fedora Core 5 no longer has this problem.. I'm surprised it took this long for the bug report to get obsoleted by the fedora release version. I'll check with Fedora 7 to make sure that nothing has re-enabled the bug, later this afternoon, and get back to you with the final 'current' info.
(In reply to comment #8) > Fedora Core 5 no longer has this problem.. Right, the reason is that "mozilla" has been replaced by "seamonkey", and so, the "gecko" backend has been updated to version 1.8 instead of 1.7. Version 1.8 treats TrueType fonts correctly.
Closing per the last two comments.