[open-beos-printing] Re: Updates?

HI Philippe,

philippe.houdoin@xxxxxxx schrieb:

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.


True. BTW, did anyone ever notice that you cant process two
preview jobs at the same time...  ;)


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.


I agree, yes :)


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


Oh, and have one ever try to cancel a processing spool job.


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...


Yes i know this, and i think this is fine.

I probably need to change only one bit here. In case print_server
crashed during spooling, after he comes up again all existing
files are mark for reprocessing. This should only be the case for
files that are not in processing state, still processing marked
files should become failed. Otherwise one of these file might
crash it again. I had it several times while syncing libprint
preview.  :)


I see it more as an translator, to write out pdf files.


I didn't have a better word handy.


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.


I agree here too and i would even go so far and say pdf, odf,
etc. translator doesn't make any sense at all. As you said, we
would have to come up with format that the translator knows
to be able to write out, can convert into and everyone else
understands. This shows the limitation of translator add_ons,
they might be good for graphics, audio and such, but everything
more advanced they are kind of useless.


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.


And this is where i was going to step in, use this well known
format to write pdf out.


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.


I would love that too.


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... 

Can you elaborate more on this please.


Kind Regards,
Karsten

Other related posts: