Re: Updates?

Hi Philippe,

[email protected] 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