[open-beos-printing] 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 <HOST.HAIKU@xxxxxx>:

- 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

Other related posts: