Hello, On Aug 9 18:00 Dmitry P wrote (shortened): > Is it possible to setup your tool to get a print-preview before > printing process starts?
What exactly do you expect to get from a "print-preview"? Only a graphical output of the PostScript which is produced by whatever application or a graphical WYSIWYG representation what the printer will actually output? The latter is is not possible (but something similar is possible). Reasoning: The printing dialog (i.e. the program which shows you the print-preview) would have to ask the printer somehow what it would actually produce. In particular a big-and-fat network (PostScript) printer which is only accessible via a CUPS server. Such printers decide (based upon their internal settings) what to do when there is e.g. A4 content but only Letter paper is available or something linke this. Some printers scale it onto the paper which is available, some clip what doesn't fit on the paper, some stop printing and request on their display to insert proper paper, ... Assume that the printer driver can ask the printer somehow what it would actually do, then it does still not work for printing via network. 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 know the possible options and option values (and forbidden combinations of option settings) from the PPD (printer description file) but it does not know what the printer will actually spit out for each allowed combination of option settings. Therefore I think that a "wysiwyg preview" is not possible. With "not possible" I mean "not possible so that it works well in almost every case". All I wanted to point out is that one cannot rely on having a bidirectional communication between printing dialog and printer to build up a truthful "wysiwyg preview". On the other hand what is possible is a graphical representation what the summary effect of several combinded option settings is according to the information from the PPD. I think it would be sufficient to avoid 99% of false printouts if only the intentions in the document (e.g. the "BoundingBox") are compared with the announced capabilities of the device according to its PPD (e.g. the "ImageableArea" for the selected "PageSize"). >From the rest of 1% false printouts I think that 99% happen when the announced capabilities of the device (via its PPD) do not match with its actual capabilities. To avoid the latter, it is since CUPS 1.2 possible that drivers query the printer for its actual capabilities and spit out an exact matching PPD file, see "dynamically-generated PPD files" at http://www.cups.org/documentation.php/man-cups-driverd.html This way the queue can be set up with an exact matching PPD file so that only 0.01% false printouts are left. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ HPLIP-Help mailing list HPLIP-Help@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-help
