Updates?

Hi,

I have started playing around a bit with some new API for the print kit.

BPrinter: wraps currently around the old style printer nodes, but i would 
like to extend it to handle ppd informations as well.

BPrinterRoster: can be used to retrieve printers from the system without 
print_server.

BPrintPanel, BJobSetupPanel (some missing panels): the idea here is to get 
rid of implementing these inside the driver (won't work with cups anyway). 
Instead they should get the information from BPrinter and it set there as 
well. This would also allow to get rid of app settings storage in print server.

I would also like to merge the preview and pdf printer as inbuild classes, 
so that, e.g preview printing works instantly without print to preview or 
tons of clicks in the printer panels. The same counts for pdf, it should be 
provided by default and always be available, but not as independent system 
printer.

There is still a loooot of stuff missing, but i would like to inform you so 
that nobody feels offended from my doing. If there are questions, ideas or 
concerns, please shout  :)

Regards,
Karsten

PS: Any informations on the cups port?

Re: Updates?

Hi,

> Hi,
> 
> I have started playing around a bit with some new API for the print kit.
> 
> BPrinter: wraps currently around the old style printer nodes, but i 
> would like to extend it to handle ppd informations as well.

Just to be a bit more specific, the ppd parser should no go in here. 
Only printer settings and some info about ppd file or driver location.

> BPrinterRoster: can be used to retrieve printers from the system without 
> print_server.
> 
> BPrintPanel, BJobSetupPanel (some missing panels): the idea here is to 
> get rid of implementing these inside the driver (won't work with cups 
> anyway).

Most likely they would use the ppd parser to get the printer options.

> Instead they should get the information from BPrinter and it 
> set there as well. This would also allow to get rid of app settings 
> storage in print server.

This is not entirely correct. I would offload the burden to the 
application developer which seems, hmmm...

> I would also like to merge the preview and pdf printer as inbuild 
> classes, so that, e.g preview printing works instantly without print to 

Re: Updates?

Hi Karsten!

2008/8/11 Julun <HOST.HAIKU@...>
>> I have started playing around a bit with some new API for the print kit.
>>
>> BPrinter: wraps currently around the old style printer nodes, but i would like to extend it to handle ppd
informations as well.
>
> Just to be a bit more specific, the ppd parser should no go in here. Only printer settings and some info about
ppd file or driver location.

So it just provides a convenience API for the standard printer spooler
settings that are stored in file attributes (printer driver, transport
add-on, ...)?
How do you intend to support printer driver specific settings? For
example the path to the PPD file? Do you provide direct access to
BDirectory of the
spool folder or do you wrap that too?

>> BPrinterRoster: can be used to retrieve printers from the system without print_server.

What's this for? ATM only printer_server or printers preflet could use
that, right?

>> BPrintPanel, BJobSetupPanel (some missing panels): the idea here is to get rid of implementing these
inside the driver (won't work with cups anyway).
>
> Most likely they would use the ppd parser to get the printer options.

Yepp. It should be extensible by printer drivers. libprint already

Re: Updates?

Karsten, Julun, Michael,

> I would also like to merge the preview and pdf printer as inbuild 
> classes, so that, e.g preview printing works instantly without print to 
> preview or tons of clicks in the printer panels. The same counts for 
> pdf, it should be provided by default and always be available, but not 
> as independent system printer.

Preview currently don't actually push any data to a print transport but
screen, indeed.
While a "Picture Viewer port" could be written to launch an external
BPictures viewer, which will be more modular than the current builtin/thigh
integrated, Preview is not really a "print" operation but a usefull feature
and as such should be always easily accessible, not needing him to setup a
"preview" pseudo printer.
While I'm not that found on too much integrated design, I can see why
Preview should not considered a printer driver at least.

But why inbuild PDF Writer driver ?! It actually push PDF formatted data
thru a transport, a transpart that can be not only "Print To File" but
whatever port to which a PDF-compliant device could be connected to.
Don't assume PDF Writer will be only used to generate PDF files, please. I
used to have access in my previous job (prepress IT) to a PDF-compliant
printer, connected thru HP JetDirect protocol.

PDF is no more special format than HP's PCL4/5/6 or Canon's cryptic BJ
printers protocol. They're all formats to describe pages content, that
different devices - hardware or software - knows to render. 
Preview use Haiku/BeOS native BPictures format, which can't be rendered
outside Haiku/BeOS. 

Re: Updates?

Hi Philippe!

2008/8/11 <philippe.houdoin-GANU6spQydw@public.gmane.org>

AFAIK, Haiku images have a "Save as PDF" printer connected to "Print To
File" pre-installed.
Maybe the single issue users will have is we don't offer a quick way to
swith the printer target *at* print time, contrary to other OSes. What
about adding a "printer: " popup menu on the print/job panel(s), like under
Zeta ?

Actually the Haiku print_server already provides that, IIRC even before Zeta was released I guess you haven't tried to print something under Haiku yet.

The problem however is that you still have to configure it separately and cannot use the settings from another printer driver.

 

That way, the pre-installed "Save To PDF" will be at one click too, but no
need to handle PDF differently than others drivers.

Cheers,

Michael 

Re: Updates?

Hi Michael,

thanks for your comments  :)  Hope you had some nice holidays too  :)

