225243 - [ps] Page appears reversed (mirrored) when printed

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Michael Thome]

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

Text is printed in mirror-image on some (all?) pages in 1.6a
display and print-preview are correct, but the generated postscript is wrong.

Reproducible: Always

Steps to Reproduce:
1. load up a page with text
2. print
3.

Actual Results:  
see attached postscript

Comment 1

[Michael Thome]

Attachment: reversed printed text

Comment 2

[Boris Zbarsky [:bzbarsky]]

Kenneth, that sounds like yours....

Note that I cannot reproduce this with Linux trunk build 2003-11-08-05. 
Michael, are you using the PostScript or XPrint print module?

Comment 3

[Kenneth Herron]

The print job is from the postscript module, but it has undergone some kind of
postprocessing (or it's from an altered version of mozilla) which introduced the
inverted text.

Classic print job behavior was to define altered versions of the standard fonts
(times-roman, etc.) at the top of the postscript document. In order to print
text, the print job would then select one of the altered fonts, scale it to the
right size, and draw the desired characters.

The printing model was recently changed so that the coordinate system is
inverted along the Y axis. To make characters come out right-side-up, the code
which produces the "altered" fonts was modified to invert each font.

The effect of the postprocessing step is to embed a pair of verdana fonts
(regular and bold) into the document, and to modify the character-drawing code
to select these verdana fonts instead of the altered standard fonts. The verdana
fonts aren't inverted so the glyphs are drawn upside down.

Michael, are you running standard mozilla 1.6a downloaded from mozilla.org, or
did you get it somewhere else? Was the sample attachment produced by doing a
"print to file" from mozilla, or some other way? Could you describe your
printing setup in more detail?

Comment 4

[Michael Thome]

Answers:
- No XPrint installed - plain old postscript.
- I'm using mozilla-1.6a-xft-pc-linux-installer.tar.gz as currently (as of this
writing) posted on the main downloads page.  I note that it is described as a
contributed build.  Here's the md5sum of the dist package:
6dd5b19db9dbb4e7a8286ccf97c1afec  mozilla-1.6a-xft-pc-linux-installer.tar.gz

about:buildconfig reports:
Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) 	-Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) 	-fno-rtti
-fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -pedantic
-fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--enable-xft --disable-tests --disable-debug --enable-optimize
--without-system-nspr --without-system-zlib --without-system-jpeg
--without-system-png --without-system-mng --enable-crypto 

Comment 5

[Kenneth Herron]

Ah. The different postscript is from the xft code, specifically
gfx/src/ps/nsType8.cpp. I hadn't looked at that code before.

The fix for this should be pretty simple, but I'm not set up to build xft here,
and a couple of quick attempts at editing the sample print job to fix the
problem weren't successful.

Comment 6

[Christopher Blizzard (:blizzard)]

There's also bug 190031 for the xft bits.  I've been reading my postscript book
to bone up so I can do that hacking on my own.  The basic idea is to just use
the lookup algorithm that's being used in the xft code to drive which fonts and
glyphs we use for printing the postscript document.

Comment 7

[Kenneth Herron]

I'll go ahead and take this. After thinking about it, I think it's best to not
invert the PS coordinate system. The inverted coordinate system, and the
necessity of inverting any fonts used in the document, is likely to impact other
users as well. I understand that printing oriental pages, for example, requires
postprocessing PS output to insert additional fonts.

Comment 8

[Kenneth Herron]

Attachment: Move the coordinate system origin to lower left corner

This changes the postscript coordinate system back to having the origin at the
lower left corner of the document, with Y increasing upwards. This should
remove the need to invert fonts. I'm not set up to build xft here so I can't
directly confirm that the original problem is resolved.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 135591 [details] [diff] [review]
Move the coordinate system origin to lower left corner

>Index: gfx/src/ps/nsPostScriptObj.cpp

>   // Procedure to reencode and invert a font

It no longer inverts, does it?

Other than that, looks good.  sr=bzbarsky

Comment 10

[Kenneth Herron]

Attachment: Corrected comments

Corrected the invert comment (and buffed up similar comments in the
image-drawing functions).

Comment 11

[tor]

Comment on attachment 135600 [details] [diff] [review]
Corrected comments

In the image functions, you've removed the comments referring to
inverting the Y axis, but still set a negative Y scale.  Perhaps
the comments should be changed to indicate why this is necessary?

