[Printing-architecture] [Printing-summit] Print Dialog: Preview Processing: Only A Question

Petrie, Glen glen.petrie at eitc.epson.com
Thu Apr 23 06:29:52 PDT 2009


I think the situation is like this...

The preview, in most cases, will not be generated by the printer-driver
or by the printer itself.  Printing, that is, the rendering of physical
page from the electronic page is a one-way process done within the
printer-driver or within the printer. In almost all cases (maybe all
cases), it will be a filter (that means Ghostscript) that will generate
the preview.  The filter is taking the electronic document page (PS,
PDF, image(jpeg, tiff, png, ...), ...) and producing an "electronic
print page" (an image) for viewing or passing to printer-drivers (or
printers) that process only image data.

I am not aware of a printer-driver that directly generates preview

(Just to make sure, the "printer-driver" is the software/firmware that
takes the electronic print content and converts its into printer
specific commands to produce physical printed pages.  For example,
inkjet "printer-drivers" typical take in images and rasterize the image
to PCL for HP, ESC/P for Epson, and so forth.  In this case, the
"printer-driver" output is not displayable (unless you were to use a


> -----Original Message-----
> From: Johannes Meixner [mailto:jsmeix at suse.de]
> Sent: Thursday, April 23, 2009 2:39 AM
> To: peter sikking
> Cc: Petrie, Glen; printing-architecture at lists.linux-foundation.org;
> printing-summit at lists.linux-foundation.org
> Subject: Re: [Printing-summit] [Printing-architecture] Print Dialog:
> Preview Processing: Only A Question
> Hello,
> On Apr 22 17:56 peter sikking wrote (shortened):
> > Glen wrote (shortened):
> ...
> >>  I don?t believe that the actually printer driver would be needed
> >> render the preview at the level needed for the preview; so this
> >> keeps generation of the preview within the confines of the print
> >> dialog.
> >
> > I agree.
> I do not understand how this fits to what Peter required
> in his previous mails:
> ------------------------------------------------------------------
> ...
> the usability test results proved that the preview is a huge
> success and needs to be 100% "true"
> ...
> without a doubt _and_ proven by our first tests: the preview
> needs to be a lo-res version of exactly what will come out
> of the printer.
> -----------------------------------------------------------------
> How should the preview be 100% "true" when it is done only
> "within the confines of the print dialog" (i.e. without
> the actual printer driver and without the actual printer)?
> I understand that a "combination of the printer driver
> and the dialog set-up files" (see the mails at the bottom)
> might be able to generate a true wysiwyg preview
> but I do not understand at all how to do it
> without driver and printer.
> Compare what I wrote in a previous mail here:
> ------------------------------------------------------------------
> For example to get a preview which is "exactly what will
> come out of the printer" ;-)
> To make such a preview, the printing dialog must query the
> printer device (e.g. to find out which media is currently
> actually loaded).
> ------------------------------------------------------------------
> Regarding "cupsfilter" see
> http://www.cups.org/documentation.php/doc-1.4/man-cupsfilter.html
> ------------------------------------------------------------------
> cupsfilter currently does not use the filters defined in
> the PPD file. This will be addressed in a future CUPS release.
> ------------------------------------------------------------------
> The driver is one of the filters defined in the PPD file
> so that currently cupsfilter does not run the driver
> so that currently cupsfilter cannot produce an image
> which shows '100% "true" exactly what will come out
> of the printer'.
> To aviod another mail war:
> I neither want to accuse a programmer (like "your software
> is bad because it does not do what the user wants")
> nor to accuse an usability expert (like "your usability test
> are bad because the users ask for nonsense stuff").
> I only want to avoid a continuous misunderstanding between
> programmers and usability experts which results in the end
> nothing else but frustration when in the end the software
> does not do what the usability experts wanted simply
> because at the current time it was not possible for the
> programmer to implement what the usability experts wanted.
> I fully agreed all the time that "true wysiwyg" is what
> everybody wanted and wants to have.
> But on the other hand I think that it does not help to
> only demand it without listening to what is currently
> possible to be implemented and adapting the current
> requirements to what is currently possible.
> I think this is a precondition so that it is possible
> to move forward step by step to "true wysiwyg".
> I think it might help a lot when the usability experts
> keep the "true wysiwyg" requirement as ultimate goal
> but provide some fallback designs what to do
> when this or that precondition for "true wysiwyg"
> is not fulfilled:
> E.g. what should be shown as "best effort preview" when
> - it fails to find out e.g. which media is currently
>    actually loaded in the printer (e.g. when there is
>    no communication with the printer device)
> - it fails to find out anything at all about the printer
>    (e.g. when a laptop user is on his way and prints into
>    a local queue which points to a remote queue on a remote
>    CUPS server where the PPD file is located but the server
>    is currently not accessible)
> For more information have a look at
> https://lists.linux-foundation.org/pipermail/printing-
> summit/2007/001140.html
> ------------------------------------------------------------------
> printing dialog cannot reliably determine what the
> physical outcome will be - it can only guess the physical outcome
> by hoping that everything works as the printing dialog assumes
> see (*) below.
> ...
> Unfortunately some printer manufacturers make also cheap and stupid
> printers ( for their customers who like to buy cheap hardware ;-)
> Those printers get their input data as a "bitmap" of dots which are
> to be printed and usually the driver of such a piece of hardware
> cannot ask the printer which paper is currently loaded.
> Often the printer is so stupid that it doesn't know it but usually
> the reason is that there is no bidirectional communication with
> the printer while a print job is processed (and there is no
> communication with the printer at all while a print job is created
> by the application (*)).
> ------------------------------------------------------------------
> and
> https://lists.linux-foundation.org/pipermail/printing-
> summit/2007/001142.html
> ------------------------------------------------------------------
> Please provide some ideas how such a wysiwyg preview is to
> be implemented so that it really works...
> In particular I like to learn how to get a wysiwyg preview
> for those big printers which do it all internally.
> The printing dialog would have to ask the printer somehow
> what it would actually produce (in particular a network
> printer which is only accessible via a CUPS server).
> E.g. such printers decide (based upon their internal settings)
> what to do when there is A4 content but only Letter paper is
> available or vice versa.
> Some printers scale it onto the paper which is available,
> some clip what doesn't fit on the paper,
> ------------------------------------------------------------------
> and Peter's reply:
> https://lists.linux-foundation.org/pipermail/printing-
> summit/2007/001143.html
> ------------------------------------------------------------------
> The combination of the printer diver and the dialog set-up files
> (PPDs, etc.) controls the dialog, knows how the printer ticks and
> generates the data to the printer. That is enough to make it
> work with near-zero network polling.
> ------------------------------------------------------------------
> and my reply:
> https://lists.linux-foundation.org/pipermail/printing-
> summit/2007/001145.html
> ------------------------------------------------------------------
> For a PostScript printer there is no driver.
> For printing in the network the driver runs on the print server
> so that there is no communication between a user application
> which runs on the user's workstation and the driver which runs
> at any time later when the print job is actually processed
> on the print server.
> The printing system and the user application only knows the
> possible options and option values (and forbidden combinations
> of option settings) from the PPD but it does not know what the
> printer will actually spit out for each allowed combination
> of option settings.
> ------------------------------------------------------------------
> Kind Regards
> Johannes Meixner
> --
> SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
> AG Nuernberg, HRB 16746, GF: Markus Rex

More information about the Printing-architecture mailing list