Closed Bug 24847 Opened 25 years ago Closed 23 years ago

cannot print in landscape mode

Categories

(Core :: Printing: Output, defect, P3)

Product:
Core
Component:
Printing: Output
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: jdaly, Assigned: dcone)

References

Details

(Keywords: platform-parity)

Attachments

(2 files)

Suggested implementation
25.16 KB, patch
Details | Diff | Splinter Review
patch for Xprint module
1.79 KB, patch
Details | Diff | Splinter Review 
this may be part of the printing prefs (bug 4637) but i thought it should be on
the main print dialog. the main print dialog is there under linux, but no
'portrait/landscape' option, like on the linux 4.x versions of communicator. i
checked the windows version, and it was under 'page setup', so maybe that's
where it's planned to be? currently that menu item is greyed out.
Can you look at this and comment.
Assignee: dcone → syd
Status: NEW → ASSIGNED
Keywords: beta1
Putting on PDT- radar.  Won't hold beta for this.  Adding relnote keyword.
Keywords: relnote
Whiteboard: [PDT-]
Target Milestone: --- → M16
M16 has been out for a while now, these bugs target milestones need to be 
updated.
Is this bug actually still there? (Linux landscape printing support)

Gerv
Whiteboard: [PDT-] → [PDT-] relnote-user
yes, pretty much. There is no option to print in Landscape mode on linux from 
the dialog box that pops up.
Reassigning to kevin for triage
Assignee: syd → kmcclusk
Status: ASSIGNED → NEW
Reassigning to waqar
Assignee: kmcclusk → waqar
*** Bug 53839 has been marked as a duplicate of this bug. ***
*** Bug 53839 has been marked as a duplicate of this bug. ***
adding myself cc list
Adding to cc
Status: NEW → ASSIGNED
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay
Target Milestone: M16 → ---
Target Milestone: --- → Future
*** Bug 72860 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0, pp
Adding self to CC.

This really does need to get fixed; there are some Web sites (like my credit
card statements) that simply don't print in portrait mode; I have to fire up NS4
to print them.  That makes this a 4xp issue, and possibly a dogfood/catfood issue.



*** Bug 85643 has been marked as a duplicate of this bug. ***
Also I think we have same problem on Mac also. THe old 4.7 client
had a Page setup option from which you could choose teh landscape
setting....the current 6.1 client doesn't have this option
on the print dialog and there is no PAge setup option from the File menu.

I couldn't find "waqar" in the Netscape phonebook...can we
re-assign this to someone else?

Cc: dcone, kmcclusk, rods

This is also a problem on Mac....no option there to change to landscape mode.

changing platform to ALL.
OS: Linux → All
This is for Me
Assignee: waqar → dcone
Status: ASSIGNED → NEW
Adding patch, review keywords.

Requesting review. Suggesting target milestone 0.9.4 because we have a patch.

I'm not sure if the change to layout/base/src/nsPrintPreviewContext.cpp is
necessary or correct, please comment.

This implementation works for me. I disabled swapping of page size in
nsPostScriptObj, because my understanding is: The actual creator of the page
must set the sizes to be able to render the page correctly, therefore we can
expect these values to be ok.
Keywords: patch, review
Kai:
Wanna add a small API which queries the printer device context which layout
modes are supported and which not (see bug 84947) ? Some printers do not support
landscape mode - and some support more than portrait/landscape...
Roland: Currently no, but I've got an idea, will add a comment to the other bug.

Can we mark this one as a "duplicate" of bug 84947 ? I'd like to slaughter this
and print dialog issues all-in-one-step if possible ...
I'm unsure why we should do this? This bug already has a working implementation 
(although nobody else has yet confirmed it).

The other bug has not been worked on yet.

I vote for using the patch in this bug for as long as we don't have a working
alternative.

In general the patch looks good, I didn't go over it with a fine tooth comb.
kai:
My only problem is time. AFAIK it will take 1-2 weeks until your patch passed
r=/sr= cycle - in the meantime I have a more or less "ready" patch for bug
84947. Then your patch "lands", destroying my patch, then I repair it and "land"
it one week later - supersetting all the changes in your patch. Question is if
that's usefull... ;-/
And I cannot wait - bug 84947 must land in 0.9.5 because I doubt that it is
possible to get new features into later milestones - AFAIK any milestone beyond
0.9.5 is to "stabilize" the Zilla for mozilla _1.0_ ...

Finally... if you really demand on landing your patch first - please let me file
a revised patch with Xprint support...
First, my patch is not that big. And from what I understand from the other bug,
you are planning a complete replacement of the print dialog, right?

If you fear, that this patch will mix up with your patch, you can easily revert
my patch using "patch -r", just before you apply your new patch. I don't think
that my patch destroys your patch.

Second, XPrint isn't included with Red Hat 7.1, for example. My suspicion is, a
majority of existing Unix installations don't have XPrint available.

In addition, with your planned implementation, I wonder what will happen on
systems that don't have XPrint installed. We still need a working print dialog
on systems without XPrint.

