168491 - Text prints with gray background when BACKGROUND-COLOR set to white

Status: VERIFIED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Dan Gilliam]

Text with this sort of font attribute:

<FONT FACE="Geneva" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF">

prints with a light gray background on all the text (you can't see it in an
on-screen preview, but it's obvious on an actual printout). Removing the STYLE
attribute fixes it.

Tested in 08/26 trunk build on Mac OS X 10.1.5.

Comment 1

[Mike Pinkerton (not reading bugmail)]

important for a certain embedding customer

Comment 2

[Mike Pinkerton (not reading bugmail)]

conrad says dcone would be better for this

Comment 3

[Conrad Carlen (not reading bugmail)]

> conrad says dcone would be better for this

That was assuming that this was a Mac-only problem. Do we know that it is? If it
happens on ALL, maybe it should be rod's.

Comment 4

[Conrad Carlen (not reading bugmail)]

Checking now to see if this is XP or not.

Comment 5

[Conrad Carlen (not reading bugmail)]

Huh - I don't have this problem on today's Mac trunk build. Are you sure there's
not something wrong with your ColorSync setup?

Comment 6

[Dan Gilliam]

I pulled down today's trunk build, still see it.

It's not specific to particular machines or ColorSync settings... as far as I
can tell, everyone around here can reproduce it. The printers here are generally
HPs... I'm using an HP LaserJet 8000N. I don't know if the problem is evident on
inkjet printers, haven't tried.

FYI, it's a pretty light gray, sometimes more, sometimes less -- I've attributed
this to printer randomness (low on toner, etc.) -- but maybe it's just
completely not happening on some devices.

Comment 7

[Conrad Carlen (not reading bugmail)]

Also WFM using today's branch build. My testing was done on an Epson Color 740i
and, whether using its color matching or ColorSync, and tweaking the monitor
settings this way and that, no gray background on the test URL.

Comment 8

[Conrad Carlen (not reading bugmail)]

When the background gets set behind the text, I've narrowed it down the the call
to ::RGBForeColor() where it happens. In other words, the eventual Mac color for
STYLE="BACKGROUND-COLOR: #FFFFFF" does end up as (65535, 65535, 65535)

Unless there is something in Gecko which is causing #FFFFFF not to get mapped to
RGBColor(65535, 65535, 65535), the printing process is interpreting
RGBColor(65535, 65535, 65535) as something other than white in your case.

Is there some color mapping we might do which would cause #FFFFFF not to end up
as the device color RGBColor(65535, 65535, 65535)? And something environment
dependent because it WFM.
 

Comment 9

[Dan Gilliam]

::RGBForeColor() seems strange. Did you mean RGBBackColor?

I think the difference may be that you are not using a Postscript printer. I
tried printing this stuff out to a Postscript file and looking at the diffs
between bug/no-bug cases. The one diff that looks relevant -- in the fail case
you see this add'l PS:

/Cs1 /ColorSpace findRes cs
1 1 1 sc
42 42 m
390 42 l
390 55 l
42 55 l
h
f
cgQ
cgq
1 0 0 -1 18 774 cm

which looks like it's setting color to white, then outlining and filling a rect
-- but I don't have a clue what the last half is doing... perhaps 'cm' is color
mapping. This whole section is missing if you don't set the BACKGROUND-COLOR.

my setup: no ColorSync profile set up for the printer. The Display profile in
ColorSync is set to Color LCD. I doubt any of our reports come from folks who've
mucked with ColorSync, but they _might_ all be using laptops, and so have a
different default profile than most.

I'll try some tests with desktop machines and different profiles. Maybe an Apple
PS generation bug?

Comment 10

[Conrad Carlen (not reading bugmail)]

> ::RGBForeColor() seems strange. Did you mean RGBBackColor?

No. The background is painted before the text is drawn, using the fore color.

> I think the difference may be that you are not using a Postscript printer.

Probably. You know what's really annoying in OSX? You can't add a printer unless
the printer is available. That means I can't save out a PS file since I don't
have a PS printer available. &%#@!. Can you attach the whole PS file you made to
the bug so I can see the definition of the procedures in that PS code snippet
you gave?

Comment 11

[Dan Gilliam]

Attachment: Sample Postscript output from printing the HTML failcase.

Here's the PostScript generated when I print
http://homepage.mac.com/dgilliam/gray3.html to file on Mac OS X 10.1.5.

Comment 12

[dcone (gone)]

Prints fine on windows.  Seems like the Mac printer driver is doing something.
Can you run this exact same setup with explorer.. and then compare the
PostScript and the output?

Comment 13

[Conrad Carlen (not reading bugmail)]

It's a bug in Apple's PS generation.

The following was added to the printing sample in /Developer/Examples/Printing/App

OSStatus DrawPage(PMPrintSession printSession, UInt32 pageNumber, Boolean
addPostScript)
{
    OSStatus status = noErr;
    Str255 textString = "\pDrawing Page Number ";
    Str255 pageNumberString;
    RGBColor saveColor;
    RGBColor behindColor = { 65535, 65535, 65535 };
    FontInfo fontInfo;
    Rect behindRect;
    
    GetForeColor(&saveColor);
    RGBForeColor(&behindColor);
    
    //	In this sample code we do some very simple text drawing.    
    MoveTo(72,72);
    
    TextFont(kFontIDHelvetica);
    TextSize(24);
    NumToString(pageNumber, pageNumberString);
    PLstrcat(textString, pageNumberString);
    
    GetFontInfo(&fontInfo);
    SetRect(&behindRect,
      72, 72 - fontInfo.ascent,
      72 + StringWidth(textString), 72 + fontInfo.descent);
    PaintRect(&behindRect);
    RGBForeColor(&saveColor);
    
    DrawString(textString);

so that it paints the background with RGB(65535, 65535, 65535) and, on Dan's
printer, this simple test shows the problem as well.

Resolving and filing bug to Apple.

Comment 14

[sujay]

verified.