Michael Pfeiffer schrieb:
> Hi Karsten!
> 
> 2008/8/11 Julun <HOST.HAIKU@...>
>>> I have started playing around a bit with some new API for the print kit.
>>>
>>> BPrinter: wraps currently around the old style printer nodes, but i would like to extend it to handle ppd
informations as well.
>> Just to be a bit more specific, the ppd parser should no go in here. Only printer settings and some info
about ppd file or driver location.
> 
> So it just provides a convenience API for the standard printer spooler
> settings that are stored in file attributes (printer driver, transport
> add-on, ...)?
> How do you intend to support printer driver specific settings? For
> example the path to the PPD file? Do you provide direct access to
> BDirectory of the
> spool folder or do you wrap that too?

I was uncertain on how to handle specific settings, even more i don't 
know yet what needs to be added once we have cups running. Do you have 
an rough idea whats needed?

I also can't see the need for direct access to the spool folder, as the 
printer is the spoolfolder. I added some watching methods to the printer 
class to monitor spooljobs. Most likely i will also add some more 
private methods to be able to use it from print server. Like i have 
added the config, job, page settings and so on. Not sure though.

> 
>>> BPrinterRoster: can be used to retrieve printers from the system without print_server.
> 
> What's this for? ATM only printer_server or printers preflet could use
> that, right?

Right, this was the indent behind it. Later I noticed that it could be 
handy for any app as well. It also has an inbuilt watching mechanism, so 
anyone can register and be up to date if a printer get's added. I used 
it to build the printer list in JobSetupPanel, but i will extend it to 
keep the printer list up to date.

> 
>>> BPrintPanel, BJobSetupPanel (some missing panels): the idea here is to get rid of implementing these
inside the driver (won't work with cups anyway).
>> Most likely they would use the ppd parser to get the printer options.
> 
> Yepp. It should be extensible by printer drivers. libprint already
> provides this to a certain degree, but of course only for libprint
> based printer drivers.

Currently it is not so much focused on drivers (but can be important), 
it was more like to help app developers to extend the panels. Like in 
ShowImage, when going to print there is this tiny small window between 
page setup and job setup, while the app dev would then be able to pass 
it directly to the job panel(this is impossible to achieve now):

// the panels modifies the printer directly, not settings message around
BPageSetupPanel panel(&fPrinter);
status_t status = panel.Go();

BJobSetupPanel panel2(&fPrinter);

// create an advanced option preflet
BView* superduper = new SuperDuper();
panel2.AddOptionsPage(superduper);
status_t status2 = panel2.Go();

// then print based on printer settings
// like we have done with BPrintJob(still there, uses printer)

I still need to think how this special information can be stored, passed 
back.

Not sure how cups works, but i got the feeling that there is no need to 
talk with it like (BPrintJob <-> print_server). Hence the idea to put 
the panels on the application side and configure the printer object. 
BPrintjob might need to be extended to get all infos out of the printer 
and spool the job into the right cups folder. But i need to see how it 
works once available.

> 
>>> Instead they should get the information from BPrinter and it set there as well. This would also allow to
get rid of app settings storage in print server.
> 
> I still think coupling the settings with an application is a good
> idea, so each application uses the settings it has used the last time
> for printing. What's missing however are user definable presets (like
> for color or black/white only). These should be configurable in the
> printers preflet and in the print setup/job dialogs as well.
> 
>> This is not entirely correct. I would offload the burden to the application developer which seems, hmmm...
> 
> I think this was intended by Be too. AFAIK Gobe stored these settings
> within documents. I choose the app settings storage so neither the
> application nor the printer driver has to care about it.

I think the current way is great, but what if we decide at some point we 
run only cups and no print_server anymore?

> 
>>> I would also like to merge the preview and pdf printer as inbuild classes, so that, e.g preview printing
works instantly without print to preview or tons of clicks in the printer panels. The same counts for pdf,
it should be provided by default and always be available, but not as independent system printer.
> 
> Good idea, like it is available in Mac OS X? I think a good place
> would be the settigs dialog opened by the print server. Where you
> could add buttons for "preview" and "save to PDF file" and a
> possibility to set PDF specific settings. Are there any PDF printers
> available? If that's the case the PDF printer driver would still be
> necessary.

I will only remove the need to setup a preview driver and print to 
preview. The pdf driver will still exist, but i consider sharing it, to 
have an always available print to file pdf printer. If one needs to 
setup an pdf printer, he can (even print to file).

> 
> BTW these are acutally features for R2, but I don't want to stop you
> if you have time to complete it before R1 is released 

I know that and this is fine with me. I never thought about doing this 
for R1. :) We haven't reached R1 yet, but i can not hurt to talk about 
this anyway. We will be even better prepared when we need to decide on 
an new API for after R1.  :)

> 
>>> PS: Any informations on the cups port?
> 
> Bad news: Jovan wanted to deliver the ppd parser one week ago, but I
> have not received it yet...
> 
> Good news: CUPS almost builds out of the box under Haiku.

  Great  :)

  Only the
> backend drivers need some work (= transport add-ons in Haiku). However
> I did not test it. I could provide the Jamfiles if my MacBookPro did
> not die last week  Of course no backups when needed.

Isn't there Time Machine on OS X? Sad, of course!  :(

Best Regards,
Karsten

Re: Updates?

Hi Philippe,

thanks for your comments. :)

philippe.houdoin@... schrieb:
> Karsten, Julun, Michael,

Karsten == Julun

>> I would also like to merge the preview and pdf printer as inbuild 
>> classes, so that, e.g preview printing works instantly without print to 
>> preview or tons of clicks in the printer panels. The same counts for 
>> pdf, it should be provided by default and always be available, but not 
>> as independent system printer.
> 
<snip>
> 
> But why inbuild PDF Writer driver ?! It actually push PDF formatted data
> thru a transport, a transpart that can be not only "Print To File" but
> whatever port to which a PDF-compliant device could be connected to.
> Don't assume PDF Writer will be only used to generate PDF files, please. I
> used to have access in my previous job (prepress IT) to a PDF-compliant
> printer, connected thru HP JetDirect protocol.
> 
> PDF is no more special format than HP's PCL4/5/6 or Canon's cryptic BJ
> printers protocol. They're all formats to describe pages content, that
> different devices - hardware or software - knows to render. 
> Preview use Haiku/BeOS native BPictures format, which can't be rendered
> outside Haiku/BeOS. 
> But PDF is not in such case. Please, keep it as a printer add-on.

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.

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. And then we would 
need it anyway. And i can imagine that there will be an pdf driver for 
cups as well?

> AFAIK, Haiku images have a "Save as PDF" printer connected to "Print To
> File" pre-installed.
> Maybe the single issue users will have is we don't offer a quick way to
> swith the printer target *at* print time, contrary to other OSes. What
> about adding a "printer: " popup menu on the print/job panel(s), like under
> Zeta ?
> That way, the pre-installed "Save To PDF" will be at one click too, but no
> need to handle PDF differently than others drivers.

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

Best Regards,
Karsten

Re: Updates?

Hi Julun,

> Karsten == Julun

Ooops!


> 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. The temporary
"Save As PDF" print jobs should still be kept somewhere. 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?

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

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

Bye,
  Philippe.

Re: Updates?

Hi Philippe,

philippe.houdoin@... 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

Re: Updates?

Hi Karsten!

IMO this discussion started unfortunate. I first thought we were
talking about refactoring the current print kit. Obviously I missed
the point where you were talking about the new API meaning the API for
R2.

Before we can discuss the API we should define a feature set, based on
that we can then talk about the API.

The features I could extract from this thread are:
Karsten:
- Show preview from job setup dialog.
- Save PDF to file from job setup dialog.
- Integrate application and print settings into page/job setup dialog.
BTW only the last one requires an API change (= new printer driver
interface, should wait for R2).

Philippe:
- Persistent print settings per printer (IIRC printer_server does this already
  but on a printer _and_ application level, as I tried to explain in a
previous email).

Please correct me and add more that I missed or that you have planned.

BTW replacing print_server with CUPS is not a feature per se 

And before we think about implementing it we should finalize R1 first.
There are some things that should be improved, for example (somewhat
ordered by priority):
- The preview window still does not have a tool bar.
- The user interface of libprint should be improved.
- The PS printer driver should generated vectorized output.
  ATM it creates a number of raster images only, which is
  somewhat OK if the output goes to a printer or even CUPS.
  But for sure you do not want to convert that to a PDF file.
  I wish you good luck implementing the more advanced features
  of our PDF printer driver, like extracting links or the outline
  from a print job.
  And there is also the issue that the Interface Kit graphics model
  is (or was) not 100% compatible with PS graphics model,
  at the time of the implementation PDF graphics model was much
  better in this regard.
  So to work around that you end up rasterizing everything
  that can not be reproduced otherwise.
- The PS driver should support PPD.
- If we want CUPS to (ab)use as a "printer driver" a libprint
  based printer driver should be implemented that generates
  the CUPS native "raster" format. This should also support PPD.
- and for sure more I forgot.

I would really wish that, if you have the time and motivation, you
could complete to open tasks first, before you start with the next
step of defining and implementing an API for R2. This would be more in
the spirit of Haiku. I am sorry that I cannot keep my motivation long
enough to do that myself. But I really think that improving the R1
experience is more important now, than starting the planning phase for
R2 already.

Cheers,
Michael