[bedevtalk] BPrintJob questions

[Philippe Houdoin]

Hi Sergei,

> 1) DrawView(BView *viewtoprint
> BeBooks says that viewtoprint must be attached to window.
> Does it meant that we cannot print (directly) view attached to BBitmap?
> (As far as my own experience shows, drawing at BBitmap also heavily inolves
> app_server, so i'm unsure how to interpret that sentense from BeBook)

I dunno for sure as I never test it, but BBitmap accepting BViews are more or
less handled as an unvisible window by the app_server. You may want to test if
you can't call DrawView(your_bbitmap's main view).

Anyway, it's not that hard to create an invisible window, add a very simple
BView object that take a bbitmap as argument and on Draw() call DrawBitmap() on
it to print your offscreen bbitmap.
Give a look at this Tuxpaint's beos printing implementation:

http://cvs.sourceforge.net/viewcvs.py/tuxpaint/tuxpaint/src/BeOS_print.cpp?rev=1.2

Look at SurfacePrint() code, an invisible (->Show() is not called) window is
created and ran the time to print the image. Maybe you could get some
inspiration here...

> 2)BeBook says that DrawView() results in calling viewtoprint->Draw().
> As i understand the idea, app_server here hooks all drawing instructions, but
> renders using printer driver, instead "screen driver").

Not really. While printing, instead of "performing" the drawing instructions the
 BPrintJob::DrawView() records them into a BPicture object which are flatten
into the job file. The app_server don't even know that this BPicture is for
printing purpose, pretty much (if not all) is done directly on client side.

When BPrintJob::CommitJob() is called, the job file is commited and the
print_server, thanks to node monitoring, detect it and spawn the print queue
driver to process it...

> But there are some questions here
> a)when DrawView returns - when returns viewtoprint->Draw() ?
> b)What to do if viewtoprint->Draw() is really very asynchronous by
> implementation, e.g. it only sends somewhere message with update rect as
> content?

Glup. views's Draw() methods are not supposed to be asynchronous. :-\
If you have no other choice, you could expand your viewtoprint::Draw() method to
wait for drawing worker task to finish:

viewtoprint::Draw()
{
  [...]
  if (IsPrinting()) {
    WaitDrawingWorker();
  }

}

Otherwise, your viewtoprint::Draw() will return too early, and many if not all
drawing instructions that should have been recorded into the BBpicture will be
missing...

But it will work only if the drawing worker thread actually use viewtoprint too
to do its drawing directly or indirectly.

> Should we wait somewhere some kind of feedback from that drawing-worker and
> call SpoolJob only then?

Please don't. Instead make your viewtoprint::Draw() synchronous when printing.
While I understand that it's valid to fire & forget an HTML renderer drawing
thread, for printing you *must* have the whole page rendered to be able to
print it ;-)

- Philippe Houdoin, print drivers writer. Once.