Re: Updates?

Hi Julun,

> Karsten =3D=3D Julun

Ooops!
;-)

> I will keep it or i won't remove it. Hmmm  :)  The idea is to have it=20
> inbuild, always available but not as printer node as in it's current
> state.

May I ask again why?=20
Why make a simple and working design a bit more complex and integrated (a=
s
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. The tempora=
ry
"Save As PDF" print jobs should still be kept somewhere. Why having norma=
l
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?

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

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.

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 a=
s
PDF is already available at one click for users.

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

> I'm not talking about the near future, but i always consider print=20
> server to die at some point in time in favor of cups.=20

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 wa=
y,
even in a design without a print_server.

> I have done this already in the new JobSetupPanel. There will be an=20
> 'Properties' button, to access printer specific options as well (cups=20
> ppd info, pdf Author etc.)

Sounds nice and to the point.
Regarding job properties, what about automatically keep the last print jo=
b
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?

Bye,
  Philippe.