203794 - [ps] can't print a web page if I have files named either sans or serif where I ran mozilla from

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[William D. Colburn]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

Mozilla can't print if a directory named either sans or serif exists.
An strace shows that mozilla has opened sans (or serif) and is now looping on a
read() error.


Reproducible: Always

Steps to Reproduce:
1. mkdir sans
2. mozilla http://www.cnn.com/
3. try to print

Actual Results:  
Mozilla hangs.

Expected Results:  
Printed the web page.


This didn't happen under RedHat 7, whatever Mozilla that was.  The Mozilla in
Redhat 8 did this, and I downloaded the latest Mozilla to test that it was still
there.

Comment 1

[Boris Zbarsky [:bzbarsky]]

What does your about:buildconfig say?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Never mind; this is a problem on non-xft builds too.  The bug is in
http://lxr.mozilla.org/seamonkey/source/gfx/src/ps/nsAFMObject.cpp#375
(nsAFMObject::AFM_ReadFile) or its caller....

Comment 3

[Kenneth Herron]

The immediate issue here is that the AFM parser in nsAFMObject.cpp doesn't deal
properly with unexpected errors or EOF while reading from an AFM file. This
isn't difficult to fix but there's a larger issue; the code for locating AFM
files seems to be broken.

When the PS module needs character metrics for a font, it starts by consulting
freetype if available, then checking the built-in AFM data for the standard
postscript fonts. Next it calls nsAFMObject::AFM_ReadFile() in hopes of loading
the data from an AFM (adobe font metrics) file; if this fails, it looks for a
substitute font.

AFM_ReadFile() just takes the font name and tries to use it as a filename. There
are three issues with this:

1) It doesn't add an extension. AFM files normally end in ".afm".
2) It only looks in the current working directory.
3) AFM files are specific to a particular font slant (roman, italic, oblique)
and weight (normal, bold). These attributes are sometimes reflected in the
filename, e.g. "Palatino-Bold.afm", but there's no real naming standard.

#3 is the real killer. In general it's impossible to guess the name of an AFM
file based on the desired attributes; you need a table mapping attributes to
filenames. Mozilla doesn't have anything even approaching this.

So it seems the proper solution for this bug is to disable the AFM reading code
until mozilla can do it properly.

Comment 4

[Tony Chung [:tchung]]

Hi there, is this something you can still reproduce against the trunk today?  Please see if you still reproduce this error on the 2007 nightlies of Gran Paradiso (Fx3).   Thanks.

Comment 5

[Kenneth Herron]

This was an issue with the old pre-cairo printing code. I would be amazed if it could be reproduced with a trunk cairo build.

I've been holding off closing all the old bugs about the pre-cairo system until that code has actually been removed from the tree.

Comment 6

[Kenneth Herron]

The old PS printing system has been removed. Resolving as fixed by the move to cairo.