In my opinion, the behaviour of Mozilla should be dynamic. If we extend the
print dialog, shouldn't it behave in a way, dynamically detecting whether XPrint
is available or not, and display either the old version of the dialog (which my
patch extends), and if it is available, then display your new dialog? This
means, my patch wouldn't clash with your patch at all.

Third, my patch isn't limited to changing the print dialog only. It implements
the logic for creating landscape Postscript files, which is currently missing
from Mozilla at all.

Are my arguments convincing, or am I wrong?

> First, my patch is not that big. And from what I understand from the other 
> bug, you are planning a complete replacement of the print dialog, right?

Not really. I only add some stuff that the options/choices in the widgets can be
populated based on information from the device instead of using fixed values...

> If you fear, that this patch will mix up with your patch, you can easily 
> revert my patch using "patch -r", just before you apply your new patch. I 
> don't think that my patch destroys your patch.

Mhh... OK... point for you ... :-)
But: See below - I used your patch as starting point for my patch...

> Second, XPrint isn't included with Red Hat 7.1, for example. My suspicion is, 
> a majority of existing Unix installations don't have XPrint available.

"It does not matter when it is not part of Linux distribution xyz !?" -->
invalid argument. 
There is a lot of stuff around which is important but not part of RedHat...

Xprint is part of Solaris and HP-UX - and the client side library is (AFAIK)
always part of Xfree86 (otherwise a lot of stuff incl Motif and JAVA plugin
would break). Only the server (Xprt) is not part of a standard installation
(SuSE has a binary in a extra package - but I won't recommend a Xfree86-based
Xprt... some stuff in Xfree86 V4.x is still broken - incl. Xprt... ;-( )...
X.org source produces a properly working version... (ask me if you want a
package; I don't have the exact URL handy ...).

> In addition, with your planned implementation, I wonder what will happen on
> systems that don't have XPrint installed.
> We still need a working print dialog
> on systems without XPrint.

Don't worry. Xprint module only gets activated on demand - either via prefs or
by setting the XPSERVERLIST env var (which contains a list of available Xprt
servers).
For the postscript module I am going to use the same API to query
options/choices - but the source for the dialog options/choices are the prefs,
e.g an adminstrator can use prefs to limit/extend the number of available
choices via prefs in that case...

> In my opinion, the behaviour of Mozilla should be dynamic. If we extend the
> print dialog, shouldn't it behave in a way, dynamically detecting whether 
> XPrint is available or not, and display either the old version of the dialog 
> (which my patch extends), and if it is available, then display your new
> dialog? This means, my patch wouldn't clash with your patch at all.

See my comment above. The information (e.g. available choices/options) for the
print dialog should be dynamically obtained from the device context - nothing
more.

> Third, my patch isn't limited to changing the print dialog only. It implements
> the logic for creating landscape Postscript files, which is currently missing
> from Mozilla at all.

That's my I used your patch as start point for my work... :-)

Anyway... I filed a add-on patch which implents the "orientation" support for
Xprint module.

----

dcone:
I retarged this bug to 0.9.5 to get it in as _quick_ as possible. 0.9.5 is the
milestone where I'd like to land the new print dialog - and I need this one "in"
first, please.

Requesting r=/sr= for both patches ...
Keywords: mozilla1.0 → mozilla0.9.5
Target Milestone: Future → mozilla0.9.5
Blocks: 84947
CC:'ing attinasi@netscape.com - we need r= ASAP, please ...
r=dcone
Thanks!

Requesting sr= ...
Keywords: mozilla0.9.5 → mozilla0.9.4
Target Milestone: mozilla0.9.5 → mozilla0.9.4
sr=attinasi
Roland, just some final comments:

>> In addition, with your planned implementation, I wonder what will happen on
>> systems that don't have XPrint installed.
>> We still need a working print dialog
>> on systems without XPrint.

>Don't worry. Xprint module only gets activated on demand - either via prefs or
>by setting the XPSERVERLIST env var (which contains a list of available Xprt
>servers).
>For the postscript module I am going to use the same API to query
>options/choices - but the source for the dialog options/choices are the prefs,
>e.g an adminstrator can use prefs to limit/extend the number of available
>choices via prefs in that case...

Ok, please just make sure to chose good defaults. On systems without XPrint,
where an administrator has not done any manual configuration, all the current
options should be available in the dialog IMHO.

Actually no, I take that back, you'd better wait until after the branch. Sorry!
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Patches checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: mozilla0.9.4
Resolution: --- → FIXED
Whiteboard: [PDT-] relnote-user → [PDT-] works on Mac and Windows, need to confirm on Linux
Okay I can print landscape mode on all  platforms(Mac, Linux, Windows)
using latest 11/1 trunk build.

REOPEN if I missed something, but looks like this bug is fixed.
Status: RESOLVED → VERIFIED
Whiteboard: [PDT-] works on Mac and Windows, need to confirm on Linux → [PDT-]
*** Bug 120449 has been marked as a duplicate of this bug. ***
URL: n/a
Keywords: patch, relnote, review
Whiteboard: [PDT-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: