Updates?

[julun]

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?

[Julun]

Hi,

Post by julun
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.

Post by julun
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.

Post by julun
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...

Post by 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.
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?

[Michael Pfeiffer]

Hi Karsten!

Post by julun
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?

Post by julun
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?

Post by julun
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.

Post by julun
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.

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

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.

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

Post by julun
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. 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.

Cheers,
Michael

[Julun]

Hi Michael,

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

Post by Michael Pfeiffer
Hi Karsten!

Post by julun
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.

Post by Michael Pfeiffer

Post by julun
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.

Post by Michael Pfeiffer

Post by julun
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.

Post by Michael Pfeiffer

Post by julun
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?

Post by Michael Pfeiffer

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

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

Post by Michael Pfeiffer
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. :)

Post by Michael Pfeiffer

Post by julun
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

Post by Michael Pfeiffer
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

[p***@public.gmane.org]

Karsten, Julun, Michael,

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

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.
But PDF is not in such case. Please, keep it as a printer add-on.

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.

My .02 cents.

Bye,
Philippe.

[Michael Pfeiffer]

Hi Philippe!

Post by p***@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.

Post by p***@public.gmane.org
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

[Julun]

Hi Philippe,

thanks for your comments. :)

Post by p***@public.gmane.org
Karsten, Julun, Michael,

Karsten == Julun

Post by p***@public.gmane.org

Post by 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>

Post by p***@public.gmane.org
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?

Post by p***@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 ?
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

[p***@public.gmane.org]

Hi Julun,

Post by Julun
Karsten == Julun

Ooops!
;-)

Post by Julun
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

Post by Julun
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.

Post by Julun
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.

[Julun]

Hi Philippe,

Post by p***@public.gmane.org

Post by Julun
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.

Post by p***@public.gmane.org
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.

Post by p***@public.gmane.org
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.

Post by p***@public.gmane.org
What's wrong with having a "Save As PDF" printer node?

Nothing?

Post by p***@public.gmane.org
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.

Post by p***@public.gmane.org
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.

Post by p***@public.gmane.org
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.

Post by p***@public.gmane.org

Post by Julun
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.

Post by p***@public.gmane.org

Post by Julun
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

[Michael Pfeiffer]

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

[p***@public.gmane.org]

Hi Michael,

Post by Michael Pfeiffer
And before we think about implementing it we should finalize R1 first.
There are some things that should be improved, for example (somewhat

The #1 missing feature is that USB printers support is not complete yet
under Haiku!
As most users who will try to print will have an usb printer, I'll bet
that's our top blocker for R1...

Currently, "USB Port" transport add-on rely on an working
/dev/printer/usb/0 entry, but we don't have, as we don't have any
usb_printer driver under Haiku yet.
Maybe we don't need to write a kernel driver. USB transport add-on could do
all by itself using the userland USB Kit.
But it should be done *somewhere* ;-)

Post by Michael Pfeiffer
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.

Agreed.
Plus the discussion show that some evolution is not limited to printing kit
but relate to Translation Kit too.
Which was my point actually: this wider evolution is meat for R2, not R1.

So, let's finish USB printers support first, right.

Bye,
Philippe.

[Julun]

Post by Michael Pfeiffer
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. :)

Post by Michael Pfeiffer
Before we can discuss the API we should define a feature set, based on
that we can then talk about the API.
- 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. :)

Post by Michael Pfeiffer
- 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

Post by Michael Pfeiffer
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

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

Post by Michael Pfeiffer
- The preview window still does not have a tool bar.

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

Post by Michael Pfeiffer
- 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?

Post by Michael Pfeiffer
- 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? :)

Post by Michael Pfeiffer
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?

Post by Michael Pfeiffer
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?

Post by Michael Pfeiffer
, 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 :)

Post by Michael Pfeiffer
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

[Michael Pfeiffer]

Post by Julun

Post by Michael Pfeiffer
- 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?

Post by Julun
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.

Post by Julun
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 :(

I am not sure, but I think Preview in libprint was intended for
debugging purposes only. Anyway but this could be fixed.

Post by Julun
- printer based PageSetup/ JobSetup but without print_server
interaction

This is not a new feature. Page/job setup is already there.

Post by Julun
- Print Preview, using a PreviewPanel directly from inside the
application

OK.

Post by Julun
- 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.

Post by Julun
- 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)

Post by Julun
- wrapper class around cups provided api

Not a feature.

Post by Julun
- some convenient classes around printing

- to improve reusability?
- to easy programming?

Post by Julun

Post by Michael Pfeiffer
- 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.

Post by Julun
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.
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.

Post by Julun

Post by Michael Pfeiffer
- 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.

Post by Julun

Post by Michael Pfeiffer
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?

[Incompatible graphics model]
Like alpha blending is/was not supported in PostScript...
Like not all drawing modes are/were not supported in PostScript...
Like issues with clipping or inverse clipping...

[PPD Support in PS driver]
I don't need to explain that?

[CUPS as printer driver]
A part of CUPS acts like a filter chain. It takes a file, for example
PostScript, and converts it in one or more steps to a stream than can
be sent to a printer.
So we need a Haiku printer driver that prepares the print job so it
can be used as input for the CUPS filter chain (convert it to either
PostScript, PDF, or CUPS "raster" format). The output of that chain is
then sent via transport add-on to the printer. This was actually the
plan for the HCD CUPS project... The PostScript driver should be
adapted for that.

[CUPS raster format]
CUPS understands many different "input" formats (for example plain
text too, or standard raster image formats (gif, png, (don't quote me
on that, though)).
The "raster" format is a multi page format whose contents are raster
images and it contains additional data about the print job (similar to
our print job file).

The advantage of a Haiku CUPS raster printer driver compared to PS
driver is, that the step processing step could be eliminated that way:
PS driver: print job -> PS -> GhostScript -> CUPS filter chain
Haiku raster printer: print job -> raster file -> CUPS filter chain

Post by Julun

Post by Michael Pfeiffer
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?

Good idea. I would put open tasks into Trac and thoughts about R2 into
the wiki. I do not volunteer to do that ;-)

Post by Julun

Post by Michael Pfeiffer
, 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 :)

Post by Michael Pfeiffer
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.

Appreciated.

- Michael

[julun]

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

Post by Michael Pfeiffer

Post by Julun

Post by Michael Pfeiffer
- 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.

Post by Michael Pfeiffer

Post by Julun
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,
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
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.
- system wide print preview support without API change, nor application
support nor printer driver support needed
- 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

Post by Michael Pfeiffer

Post by Julun
- 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.

Post by Michael Pfeiffer

Post by Julun
- Print Preview, using a PreviewPanel directly from inside the
application

OK.

see above

Post by Michael Pfeiffer

Post by Julun
- 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.

Post by Michael Pfeiffer

Post by Julun
- nice cups integration into printing system

Not a feature.
- 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)

Post by Julun
- wrapper class around cups provided api

Not a feature.

But we don't have it, right?

Post by Michael Pfeiffer

Post by Julun
- some convenient classes around printing

- to improve reusability?
- to easy programming?

To easy programming, yes.

Post by Michael Pfeiffer

Post by Julun

Post by Michael Pfeiffer
- 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.

Post by Julun
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.

Post by Michael Pfeiffer
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.

Post by Michael Pfeiffer

Post by Julun

Post by Michael Pfeiffer
- 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>

Post by Michael Pfeiffer
[Incompatible graphics model]
[CUPS as printer driver]
[CUPS raster format]

<snip>

I will come back on that part separately.

Post by Michael Pfeiffer

Post by Julun
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

[Michael Pfeiffer]

Post by Michael Pfeiffer

Post by Julun
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.

IIRC that code was inside an ifdef and was enabled for debugging only.

Post by Michael Pfeiffer
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?

You wrote:
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?

- Michael

[Julun]

Hi Michael

Post by Michael Pfeiffer

Post by Michael Pfeiffer

Post by Julun
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.

IIRC that code was inside an ifdef and was enabled for debugging only.

Ok, thanks. Need to look at the diff then.

Post by Michael Pfeiffer

Post by Michael Pfeiffer
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?

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?

Now i got it. If you or someone else is willing to maintain it
and all it's dependencies, i won't replace it for sure. :)

Karsten

[Michael Pfeiffer]

Post by Julun
Hi Michael

Post by Michael Pfeiffer

Post by julun

Post by Michael Pfeiffer

Post by Julun
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.

Post by Michael Pfeiffer
IIRC that code was inside an ifdef and was enabled for debugging only.

Ok, thanks. Need to look at the diff then.

I was wrong about that, the Preview window was enabled in r19882:
http://svn.berlios.de/viewcvs/haiku?rev=19882&view=rev

As you have already mentioned the behaviour is somewhat strange in
combination with the combined printer selection and page/job setup
dialog in Haiku. It feels strange after you close the job setup dialog
of the printer driver either with "Print" or with "Preview" that the
combined dialog is opened again.

The combined dialog can be disabled in print_server (set
fUseConfigWindow to false in PrintServerApp constructor) so then it
behaves as R5. The dialog provides however two features:
- printer selection during page or job setup
- page setup during job setup
It was a compromise to provide these features without the need of a
new printer driver interface. What I wanted in R2 was to inline the
page and job setup into that dialog. That should then avoid the
strange behaviour.

Anyway I should not have contributed to this discussion in the first
place, as I don't want to think about R2 at this time.

- Michael

[julun]

Hi Michael,

Post by Michael Pfeiffer

Post by Julun
Hi Michael

<snip>

Post by Michael Pfeiffer
The combined dialog can be disabled in print_server (set
fUseConfigWindow to false in PrintServerApp constructor) so then it
- printer selection during page or job setup
- page setup during job setup
It was a compromise to provide these features without the need of a
new printer driver interface. What I wanted in R2 was to inline the
page and job setup into that dialog. That should then avoid the
strange behaviour.

I understand the idea behind the dialog and I've seen that flag.
Anyway, i don't think we should disable it.

Post by Michael Pfeiffer
Anyway I should not have contributed to this discussion in the first
place, as I don't want to think about R2 at this time.

Sad to hear that, as I'm always interested in your opinion. You are
the main contributer so far, and i appreciate your comments. Maybe i
should work on my wording when writing mails :(

Karsten

[Simon Gauvin]

Post by Julun
Hi Philippe,

Post by p***@public.gmane.org
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.

This is indeed a valid point from a users perspective. "Printing" or "exporting"
a PDF file from a programs native internal format is a layer of abstraction
created by technical issues of how the PDF is created that need not be presented
to the user. In the users world a file is file, whether it is PDF, PNG, JPEG,
DOC, etc. In every situation the File menu Save As... menu item is the
appropriate place for accessing this functionality. And everyone can attest to
the fact that a file dialog being presented during a Print command is an awkward
and confusing interface. The question then is whether PDF file creation should
even be in the realm of printing? Perhaps it should more appropriately be a BeOS
Translator plugin... even if it uses printing API's underneath, the user never
needs to know this.

-----------------------------
Simon Gauvin
Ph.D. Candidate
Faculty of Computer Science
Dalhousie University, Canada
http://www.cs.dal.ca/~gauvins

[Jorge Mare]

Post by Simon Gauvin
Perhaps
it should more appropriately be a BeOS Translator plugin... even if it uses
printing API's underneath, the user never needs to know this.

You read my mind. +1 to a PDF data translator.

Jorge

[Julun]

Hi Jorge,

Post by Jorge Mare

Post by Simon Gauvin
Perhaps
it should more appropriately be a BeOS Translator plugin... even if it uses
printing API's underneath, the user never needs to know this.

You read my mind. +1 to a PDF data translator.

sad, but this is supposable never going to work.

Regards,
Karsten

[Jorge Mare]

Post by Julun
Hi Jorge,

Post by Jorge Mare

Post by Simon Gauvin
Perhaps
it should more appropriately be a BeOS Translator plugin... even if it uses
printing API's underneath, the user never needs to know this.

You read my mind. +1 to a PDF data translator.

sad, but this is supposable never going to work.
From the user POV, print to PDF is not intuitive, and a PDF data

translator that allows Save as PDF and/or even drag-and-drop to PDF
(as with the other translators) would provide a much more
intuitive/natural workflow to the user. PDF is just another format
anyway.

I have no clue how a PDF data translator could be implemented. I also
realize that this may be beyond the scope of this team. I think Simon
was trying to point out the POV of the users Haiku is trying to cater
to, as this sometimes can get lost in technical discussions, and I
just agreed with him. :)

Jorge

[Julun]

Hi Simon,

Post by Simon Gauvin

Post by Julun
Hi Philippe,

Post by p***@public.gmane.org
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.

This is indeed a valid point from a users perspective. "Printing" or
"exporting" a PDF file from a programs native internal format is a layer
of abstraction created by technical issues of how the PDF is created
that need not be presented to the user. In the users world a file is
file, whether it is PDF, PNG, JPEG, DOC, etc. In every situation the
File menu Save As... menu item is the appropriate place for accessing
this functionality.

I intended more to have a separate "Save as PDF" menu item, which
indeed uses the hopefully existing printing code, to write out
the file directly based on the applications stored BPrinter.

And everyone can attest to the fact that a file

Post by Simon Gauvin
dialog being presented during a Print command is an awkward and
confusing interface. The question then is whether PDF file creation
should even be in the realm of printing? Perhaps it should more
appropriately be a BeOS Translator plugin... even if it uses printing
API's underneath, the user never needs to know this.

this is something I'm going to try. But not as translator in the
usual way.


Regards,
Karsten

[Simon Gauvin]

I intended more to have a separate "Save as PDF" menu item, which indeed
uses the hopefully existing printing code, to write out the file
directly based on the applications stored BPrinter.

Why create a separate menu item for a specific file format? What happens when
the user wants to save to PNG, or DOC, or XML, will the file menu have "Save as
<FIlE TYPE>" for each FILE TYPE menu item in the File menu? Of course not, and
the reason is one of dependency. Creating a "Save as PDF" creates a hard
dependency between the GUI and the function of saving various file types. That's
why translators were invented, so that this dependency can be broken and allow
system-wide functionality that essentially comes free with every program.

Although technically difficult to do, and perhaps all the more reason to do it,
creating a PDF translator is not impossible. The issue, from what I can
understand from the conversations here, is one of pagination. So, assume that
this translator needs to display a dialog allowing the user to select a page
size and various other properties once they click the Save As button in the file
output dialog. Problem solved.

Technically selecting a PDF drop down menu in the "Save As..." dialog for a
translator should be no more complex than making a "Save as PDF" menu item, but
it makes a lot of difference to the users, and to the quality of the software
engineering used in the OS.

However, I tend to agree that this is an R2 issue and that there are more
pressing items to be solved for R1.

Simon

[Julun]

Hi Simon,

Post by Simon Gauvin

Post by Julun
I intended more to have a separate "Save as PDF" menu item, which
indeed uses the hopefully existing printing code, to write out the
file directly based on the applications stored BPrinter.

Why create a separate menu item for a specific file format? What happens
when the user wants to save to PNG, or DOC, or XML, will the file menu
have "Save as <FIlE TYPE>" for each FILE TYPE menu item in the File
menu? Of course not, and the reason is one of dependency. Creating a
"Save as PDF" creates a hard dependency between the GUI and the function
of saving various file types. That's why translators were invented, so
that this dependency can be broken and allow system-wide functionality
that essentially comes free with every program.
Although technically difficult to do, and perhaps all the more reason to
do it, creating a PDF translator is not impossible. The issue, from what
I can understand from the conversations here, is one of pagination.

Well, that would be the smallest problem. Imagine the following
case, there are two word processing application available for
Haiku. One is really stupid, like StyledEdit, it's fine to put
everything into BPrintJob and pass it on to the translator. But
then there is the other one, Haiku Office ;) and it is trying to
be smart, having hyperlinks, animations, flash, clickable links
to jump inside the document or whatever one can embed, now try to
solve that with BPrintJob and get it into the pdf...

So the application needs to implement it's own exporter, to get
all features out. I instead intend to have basic pdf output
available, nothing fancy.

And of course you can add the "Save as pdf" menu item wherever
you want and call the printer code later on. What would prevent
you as dev from doing this? Come on. :)

Regards,
Karsten

[p***@public.gmane.org]

Hi Karsten,

Post by Julun

Post by p***@public.gmane.org
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.

But not before, as one print job can't necessarily be processed immediatly,
mostly because the print target can be a shared one (like a single printer)
for which access should be serialized.
While it doesn't apply when target is a file - only if it's a distinct
file, this serialization needs some queue mechanism or the user app will
wait until job is totally printed, which is not desirable, I guess you will
agree.

That what printer node(s) does, queing. Plus hosting via attributs every
printer specific configuration.
BTW, as a print spooler can be suspended/restarted too, or the printer
device unavailable, the queue is then far less temporary and should/would
even survive a restart. Which is a nice feature, in particular when you
printer is back online...

Post by Julun
I see it more as an translator, to write out pdf files.

+

Post by Julun
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.

Now I see what you don't like in the current design.

It's not a translator because we can't translate magically any application
data into a multipages document without first have specified a multipages
document data format. Such translator is desirable indeed, and maybe for R2
we will have such document format so we could translate into PDF, HTML/XML,
Word, OpenDocument or whatever.
But until this time, we can't translate at all into PDF.
If such a translator will ever be designed and written, the same PDF core
should be (re)used by both PDF print driver and translator, obviously.

What we do now is taking advantage of the only situation when we have a
multipages document data format : applications to support printing have to
paginate their content, and the BPrintJob convert it into a known data
format : the prin job structure.

BTW, the verb "Print..." in app's menu is obsolete since user can also fax,
write pdf and whatever other print -> document gateway using this command.
Sometimes I hope someone will comes with a better command name.

Post by Julun
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.

And here is the actual needs for a standard multipages document format. The
current PDF Writer core code could be converted into a PDF translator for
example. Such translator would expect in input a format very similar to the
today print job file structures.

Then a newer PDF Writer will just wrap this PDF translator, handing its
input print job data, after some conversion, and capturing the translated
output to pass it directly to its print transport add-on.

The key is really in defining a multipages document format. I think a
polished one based on the current print job strutures (list of pages, each
with a list of BPictures, mostly) could be set easily, even for R1.
Some food for reflexion...

Post by Julun
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. :)

Thanks to clarify. I hope you take no offense from my remarks either.

Bye,
Philippe.

[julun]

Hi Philippe

Post by p***@public.gmane.org
Hi Karsten,

<snip> :)

I will write more to this in a different mail.

Post by p***@public.gmane.org
Thanks to clarify. I hope you take no offense from my remarks either.

No, I never would. I'm really looking for input, so everything is highly
appreciated! :)


Regards,
Karsten

[Julun]

HI Philippe,

Post by p***@public.gmane.org
Hi Karsten,

Post by Julun

Post by p***@public.gmane.org
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.

But not before, as one print job can't necessarily be processed immediatly,
mostly because the print target can be a shared one (like a single printer)
for which access should be serialized.

True. BTW, did anyone ever notice that you cant process two
preview jobs at the same time... ;)

Post by p***@public.gmane.org
While it doesn't apply when target is a file - only if it's a distinct
file, this serialization needs some queue mechanism or the user app will
wait until job is totally printed, which is not desirable, I guess you will
agree.

I agree, yes :)

Post by p***@public.gmane.org
That what printer node(s) does, queing. Plus hosting via attributs every
printer specific configuration.
BTW, as a print spooler can be suspended/restarted too, or the printer

Oh, and have one ever try to cancel a processing spool job.

Post by p***@public.gmane.org
device unavailable, the queue is then far less temporary and should/would
even survive a restart. Which is a nice feature, in particular when you
printer is back online...

Yes i know this, and i think this is fine.

I probably need to change only one bit here. In case print_server
crashed during spooling, after he comes up again all existing
files are mark for reprocessing. This should only be the case for
files that are not in processing state, still processing marked
files should become failed. Otherwise one of these file might
crash it again. I had it several times while syncing libprint
preview. :)

Post by p***@public.gmane.org

Post by Julun
I see it more as an translator, to write out pdf files.

I didn't have a better word handy.

Post by p***@public.gmane.org

Post by Julun
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.

Now I see what you don't like in the current design.
It's not a translator because we can't translate magically any application
data into a multipages document without first have specified a multipages
document data format. Such translator is desirable indeed, and maybe for R2
we will have such document format so we could translate into PDF, HTML/XML,
Word, OpenDocument or whatever.
But until this time, we can't translate at all into PDF.
If such a translator will ever be designed and written, the same PDF core
should be (re)used by both PDF print driver and translator, obviously.

I agree here too and i would even go so far and say pdf, odf,
etc. translator doesn't make any sense at all. As you said, we
would have to come up with format that the translator knows
to be able to write out, can convert into and everyone else
understands. This shows the limitation of translator add_ons,
they might be good for graphics, audio and such, but everything
more advanced they are kind of useless.

Post by p***@public.gmane.org
What we do now is taking advantage of the only situation when we have a
multipages document data format : applications to support printing have to
paginate their content, and the BPrintJob convert it into a known data
format : the prin job structure.

And this is where i was going to step in, use this well known
format to write pdf out.

Post by p***@public.gmane.org
BTW, the verb "Print..." in app's menu is obsolete since user can also fax,
write pdf and whatever other print -> document gateway using this command.
Sometimes I hope someone will comes with a better command name.

I would love that too.

Post by p***@public.gmane.org

Post by Julun
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.

And here is the actual needs for a standard multipages document format. The
current PDF Writer core code could be converted into a PDF translator for
example. Such translator would expect in input a format very similar to the
today print job file structures.
Then a newer PDF Writer will just wrap this PDF translator, handing its
input print job data, after some conversion, and capturing the translated
output to pass it directly to its print transport add-on.
The key is really in defining a multipages document format. I think a
polished one based on the current print job strutures (list of pages, each
with a list of BPictures, mostly) could be set easily, even for R1.
Some food for reflexion...

Can you elaborate more on this please.


Kind Regards,
Karsten

[Michael Pfeiffer]

Post by Julun
HI Philippe,

Post by p***@public.gmane.org
Hi Karsten,

Post by Julun

Post by p***@public.gmane.org
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.

But not before, as one print job can't necessarily be processed immediatly,
mostly because the print target can be a shared one (like a single printer)
for which access should be serialized.

True. BTW, did anyone ever notice that you cant process two
preview jobs at the same time... ;)

print_server needs support for this special case to not serialize
preview print jobs. More work for you, I guess ;-)

Post by Julun

Post by p***@public.gmane.org
That what printer node(s) does, queing. Plus hosting via attributs every
printer specific configuration.
BTW, as a print spooler can be suspended/restarted too, or the printer

Oh, and have one ever try to cancel a processing spool job.

Of course, however this is not supported with the current printer
driver API. You can cancel only not already started jobs. Closing the
stream to the printer is not always sufficient to stop the printer
from printing and reseting it to wait for the next job.
Currently there is now way to tell the printer driver to stop
processing of the print job. Anyone correct me if I am wrong.

- Michael

[Michael Pfeiffer]

Post by Julun
Oh, and have one ever try to cancel a processing spool job.

That's fixed in r27113 now. However it's not an elegant solution as it
uses hard-coded transport add-on names. That should be fixed in R2, or
whatever...

- Michael

[julun]

Hi Michael,

Post by Michael Pfeiffer

Post by Julun
Oh, and have one ever try to cancel a processing spool job.

That's fixed in r27113 now. However it's not an elegant solution as it
uses hard-coded transport add-on names. That should be fixed in R2, or
whatever...

thanks. :)


I just have a question about ticket:

http://dev.haiku-os.org/ticket/1067

Do you think it needs to be fixed for the Alpha or should we leave it
for R1? It basically renders everything useless done on the print kit
side if the amount of data exceeds a given size. But it will be
reported as not working printing stuff. Any opinions?

Regards,
Karsten

[Michael Pfeiffer]

Post by Julun
Hi Michael,

Post by Michael Pfeiffer

Post by Julun
Oh, and have one ever try to cancel a processing spool job.

BTW, did anyone ever notice that you cant process two

preview jobs at the same time... ;)

Post by Julun

Post by Michael Pfeiffer
That's fixed in r27113 now. However it's not an elegant solution as it
uses hard-coded transport add-on names. That should be fixed in R2, or
whatever...

thanks. :)
http://dev.haiku-os.org/ticket/1067
Do you think it needs to be fixed for the Alpha or should we leave
it for R1?

I am for Alpha. Let's discuss this in the ticket thread.

- Michael