15.83 KB, patch
|Details | Diff | Splinter Review|
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.
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.
Created attachment 86067 [details] [diff] [review] 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.
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.
In Response to Comment 3 things have changed slightly with the OpenBeOS Print Server in that you can now select printers before you print
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.
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.
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.
forgotten bug, time for revival?
I hope so, Sergei!
Wondering if recent roc's changes in layout/view have some (potentially) good effect on situation
Summary: nsDocumentViewer's design is a royal pain for BeOS → Printing:nsDocumentViewer's design is a royal pain for BeOS
(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.
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.
removing Paul from CC
(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!
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.
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.
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
Sorry, but BeOS support has been removed from mozilla-central.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.