71669 - Xprint does not render XML+CSS pages correctly (books.xml)

Status: VERIFIED FIXED

(Core Graveyard :: Printing: Xprint, defect)

Description

[Roland Mainz]

moz_2001-03-09-08-Mtrunk Xprint module does not render most pages correctly.
Maybe the best example how things can get really worse is
http://www.mozilla.org/newlayout/xml/debugdemos/books/books.xml (toggle style to
see book pictures&descriptions, then try to print. I'll attach a GIF...) - but
other pages like http://www.yahoo.de/ do not look much better... ;-(

"Native PostScript module" prints these pages correctly...

Comment 1

[Roland Mainz]

Attachment: GIF from PostScript output printing books.xml

Comment 2

[Roland Mainz]

Sorry... I forgot to CC: Don Cone... ;-(

Comment 3

[Masaki Katakai]

Attachment: result on Solaris 8 U3

Comment 4

[Masaki Katakai]

I got the different result on Solaris 8 U3. However, it still doesn't
render properly. Roland, have you started hacking the Xprint codes?

Comment 5

[Roland Mainz]

> I got the different result on Solaris 8 U3. However, it still doesn't render
properly.

http://www.mozilla.org/newlayout/xml/debugdemos/books/books.xml is a XML+CSS
demo which has embedded HTML controls to allow the user to display the same
(XML) document using two totally different stylesheets.
Your snapshot is from (initial) "list" view, my image is from view after
switching to "full description with images" view via hitting the "Toggle CSS"
button.

> have you started hacking the Xprint codes?
Yes, I have some fixes in my tree, primary the collected recent source patches
and fixes for libXp support (printer selection by name/name:display, use of
XPSERVERLIST, waiting for End(Page|Job) events, job title and some other
(minor/major) flaws... but nothing on the rendering engine itself - I need some
time to understand why Mozilla does so many "interesting" things (which X11 does
not have) in it's rendering stuff. Without exact understaning why what happens
it's hopeless to hunt such bugs...

Unfortunately I do not have the big RAID anymore (the institute here is going to
be dismanteled and removed from history, getting aproval for new hardware in a
dead institute is difficult (and a "shiny"(hint :-) place I'd like to join
currently has a total "freeze on hiring"... ;-( )), e.g. no disk space to build
the Mozilla. All stuff is currently backed-up on the big tapeworm... but I need
diskspace to continue development... ;-(( I'll try to get rid of this issue...

Fixing "Summary" to be little bit more usefull... :-)

Comment 6

[Masaki Katakai]

OK, great. Please continue to work on the codes.
I'd like to try hacking rendering codes.

Comment 7

[Roland Mainz]

> Please continue to work on the codes

Sure... today it rains cats&dogs - tomorrow it will rain 9GB harddisks (sorry, I
couldn't resist =:-)

I try to find a solution...

Comment 8

[Roland Mainz]

> OK, great. Please continue to work on the codes.
> I'd like to try hacking rendering codes.

Basically it sounds nice - but currently it looks that I am the only one who's
working on the code (I found a temporary workaround my local limitations here...
:-) - currently I feel a little bit stupid being the old one pulling on the
rope. Xprint is a very nice piece of technology - from both user and
adminstration side. The server-side configuration - and the ability to configure
the client side based on these infos and offer only useable printer options -
solves many headaches in large networks - we tested this here with great
success... one more issue why I can't understand why noone wants to invest more
time into Mozilla's Xprint module than into the crappy PS module... ;-(


----

Back to work:
This bug may be caused by the same issue as bug 72216...
Adding refs. to Xprint meta bug 72087...

Comment 9

[Masaki Katakai]

Assign to Roland

Comment 10

[Roland Mainz]

I still have no clue how to fix this... ;-(

...but...

Accepting bug... but I need _help_...

Comment 11

[Roland Mainz]

Fix in bug 83242 - but output needs to be compared to native PS module output...

Comment 12

[Roland Mainz]

Fixed by patch in bug 83242...

Comment 13

[Masaki Katakai]

The page could be rendered mostly. Marked this as VERIFIED.

However, the texts are drawn outside of textare. Roland,
is this new problem? Should I file new bug?

Comment 14

[Masaki Katakai]

Attachment: outputs from 2002011614

Comment 15

[Roland Mainz]

I filed bug 117972 for the issue that books.xml cannot be printed anymore (some
months ago we printed that page perfectly...) ...

Comment 16

[Roland Mainz]

Comment on attachment 65393 [details]
outputs from 2002011614

katakai:
This output looks weired:
- It seems that you're not using printer buildin fonts (may be a good item for
the docs how to configure that - or better: We should change the default config
to use the common "buildin" fonts by default)
- The HTML form buttons are very large (which DPI do you use ?)

Comment 17

[Masaki Katakai]

What's DPI? screen or Xserver?

I'm using Linux, it's 75x75 and Xprt server is running on
Solaris. Here is output of xdpyinfo.

  dimensions:    4200x4200 pixels (357x357 millimeters)
  resolution:    299x299 dots per inch
  depths (2):    24, 8
  root window id:    0x25
  depth of root window:    8 planes

Actually, I get PostScript codes with builtin fonts (not
images) when I try another URL. However, it doesn't for
this URL.

Comment 18

[Roland Mainz]

Masaki Katakai write:
> What's DPI? screen or Xserver?

Xprt's DPI for this printer (xdpyinfo isn't a help here, it only shows the
maximum DPI configured for a DDX's screen. May be a good idea who hack xdpyinfo
and fix thaht...).

You can get the printer resolution from Mozilla's side via the NSPR logging
stuff:
Set
% export NSPR_LOG_MODULES=nsXPrintContext:5
before starting the Zilla to enable some debug output in Xprint module (this
code is enabled even for non-debug builds except the binary was build with
--disable-logging).
The following line should appear somewhere at the beginning after starting the
print process:
-- snip --
1[3d918]: print resolution 300
-- snip --
(the "1[3d918]:" is variable...).

> Actually, I get PostScript codes with builtin fonts (not
> images) when I try another URL. However, it doesn't for
> this URL.

Weird. Very weird... ;-((