Created attachment 66261 [details] Xerox PPD using JCL options JCL Options from PPD does not show in Print -> Properties -> Device This makes it impossible to use all features on a Xerox 7545, in particular it is not possible to select black&white or color at printing. Steps to reproduce: 1. Install a printer in Cups with a PPD that users JCL options (see below) 2. Start Libreoffice, new text document, and type a few characters 3. Go to File -> Print and select the printer from (1) 4. Open the 'Properties' tab 5. Open the 'Device' tab 6. Locate the JCL options Current behavior JCL options can not be found Expected result JCL options should be found somewhere Platform: Fedora 17, x86_64 fully updated 20012-08-27 Libreoffice 3.5.6.2-1.fc17 x86_64 Printer: Xerox 7545 with PPD "Xerox Global Printer Driver PS3", "XRX7675.PPD", http://print.chalmers.se/drivers/tme-i-2345-laser1.ppd as recommended by Xerox This file uses JCL to select color correction mode (color/blackwhite/cmyk/..) for the printer. Snippet from the PPD: *% Color Correction *JCLOpenUI *JCLColorCorrection/Color Correction: PickOne *OrderDependency: 10.7 JCLSetup *JCLColorCorrection *DefaultJCLColorCorrection: Auto *JCLColorCorrection Auto/Automatic: "@PJL COMMENT OID_ATT_COLOR_MODE OID_VAL_COLOR_MODE_AUTOMATIC<0A>" *JCLColorCorrection sRGB/sRGB Display: "@PJL COMMENT OID_ATT_COLOR_MODE OID_VAL_COLOR_MODE_SRGB_DISPLAY<0A>" *JCLColorCorrection BlackWhite/Black & White: "@PJL COMMENT OID_ATT_COLOR_MODE OID_VAL_COLOR_MODE_BLACK_WHITE<0A>" *JCLColorCorrection PressMatch/Press Match: "@PJL COMMENT OID_ATT_COLOR_MODE OID_VAL_COLOR_MODE_CMYKSimulation<0A>" *JCLColorCorrection None/None: "@PJL COMMENT OID_ATT_COLOR_MODE OID_VAL_COLOR_MODE_NONE<0A>" *JCLCloseUI: *JCLColorCorrection End snippet This ppd uses JCL for a lot of other stuff also, but the problem is the same. Background: In order to get a color printout, the generated file (PS or PDF) must be in color, AND the printer must accept to print color. To get a black output the generated file must be black OR the printer must deny printing in color. Easy? Not! Now what happens if an application that is in popular use always outputs in color, resulting in an excessive amount of color printouts, which could have been printed in black at a much lower cost? Then the only way to get black is by forcing the printer to deny color. Most of the printouts should be black, so the good default value for the printer is deny color, and that has to be set in the printer itself. To get color, go into the properties tag at printout, and select color when color printing is needed. This of course is possible only if there is a possibility to change the value. It is possible in many applications. but does not work in Libreoffice! Why? Because on this printer that option is handled by JCL, and Libreoffice ignores JCLoptions in the ppd. Firefox works correctly. What application can be that stupid that it does not give the users a color/black choice? Acrobat Reader om Windows! Remember that the printers are shared between many different OS, applications and users. We need to have consistent default values, and consistent handling of options across all these. As I can see, there is a very limited number of solutions: * Drop Acrobat Reader (And all other Adobe programs) Probably not accepted by the users, but I would like to. * Do not use Xerox printers until the problem is solved (Hello Xerox marketing, we buy 100 printers every year!!!!) * Stop using LibreOffice until this bug is corrected. This is a very unpleasant way, but we may be forced take that direction. This is not new. There is an old bug report from 2007-05-02 in the openSUSE Bugzilla. https://bugzilla.novell.com/show_bug.cgi?id=270479 OpenOffice ignores PPD options in JCLOpenUI/JCLCloseUI The status is "resolved", but I can not find any traces of that in Openoffice/Libreoffice/Apacheoffice. The problem is still in current version, waiting for a resolution. To show that I am not alone having problems with color/black printing, a quote from https://bugs.freedesktop.org/show_bug.cgi?id=47278 |The pdf export always produces a color-mode pdf, even when the document being |exported is all black text. This is a serious problem when you are using a |leased printer that is billed per impression, when color impressions are |literally ten times more expensive than greyscale impressions. Yes, this is about PDF output, my point is that color printout cost more money. It has to be very easy to use color only when needed, and black anytime else. If it is too cumbersome to get color, the user will put color as default, and then the cost will go to the sky. I have a small installation, and we print approx 22 million pages every year. Our cost for 22M black is 150.000 USD, for 22M color 1.700.000 USD Color is expensive, and i would hate to be forced to use MS Office in order to reduce cost. And no, exporting as PDF, and using a separate application to do the real printing is not an usable workaround. The only acceptable workaround is to in some way have the output piped through some other program, maybe an PDF-reader, but then it has to be integrated so the user dont have to know or see all the nasty details. //Bse Börje Sennung System Administrator Chalmers universiyu of technology bse@chalmers.se +46 31 772 6736
I discovered this error when creating letter through the wizard. After creating the letter, editing to insert text, especially a copy-and-paste operation from some other document or web site, for example, results in incorrect character spacing at the point where the insertion occurred. I also observe that character spacing within a line where a word might be capitalized can also display this error. (e.g., "trustees under The Mead Family Trust," as an indented line will print as "trustees under TheMead Family Trust,". Although the GUI presentation has the correct appearance, both printed and "save as PDF" versions of the document have incorrect spacing - usually observed with words run together.
requesting additional input - we'll have to have someone who knows something about JCL options
JCLOptions can be treated in almost the same way as the other options. As I understand, the distinction is that the application can decide to not show JCLoptins (Why hide information from the user ??). I thing that one way to handle it is to have a spareta tab in the output dialogfor these. I am not the author of PPD:s and such. I think that someone in the Printing Working Group (Micheal Sweet and friends) can come with the good answer Börje Sennung System administrator Phone : +46 31 - 772 6736 Chalmers University of Technology Fax : +46 31 - 772 8660 412 96 Göteborg Sweden E-mail : bse@chalmers.se ________________________________ From: bugzilla-daemon@freedesktop.org [bugzilla-daemon@freedesktop.org] Sent: Thursday, June 27, 2013 16:17 To: Börje Sennung Subject: [Bug 54186] : JCL Options from PPD not shown in Print -> Properties -> Device Caolán McNamara<mailto:caolanm@redhat.com> changed bug 54186<https://bugs.freedesktop.org/show_bug.cgi?id=54186> What Removed Added See Also https://bugzilla.novell.com/show_bug.cgi?id=270479 ________________________________ You are receiving this mail because: * You reported the bug.
well, I can set this to confirmed anyway. We don't show the JCL options in the ui.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2ee1de716cd8326cd56d441019db2c32b2e10a32 Related: fdo#54186 show JCL options, parse JCLOpenUI the same as OpenUI The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The above definitely works for me to make the JCL options visible alongside the "normal" PPD options. You can try in tomorrows dailies to see if that actually then goes on to do the right thing afterwards if you try and use them on a real printer. I didn't bother to separate them from the other options. If it does work, and someone feels that its necessary to show them in a separate category feel free to open a new request for that. If they fail to work at all, then reopen this bug. If it does actually work then let me know and we can consider backporting this to 4.1.