[open-beos-printing] Re: Updates?

Hi Philippe,

philippe.houdoin@xxxxxxx schrieb:
I will keep it or i won't remove it. Hmmm :) The idea is to have it inbuild, always available but not as printer node as in it's current 
state.
May I ask again why? Why make a simple and working design a bit more complex and integrated (as 
in "less modular")?

You will still need a spooling support, because nothing will (and should)
forbid users to "save as pdf" two documents at the same time.


Nothing and nobody will prevent the user from doing this.


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.


Why having normal
print jobs stored under .../Printers/<Printer Name>/. until the
corresponding driver process them, but "Save As PDF" print jobs can't
follow the same design?


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


What's wrong with having a "Save As PDF" printer node?


Nothing?


It's clean, and if ever a user wants to NOT have this feature always
available, he just can remove it (via Printers preflet or by removing the
folder himself). It's self documented, reuse the file system in a very
BeOS-ish way to store per printer configuration and consistent with all
printing spoolers.


And there is nothing I am going to change.


I really fail to see why printing in PDF format should be handle
differently because users may wants to Save As PDF more often. I stand
corrected by Michael about the printer target popup, which means saving as
PDF is already available at one click for users.


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.


In fact, I see why it should not: it breaks KISS rule without any extra
benefit for the end-user


Hmmm, there is no KISS rule for me on BeOS. The all over the
place praised KISS rule comes from the fact (as i see it),
that there was never enough time to be feature complete, be it
doe to time pressure and or lack of man power. So one had to live
with what got delivered... And here I'm talking as user.

Anyway, that's not the point here. I don't feel the end user will
lose anything. But what 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. BeOS development was always
about providing the ability to do something without big effort
and that's what i associate with BeOS KISS rule. And here I'm
talking as developer.
I'm not talking about the near future, but i always consider print server to die at some point in time in favor of cups. 

Here you mean moving the whole printing process in interface kit, and so
app caller context?
I dunno if CUPS is spooling-free, but at least access to shared printing
devices should be serialize at job level, which is usually handled via
spooling. Our printer nodes provides it for free in a clean and simple way,
even in a design without a print_server.


And this will be the same for cups, i won't change that either.
I have done this already in the new JobSetupPanel. There will be an 'Properties' button, to access printer specific options as well (cups ppd info, pdf Author etc.) 

Sounds nice and to the point.
Regarding job properties, what about automatically keep the last print job
ones (the whole BMessage) per printer in a extra attribut ? When no
specific one is passed to JobSetupPanel, the last one could be reloaded,
and the user will get his last configuration (PDF compatibility, embedded
fonts, for example) already reloaded for free?


This is a great point, i will keep that in mind. Thanks  :)


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

Kind Regards,
Karsten

Other related posts: