Re: Updates?

Hi Michael,

first of all i have to say I'm happy that you are always responding 
and are still so enthusiastic on that topic. Thank you :)

Michael Pfeiffer schrieb:
> 2008/8/12, Julun <[email protected]>:
>>> - 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.
> 
> If a printer driver does not export config_job, etc any more then this
> is an API change.
> By doing that you will loose the ability to have printer (driver)
> specific settings.
> In R5 there are public settings like the first and last page number to
> print, and printer specific settings, like gamma correction in
> libprint or the author in PDF printer driver.
> How to you handle these settings with the new API?

As i have written above, i don't want to remove those exported calls.

So what i would like to do:

having a printer object in your application (equals settings message)
passing those printer object to one of the config panels
the printer object already has the knowledge about it's driver
this means it can easily ask the driver for advanced config options*
getting a plain view containing these back from the driver*
add it to the config panel (which contains defaults) + then options
save all made settings inside the printer object on success
while print pass those message(BPrintJob) along with the file as usual

* This was what i was missing, like gamma correction since i have 
never seen it elsewhere. This is also where the ppd parser would step in.

Printing does now not work differently as with BPrintJob. The printer 
object still uses it (BPrintJob). Instead of job.BeginJob() one would 
call printer.BeginJob() etc.

While this sound as we have it today, it gives us the freedom to 
remove all the code complexity in BPrintJob and print_server. 
BPrintJob can get rid of print_server communication, print_server can 
get rid of all the code handling (job, page settings, adding, removing 
printers etc...). print_server does only need to work with spool 
folders, transports and processing.

>>  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.
> 
> Without changing the API of BPrintJob preview could be supported already,
> only the print_server needs some changes:
> 
> Under Haiku when you ask the print_server to open the page or job
> settings dialog it opens the window with the selection of the target
> printer and (up to) two buttons that open the page and the job
> settings dialog provided by the printer driver when clicked.
> 
> When you click OK the window is closed and the application fills the
> print job and when completed* the print_server takes over and hands it
> over to the printer driver...
> *) With our current API at this point the application has completed
> the the printing process.
> 
> Now you just have to add another button "Preview" to the page/job
> settings dialog from print_server and when this button is clicked you
> add a flag to the job settings BMessage:
>   bool preview = true
> that tells the print_server that the print job should not be delivered
> to the target printer but to a slightly modified Preview printer
> driver.
> This Preview printer driver has two buttons "Cancel" and "Print".
> If you click "Print" the Preview window is closed and the print_server
> hands the print job over to the target printer driver.
> If you click "Cancel" the print_server cancels the print job.
> 
> Pros:
> - system wide print preview support without API change, nor application
>   support nor printer driver support needed
> Cons:
> - After canceling the Preview window the job settings dialog is not
> reopened automatically
> - Preview can only respect public page/job settings so it can show
> only the "raw" pages. It could not support things like n-pages per
> sheet or gamma correction...
> 
> To support printer specific settings preview functionality must be
> part of a printer driver.

And here comes the advantage with my model.

having an already configured printer object in your application
pass it to print preview panel, with the application as listener
when the preview panel is shown, it calls back the application with a 
message, lets say B_PRINT_PREVIEW
the application now executes the same printing code as usual on the 
printer object
the printer object knows its setup in preview mode
since it's using BPrintJob, it can be set to "spool" to tmp or any 
given location
print panel reads the file and displays it -> instant preview with all 
options :)
even printing directly from preview would be easy to support

all pros, all cons as pro, no driver nor driver api change

  >>  - printer based PageSetup/ JobSetup but without print_server
>>  interaction
> 
> This is not a new feature. Page/job setup is already there.

I know it's there, but honestly it leads to lot of code, strange 
locking, complexity in print_server and BPrintJob that could be avoided.

>>  - Print Preview, using a PreviewPanel directly from inside the
>>  application
> 
> OK.

see above

>>  - Providing an Preview view to embed into applications
> 
> So there would then be the application choice to either open a window
> or show it inline? Not sure if I like the inconsistency between
> applications, but I am not a user interface expert to decide that.

It's not a must, it can be private too. I'm just thinking and open for 
any ideas.

>>  - nice cups integration into printing system
> Not a feature.
> Features provided by CUPS for example would be:
> - support more print drivers with printer model specific settings
> - support printer sharing (including interoperability with other OSs)
> - support cancelation of current print job
> - support reading printer status (incl. ink levels)
> 
>>  - wrapper class around cups provided api
> Not a feature.

But we don't have it, right?

>>  - some convenient classes around printing
> - to improve reusability?
> - to easy programming?

To easy programming, yes.

>>> - 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?
> 
> I don't know it was added before my time.
> 
>> Did
>>  anyone ever print with an driver based on libprint? I mean to an
>>  real printer with all available options in use?
> 
> PCL5, 6 and PS have been tested by others and me, at least from my
> side it was not tested heavily.

I'm just asking because e.g multipage code was so heavily broken in 
Preview.

> BTW I have the impression that you're underrating libprint, it is
> already very easy to implement raster based printer drivers with it
> and it supports features that I think are not even available in CUPS.
> IMO it could be made THE Haiku framework for printer drivers. It's not
> a big deal to add a new printer driver based on it for a new printer
> language if documentation is available. What's missing ATM is support
> for print _model_ specific settings. This could be fixed by supporting
> PPD.

Ups, if you got that feeling i have to apologize. I don't won't to 
underrate it.

>>> - 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?  :)
> 
> You're very quick at proposing to replace things.
> Let's assume you want to convert PS to PDF and want to extract links
> and the outline from the text in the PS file. For the outline you
> define that text in Arial 18 denotes a heading at level 1, Arial 15 a
> heading at level 2 and so on. Now you scan the PS page per page and
> when ever you reach a line of text with one of the specified font and
> size you put it into the outline. Similarly when a text matches a
> link, that is for example defines as a regular expression, you mark
> the area surrounding the text as a link.
> In order to do that you have to parse PS and interpret it.
> With the Be API extracting the information from the print job was more
> or less a piece of cake, of course there is still room for
> improvements.

I don't get what this refers to, especially the replacing part?

<snip>

 > [Incompatible graphics model]
 > [CUPS as printer driver]
 > [CUPS raster format]

<snip>

I will come back on that part separately.

>>>
>>  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?
> 
> Good idea. I would put open tasks into Trac and thoughts about R2 into
> the wiki. I do not volunteer to do that ;-)
> 

We have a simple rule at work, if someone proposes something he thinks 
it is important or missing, he has to implement it himself. So yes :)


All in all we could have the same with BPrintJob, but since it would 
know more details, like driver location, transport etc. i would prefer 
to call it BPrinter then.

Best Regards,
Karsten