39825 - page setting is wrong in Xprt PostScript output

Status: RESOLVED FIXED

(Core Graveyard :: Printing: Xprint, defect, P3)

Description

[Masaki Katakai]

It seems that scaling isn't correct in Xprt output.
When I use PS printer for destination, the page is
rendered in very small size.I think the page setting
of Postscript isn't correct.I'll attach the output.

Comment 1

[Masaki Katakai]

Attachment: GZipped PostScript output of www.yahoo.com

Comment 2

[Hidetoshi Tajima]

reassign.

Comment 3

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 4

[Roland Mainz]

Does anyone else have any idea how to fix this ?

----

Hint for everyone who reads this:
Attachment http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8858 is
xxx.ps.gz (PostScript Gzip compressed).

----

Changing COMPONENT to "Printing: Xprint"...

Comment 5

[Masaki Katakai]

Assign to Roland

Comment 6

[Roland Mainz]

Accepting bug.

Question to ftang/erik:
Is there some magic var (factor) which scales images on a page ?

Comment 7

[Roland Mainz]

Just looking a 2nd time on this bug... this issue was fixed LONG LONG ago... :)

Marking FIXED, I'd attach a example output...

Comment 8

[Roland Mainz]

Attachment: http://www.yahoo.com/ printed with 2002-01-14-08-trunk's Xprint module using Solaris2.7+108376-33 Xprt

Comment 9

[Roland Mainz]

FIXED, really.

The output is slightly cut at the right side see bug 84223 ("Printing cut off at
the right end", cross-platform, not Xprint module specific :)

Comment 10

[Masaki Katakai]

I tried this with my PS printer.

This is still reproducible for me. The output size is the same.
It's small than the exact paper. The page is printed out in 1/4
area of the page.This problem is really serious.

When you see the images on sdtimage or gs, it seems OK. But
when we send to exact PS printer, the size is still not correct,
very small.

Comment 11

[Masaki Katakai]

Re-opened. Sun Thai office is seeing this
problem too. I'm not sure which component
needs to be fixed, in our Mozilla codes or
Xprt server side. So I'm asking to Jay of Sun.

Comment 12

[Roland Mainz]

Taking...

1. Note that I am fixing the paper selection in bug 120916 - that patch in the
bug allowes the Zilla to choose the correct paper size based on the print job
options dialog settings...
2. sujay reopened bug 84223 ("Printing cut off at the right end",
cross-platform, not Xprint module specific :) ... this xx@@@!!-thing is still an
issue on the crossplatform printing code...

Comment 13

[Arthit Suriyawongkul]

does it anything related to screen-resolution?
(just a guess, coz it seems like the Xprt acts like another display.
in my test, i use  :1 .. anyway, just da guess)

note:
tested on Solaris 8

Comment 14

[Masaki Katakai]

I found my fault. I'm using SPSPARC2 which is set
printer-resolutions-supported=300 but the exact printer is 600.

When I tried to change 300 to 600, my simple test case works fine!!

However, Mozilla doesn't work. I got the following error dialog when
I set to 600.

"There was a problem priting. Tried to set an invalid printer attribute."

Roland, can you look at this?

Comment 15

[Roland Mainz]

> I found my fault. I'm using SPSPARC2 which is set
> printer-resolutions-supported=300 but the exact printer is 600.
>
> When I tried to change 300 to 600, my simple test case works fine!!
>
> However, Mozilla doesn't work. I got the following error dialog when
> I set to 600.
>
> "There was a problem priting. Tried to set an invalid printer attribute."

That's both "bug" and "issue" in the X11R651 sources the Solaris Xprt is (AFAIK)
based on.

1. The "issue":
X11R651 Xprt PS DDX code limits the supported default resolutions to the
following list: {300} /* one entry */

I have fixed that in my todays patch for bug 119102 (which allowes {75, 100,
150, 300, 600, 720, 940, 1200} as default resolutions (like the HP Xprt does)
and 2400 as additional resolution (but not as default one)).
    
2. The bug:
Xprt has a bug in the model config checks which does not check properly if a
default-resolution in the model config is part of the list of supported
resolutions. If this case happenes the Xprt does not return an error - instead
it silenty removes the "*default-resolution" Xp attribute and does nothing,
confusing applications (you cannot get the page resolution the way like xdpyinfo
does it, those infos are always the maximum configured for the matching DDX
screen).
I added a check long long to the Mozilla Xprint module which explicitly checks
for this case and returns an error if this happens (this is more or less fatal
because I need the paper resolution for futher calculations of font and image
sizes/resolutions).

Comment 16

[Roland Mainz]

bug 120916 fixed the paper settings, e.g  you can now select the paper size in
the print job options dialog (which is still a static, hardcoded list in the XUL
dialog - the current Mozilla print dialog API does not allow to query the list
of supported paper sizes from the Xprint code yet... ;-(( ).
Mozilla's Xprint module will select the matching paper size or return an error
if the printer does not support this paper size (likie trying to print DINA3 on
a DINA4-only printer).

The remaining issue is the wrong default resolution, but that's a Xprt issue
fixed in patch for bug 119102 ...

Comment 17

[Masaki Katakai]

I have a question:

Is this really Xprt bugs? because when I have put the both
into the config file, I get the proper scaled image at printing.
Can this be workaround?

*default-printer-resolution: 600
SPSPARC2.printer-resolutions-supported: 600

Comment 18

[Roland Mainz]

katakai:
I am wrong.
Xprt is right, you are right.

A printer does not need to have any defaults. Trying to set a default which is
not supported (e.g. in the list of supported attributes) should be ignored
(returning an error would be better).
If there are no defaults the code should find a reasonable default for itself.

Fix in bug 127657...

Comment 19

[Roland Mainz]

Patch for bug 127657 has been checked in... this should be fixed now.

Marking bug as FIXED.

Comment 20

[Roland Mainz]

Arthit Suriyawongkul wrote:
> does it anything related to screen-resolution?
> (just a guess, coz it seems like the Xprt acts like another display.
> in my test, i use  :1 .. anyway, just da guess)

Xprt is just any other Xserver - it uses only an other kind of output device
(printer instead of framebuffer).
Note that a Xprt screen does not represent a printer (I wish it would do that,
but that would be problematic if a Xprt should handle a lot of (say 50 or 100)
printers. A Xprt screen represents a single DDX (currently supported are
PostScript, PCL3/5 color, PCL mono and raster output (1bit deep bitmap).

The Xprt screen resolution defines only the maximum resolution configured for
the matching DDX, the printers real DPI is obtained via an another API
(XprintUtil has a bunch of functions to get/set the document/page resolution,
see XpuGetResolutionList(), XpuFreeResolutionList(),  XpuGetResolution(),
XpuSetPageResolution(), XpuSetDocResolution() and XpuFindResolution())