Comment 12

[Kenneth Herron]

Attachment: Refactored image-drawing functions

Here I've tossed out the old image-drawing functions colorimage() and
grayimage(), replacing them with a single function called DrawImage() that can
do either one. The code for DrawImage() is all new, heavily commented, and
should be much easier to follow.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Hmm... Is that patch 1.6-material?

Comment 14

[Kenneth Herron]

Requesting blocking 1.6b. Printing is at least partially broken for xft builds.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Note that even _if_ this patch is safe enough to take for 1.6b, I still won't be
able to get to it within the next few days.... (possibly not till after
Thanksgiving)....

Comment 16

[Jo Hermans]

*** Bug 226719 has been marked as a duplicate of this bug. ***

Comment 17

[tor]

Comment on attachment 136142 [details] [diff] [review]
Refactored image-drawing functions

nsPostScriptObj::grayimage() was removed, but lives on in the header file

The two DrawImage()s seem extranious, given one is essentially a one
line wrapper for the other.

Comment 18

[Asa Dotzler [:asa]]

Recent regression (since 1.5) We should get this for 1.6.

Comment 19

[Kenneth Herron]

Attachment: Rewrote image-drawing function a bit more

This patch removes the extraneous DrawImage() function and grayimage()
prototype.

I've also rewritten draw_image() to fix bug 226656. Given that the
image-drawing code had been rewritten, I wasn't leaving it in a form that was
incorrect.

I've tested this with gtk, gtk2, and xlib using a testcase containing clipped
and scaled copies of the evil image from bug 226656. The testcase prints
correclty with gtk and gtk2; xlib couldn't display the page containing the evil
image, but printing other pages worked properly.

Again, I'm not set up to build xft so I can't directly confirm that this bug is
fixed by these changes.

Comment 20

[Kenneth Herron]

er, "I wasn't comfortable leaving it in a form that was incorrect."

Comment 21

[Mats Palmgren (inactive)]

Comment on attachment 136415 [details] [diff] [review]
Rewrote image-drawing function a bit more

Don't know if this is worth doing, but you can easily get rid of
the multiplications in the loop in nsPostScriptObj::draw_image()
if you want to (there is 1 per pixel + 1 per row), like so:

  const nscoord yEnd = iRect.height * bytesPerRow;
  const nscoord xEnd = iRect.width * 3;
  for (nscoord y = 0; y < yEnd; y += bytesPerRow) {
    for (nscoord x = 0; x < xEnd; x += 3) {
      outputCount += printPixel(f, theBits + y + x);

Comment 22

[Kenneth Herron]

Attachment: Draw images within a clipping region

During my earlier tests, when the image was supposed to be clipped layout would
set up a clipping region before drawing the image. But it turns out that's not
always the case. With this version of the patch, draw_image() will create a
clipping region surrounding the rectangle in which the image should appear.

Comment 23

[Kenneth Herron]

Comment on attachment 136590 [details] [diff] [review]
Draw images within a clipping region

This is a trivial change from the previous patch. Perhaps the r= could be
carried forward?

Comment 24

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136590 [details] [diff] [review]
Draw images within a clipping region

sr=bzbarsky, though those one-line static functions are a little odd...  I
think I'd prefer it if they were just inlined -- that boolean check on each
loop iteraction should be pretty cheap; possibly cheaper than the function
calls.

Also, it's really much easier to review a patch when its scope doesn't keep
changing all the time (and when the code doesn't change radically between patch
revisions)...  ;)

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136590 [details] [diff] [review]
Draw images within a clipping region

Could this please be approved for 1.6b?  This makes xft builds not print things
upside down...

Comment 26

[tor]

Checked in with static functions removed per irc discussion with bz.

Comment 27

[Jungshik Shin]

just for the record:
re comment #5: nsType8.cpp is not xft-specific. It's for the freetype printing 
module that is usually _disabled_ in mozilla.org's gtk2+xft build (I'm lobbying 
to turn it on in mozilla.org's gtk2+xft build. see bug 190031 comment #3 and bug 
 224764). Michael used a contributed build (comment #4) that happened to be a 
Xft-build with freetype and freetype printing NOT disabled(they're included in 
the build by default although they're off in the default run-time configuration 
file.).That is, this bug (now fixed) must have been reproducible on a non-Xft 
build with freetype printing enabled (both at compile time and at run-time)