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