Bug 205179 - print/hplip: PPD German translation reversed for "Long/Short-Edge Binding"
Summary: print/hplip: PPD German translation reversed for "Long/Short-Edge Binding"
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Ben Woods
URL: https://bugs.launchpad.net/hplip/+bug...
Keywords:
Depends on: 207746
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-10 06:43 UTC by O. Hartmann
Modified: 2017-12-24 11:16 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2015-12-10 06:43:09 UTC
Using most recent CURRENT (11.0-CURRENT FreeBSD 11.0-CURRENT #0 r292014: Wed Dec  9 11:17:26 CET 2015 amd64) and most recent ports tree (Revision: 403440) and an updated ports collection via traditional port building and updating on a daily/weekly basis, CUPS printing system is doing wrong with HP OfficeJet Pro X451dw.

CUPS is installed as follows:

cups-2.0.3_1
cups-base-2.0.3_3
cups-client-2.0.3_2
cups-filters-1.2.0
cups-image-2.0.3_2
cups-pstoraster-8.15.4_8
gutenprint-cups-5.2.10_1
hplip-3.14.10_1

Printing DIN A4 paper.

The error:

The HP OfficeJet X451dw is equipted with a duplexer. Using CUPS, one has to enable the duplexer in the standard configuration. Usually, duplexing allows two types of binding: left binding - this is as we now it when we read a book, the pages "get bound" at the left hand edge of the page 9flipping the page to the left reveals the back of the page and it is still readable without turning it 180 degree). Or we can choose a "top binding" - which means, the back of a double-sided page is still readable without turning you 180 degree, if you flip the page upward - like a flipchart or a wall-calender.

I figured out, using FreeBSD's (outdated) CUPS 2.0.3 system (CUPS has > 2.1 now), that duplex printing in conjunction with the driver PPD provided by HP via port print/hplip-3.14.10_1, namely  /usr/local/share/ppd/HP/hp-officejet_pro_451_series-ps.ppd.gz, does wrong!

If someone configures a print queue the classical way for duplex printing, setting duplexing to enabled and set binding to left - as one would expect to do, the binding on small PDFs is top (like the flipchart/wall-calender). Switching to "binding top" is then as expected. But this does not hold for larger PDFs like a book with ~300 pages (I tested only on that sizes). They get always print like flipcharts when doing duplex printing!

I do not have the time to investigate this deeper, so I did not check on PS files - it doesn't matter, the printing is wrong anyway and PDF is very common. I tried the very same printer with the very same configuration, but this time with Linux Ubuntu 15.10, which comes with CUPS 2.1 (didn't check for the minor numer) and the configured hplip (version unknown). The problem I face with FreeBSD's port selection is not present there.

The print system is rendered useless in this case.
Comment 1 Tijl Coosemans freebsd_committer 2016-03-11 14:31:22 UTC
Can you test again with cups 2.1.3?
Comment 2 O. Hartmann 2016-03-15 07:03:04 UTC
No, still the same after the upgrade, but I suppose there is a translation mistake. Nothing bad, but irritating.
Comment 3 Tijl Coosemans freebsd_committer 2016-03-15 08:49:17 UTC
I see our ghostscript is outdated.  What version does Ubuntu ship?
Comment 4 Tijl Coosemans freebsd_committer 2016-03-15 09:23:46 UTC
Actually, we do have a more recent version.  If you have ghostscript9-base installed try replacing it with print/ghostscript9-agpl-base.
Comment 5 O. Hartmann 2016-03-15 09:43:48 UTC
ghostscript9-base ist installed by default, why not define ghostscript9-agpl the default if that port is up to date or more recent?

Why is Ubuntu the norm factor we have to come along with?
Comment 6 Tijl Coosemans freebsd_committer 2016-03-15 10:53:26 UTC
I'm looking for differences with Ubuntu because you mentioned it worked there.  If using ghostscript9-agpl fixes the problem I'll push for making it the default.
Comment 7 O. Hartmann 2016-03-15 14:02:40 UTC
Could the culprit be the ppd file? The problem does only occur when the German translation is seletced - it works as expected when English is the default. Haven't tried French oder Japanese ... I think someone swapped the menu text with the semsntics in the ppd ...
Comment 8 Tijl Coosemans freebsd_committer 2016-03-15 16:17:58 UTC
Here are the different translations in the PPD files:

*de.Duplex DuplexNoTumble/An langer Kante spiegeln (Standard): ""
*de.Duplex DuplexTumble/An kurzer Kante spiegeln: ""

*de.Duplex DuplexNoTumble/Binden an langer Kante: ""
*de.Duplex DuplexTumble/Binden an kurzer Kante: ""

*de.Duplex DuplexNoTumble/Bindung an langer Kante (Standard): ""
*de.Duplex DuplexTumble/Bindung an kurzer Kante: ""

*de.Duplex DuplexNoTumble/Bindung an langer Kante: ""
*de.Duplex DuplexTumble/Bindung an kurzer Kante: ""

*de.Duplex DuplexNoTumble/Bindung oben: ""
*de.Duplex DuplexTumble/Bindung links: ""

*de.Duplex DuplexNoTumble/Lange Kante spiegeln (Standard): ""
*de.Duplex DuplexTumble/Kurze Kante spiegeln: ""

"Bindung oben" and "Bindung links" seem to have been switched.
Comment 9 Tijl Coosemans freebsd_committer 2017-01-12 16:50:56 UTC
This is just a translation error in some hplip PPDs.  Assign to hplip maintainer.
Comment 10 Ben Woods freebsd_committer 2017-12-24 11:15:29 UTC
This bug has been reported to the hplip upstream maintainers:
https://bugs.launchpad.net/hplip/+bug/1739953