[open-beos-printing] Re: Updates?

Michael Pfeiffer schrieb:

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.


It was lete at night, i should have waited until the next day.
Would have avoided the situation.  :)


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


I can't see why we should change the driver API, most likely
implementation would change. No more UI code inside drivers, which means plain (spooldir, message) config_job, config_page calls. Thats what i see. 

When it comes to preview printing, how would one achieve this.
E.g printing directly into preview from an application point of
view. Since we always have to go thru print_server _and_ the
spoolfile will be generated first ofter completely 'OK' ing all
those panels, it would always be to late to "Preview". And this
is what i see as design flaw and hence the current need of the preview printer driver.
Libprint way of having Preview from JobSetup sucks even more, one has to do all job settings, press 'Preview' and then it jumps back to the previous panel where you have to press 'OK' once again to show the preview... Not the easiest and obvious way for an simple task :( 

But you are totally right, all I'm doing here is an real R2
target. I hope you won't mind if i still mess with it. I
personally think i can't be never to early to test and play
around with things like this.  :)


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.


- printer based PageSetup/ JobSetup but without print_server
interaction
- Print Preview, using a PreviewPanel directly from inside the
application
- Providing an Preview view to embed into applications
- nice cups integration into printing system
- wrapper class around cups provided api
- some convenient classes around printing


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


Good to know, i thought print kit is finished  ;)


- The preview window still does not have a tool bar.


This will be part of my changes, I'm on it.


- The user interface of libprint should be improved.


Hmm, i really won't touch it. Btw, what's the license of
libprint. Does anyone have contact to original developer? Did
anyone ever print with an driver based on libprint? I mean to an
real printer with all available options in use?


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


Hihii, do i hear a bit sarcasm?  :)


  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.


Can you please elaborate more on these points?


I would really wish that, if you have the time and motivation, you
could complete to open tasks first


Since i didn't know about all these, what if we have an general
print related task on Trac to add what comes to our mind?


, before you start with the next
step of defining and implementing an API for R2. 

Not defining, playing around. Defining an API can be an
evolving process, especially if there is time. And we obviously have plenty until 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.


Sure, i completely agree on that.

So i will go to fix at least preview printing and as pointed out
by Philippe, i will look in usb too.

Best Regards,
Karsten

Other related posts: