Bug 166280 - TrueType fonts that display correctly don't print with correct font -- Comic Sans MS changed to Helvetica-Bold
Summary: TrueType fonts that display correctly don't print with correct font -- Comic ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mozilla
Version: 4
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Ben Levenson
URL: http://www.nancycarolwillis.com/Birds...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-18 17:27 UTC by Scott R. Godin
Modified: 2018-04-11 07:26 UTC (History)
4 users (show)

Fixed In Version: f7
Clone Of:
Environment:
Last Closed: 2007-08-03 09:54:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
postscript file output by mozilla's 'print to file' feature. (81.50 KB, application/postscript)
2005-08-18 17:27 UTC, Scott R. Godin
no flags Details

Description Scott R. Godin 2005-08-18 17:27:08 UTC
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.

Comment 1 Scott R. Godin 2005-08-18 17:27:09 UTC
Created attachment 117874 [details]
postscript file output by mozilla's 'print to file' feature.

Comment 2 Ray Johnston 2005-08-18 18:15:58 UTC
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.

Comment 3 Joachim Frieben 2005-10-19 17:11:39 UTC
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.

Comment 4 Joachim Frieben 2006-02-20 20:39:55 UTC
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".

Comment 5 Christian Iseli 2007-01-22 11:13:29 UTC
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.

Comment 6 Ray Johnston 2007-01-22 17:17:58 UTC
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.

Comment 7 Matěj Cepl 2007-07-18 17:24:36 UTC
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.

Comment 8 Scott R. Godin 2007-08-02 17:17:08 UTC
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. 

Comment 9 Joachim Frieben 2007-08-02 20:02:52 UTC
(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.

Comment 10 Matěj Cepl 2007-08-03 09:54:58 UTC
Closing per the last two comments.


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