[open-beos-printing] Re: Updates?

Hi Karsten,

>> The temporary
>> "Save As PDF" print jobs should still be kept somewhere.
> 
> This is not done with the current design either, print_server
> will remove the spool file as soon as he has processed it.

But not before, as one print job can't necessarily be processed immediatly,
mostly because the print target can be a shared one (like a single printer)
for which access should be serialized.
While it doesn't apply when target is a file - only if it's a distinct
file, this serialization needs some queue mechanism or the user app will
wait until job is totally printed, which is not desirable, I guess you will
agree.

That what printer node(s) does, queing. Plus hosting via attributs every
printer specific configuration.
BTW, as a print spooler can be suspended/restarted too, or the printer
device unavailable, the queue is then far less temporary and should/would
even survive a restart. Which is a nice feature, in particular when you
printer is back online...

> I see it more as an translator, to write out pdf files.
+
> I always hated the fact that one has to _Print_ a pdf file, while
> it always feels as _Save_ from a user point of view.
 
Now I see what you don't like in the current design.

It's not a translator because we can't translate magically any application
data into a multipages document without first have specified a multipages
document data format. Such translator is desirable indeed, and maybe for R2
we will have such document format so we could translate into PDF, HTML/XML,
Word, OpenDocument or whatever.
But until this time, we can't translate at all into PDF.
If such a translator will ever be designed and written, the same PDF core
should be (re)used by both PDF print driver and translator, obviously.

What we do now is taking advantage of the only situation when we have a
multipages document data format : applications to support printing have to
paginate their content, and the BPrintJob convert it into a known data
format : the prin job structure.

BTW, the verb "Print..." in app's menu is obsolete since user can also fax,
write pdf and whatever other print -> document gateway using this command.
Sometimes I hope someone will comes with a better command name.

> if an application developer wants to
> write out pdf files only, he will rely on the fact that the user
> has to have pdf printer installed. So then he could simply reuse
> the inbuilt engine to do his job. 

And here is the actual needs for a standard multipages document format. The
current PDF Writer core code could be converted into a PDF translator for
example. Such translator would expect in input a format very similar to the
today print job file structures. 

Then a newer PDF Writer will just wrap this PDF translator, handing its
input print job data, after some conversion, and capturing the translated
output to pass it directly to its print transport add-on.

The key is really in defining a multipages document format. I think a
polished one based on the current print job strutures (list of pages, each
with a list of BPictures, mostly) could be set easily, even for R1. 
Some food for reflexion...

> Just a last sentence, maybe I was not clear enough in what I'm
> going to do. I will lay some groundwork for application
> developers here, I'm not going to introduce new or different
> system behavior.  :)

Thanks to clarify. I hope you take no offense from my remarks either.

Bye,
  Philippe.

Other related posts: