148692 - Printing:nsDocumentViewer's design is a royal pain for BeOS

Status: RESOLVED WONTFIX

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

Description

[timeless]

In BeOS, the printing api is very simple:
Page setup loads the page setup options for the current printer.
Print prints to the current printer.

And you don't waste time reinventing Print Preview. If the user wants Print 
Preview, then the user will install and activate the Print Preview printer. 
[MacOSX has a similar design]

This means that there's no point in enumerating printers - You Can't.
There's no point in checking to see if there's a printer available - If the 
user tries to print and there aren't any printers installed, BeOS asks the user 
what to do:
.--------------------------------------------------------.
|     Hang on there! You don't have any printers set up! |
|  i  You'll need to do that before trying to print.     |
|                                                        |
|     Would you like to set up a printer now?            |
|                                                        |
|                         [  No thanks  ] [[   Sure   ]] |
|________________________________________________________|

From the looks of it, if you have no printer configured, the print process will 
fail, and you'll have to select print again after you've configured a printer.

Comment 1

[Paul]

yes, I agree!
I was looking into this.  Bug#133013 was created because, someone, somewhere
removed the BeOS postscript work, probably when it got updated.  I had updated
it, but my update no longer works, plus, not knowing postscript very well, I
could only get the ps code to build, with broken graphics :( 

Anyway, my solution was going to be to always have a "default" printer.  We
would need to create our own page options dialog, to get the page header/footer
options, and zooming.  the page orientation and margins are handled by the beos
print driver.  there's the problem, though.  beos makes the driver handle all of
the information, where, mozilla likes to be in control.  the problem lies in
getting the margin information/page orientation back from the settings BMessage.
 From what I understand, it is up to the driver to set some of that information,
and there is no standard naming convention.  but, I think mozilla wants to know
that information, so it knows how to lay the page out.  but, i'm not completely
sure on all of this, as I only had a chance to spend a couple of days on it.

Comment 2

[timeless]

Attachment: draft, not compiled, bad whitespace, just ideas...

my plan (and it's on hold because i'm flipping between bezilla and webtools) is
to make the code take an alternate path on platforms that don't have multiple
printers. Basically this means we won't play with enumerators, we won't build
Postscript or XPrint printing, and we'll probably eventually remove mozilla's
print preview.

This is just a talking point. We should probably talk on irc.

Comment 3

[timeless]

Idea number 2 is to just steal the MacOS Classic printing code.

BeOS derives its UI from MacOS and they share a common approach to printers:
namely that the app may only talk to the current printer.

I'll work on that approach when I get home.

Comment 4

[Travis Chase]

In Response to Comment 3 things have changed slightly with the OpenBeOS Print
Server in that you can now select printers before you print

Comment 5

[Paul]

Travis, though that is true, it does not help us now.  Currently, our primary
target is BeOS R5.  OpenBeOS is not an option yet, nor is Zeta, as they have not
released anything.  So, in the future it may be helpful, but, for now, we, like
the Mac guys, have to deal with this "royal pain" design.

Comment 6

[Sergei Dolgov]

As OpenBeOS print Kit is 99% working, and highly R5 compatible (some of my
friends use it as replacement under plain R5), and more, it seems that Zeta one
will be similar in design (same person behind both, at least in beginning), i
think that this possibility must be considered seriously even now.

Comment 7

[Paul]

Agreed, it should be considered, and, if someone wants to do the work to get the "new"PrintKit working, that would be great, but, as there is no actual release, at this point,of any form of BeOS that uses the "new" kit, I cannot, and will not, add that code to therepository.  When, at some point in the, hopefully not too distant, future, a release is made that uses the "new" kit, I will reconsider adding the code.For now, the best thing, IMO, would be to get the current R5 print kit working, and then,build from that.  This should be possible to do now, and, once a new kit is ready, anddistributed, it should not be too difficult to migrate to it.

Comment 8

[Sergei Dolgov]

forgotten bug, time for revival?

Comment 9

[Doug Shelton]

I hope so, Sergei!

Comment 10

[Sergei Dolgov]

Wondering if recent roc's changes in layout/view have some (potentially) good effect on situation

Comment 11

[Doug Shelton]

(In reply to comment #10)
> Wondering if recent roc's changes in layout/view have some (potentially) good
> effect on situation
> 
I assume Paul is no longer involved with this.  I'm ready to test any ideas you might have along these lines - I think it's up to us now.

Comment 12

[Sergei Dolgov]

At the moment in layout we need one obvious change.
line
http://lxr.mozilla.org/seamonkey/source/layout/printing/nsPrintEngine.cpp#1543
should be
#if defined(XP_MAC) || defined(XP_MACOSX) || defined(XP_BEOS)

so nsPrintEngine::CheckForPrinters() which uses printer enumerator don't fail for us.

Comment 13

[Sergei Dolgov]

removing Paul from CC

Comment 14

[Doug Shelton]

(In reply to comment #12)

> #if defined(XP_MAC) || defined(XP_MACOSX) || defined(XP_BEOS)
> 
Good point.  I've made this change in my tree - it's a start!  It's good to know you're working on this, fyysik!

Comment 15

[Sergei Dolgov]

Per Comment 14:
Unfortunately it looks quite non-trivial, until we get real help from some Mozilla Printing guru ().
Just because BeOS printing itself is very simple.
Problem reminds me other obstacles, like it was with scrolling, where mozilla's view manager approaches BeOS app_server features and needs from platform things with lower level than we have.
Same here, moz print manager looks performing internally quite similar to app_server/print_server bundle task, and there is quite difficult to plug there inbetween with our printing, based on BView->app_server->print_server functionality.

Comment 16

[Sergei Dolgov]

Notices for myself
One way I see to workaround possible callback problem with use of DrawView(BView *nswidget,,) is 
1)to force printing reflow process to surface which uses BBitmap (we use such kind of drawingsurface for all page rendering, window-attached BViews are used only somewhere in UI)
2)Have separate BView just for printing for special Draw() inplementation whch only "blits" real view's parent bitmap (with DrawBitmap) to that special printing view, probably at EndPage() call.

Comment 17

[Sergei Dolgov]

probably we also need to get and store in widget reference to corresponding nsSurface BBitmap.
only way for using native printing seems to render printable page to (backbuffer) BBitmap, then create in nsPrintSession special BWindow and BView and with special Draw() containing DrawBitmap(backbuffer-bitmap).

To be able to go such way we need proper init in layout/printing/nsPrintEngine.cpp:Print(),
because when we calling
rv = factory->CreateDeviceContextSpec(mWindow, mPrt->mPrintSettings,
                                          *getter_AddRefs(devspec), PR_TRUE);
http://lxr.mozilla.org/seamonkey/source/layout/printing/nsPrintEngine.cpp#770

we need to get in from there not on-screen BView, which probably can be get from that mWindow, but backbuffer BView/BBitmap.

Or we need some changes in nsDrawingSurfaceBeOS.

All that needs further investigation

Comment 18

[Mats Palmgren (inactive)]

Sorry, but BeOS support has been removed from mozilla-central.