So, are we saying that the PPD file is the source of the problem?
This did not immediately work. But it did lead to a discovery.
Changing the “ImageableArea Letter” dimensions did nothing.
However, changing the dimensions of “ImageableArea A4” DID.
Which means that, despite “Letter” paper type being shown in all dialogs, the applications are using the A4 paper settings from the PPD.
Good find! 
It might also explain why increasing to 10mm margins helps with keeping the printed image from being cropped.
A4 210 x 297 mm
Letter 216 x 279 mm
Another discovery. Changing the print margins only works when done in the print dialog window, before each print job. Even after editing the PPD to change the default margins to 10mm, the print will still fail after 1 distorted page and the printer throwing an error to load A4 paper.
If, however, I change the margins in the print dialog window, (example: changing the “new” 10mm defaults to 9mm) the print succeeds.
So, it uses the new values if changes, but does not use the existing values as read from the PPD. That is very bad programming.
It’s a total mess. That this basic functionality wasn’t tested before release is embarrassing. That it impacts every North American user but hasn’t been fixed for months is unbelievable. If it’s true that this code is written by people actually paid to write it, they’re frauds. If they were on any of the IT projects that I used to manage, their last pay cheque would have been long ago. Volunteer, for-free code with bugs is one thing. But was someone paid for this? I assume that this bug hasn’t been fixed because they were kicked off and their code is so bad, no one else can read it.
Looking at the KDE and Qt Bug reports and Qt fixes mentioned below, I am reminded that, a company named KDAB is currently involved with resolving Qt printing issues and, a fix is available with Qt 5.11 – openSUSE Tumbleweed – Leap 15.0 has Qt 5.9.4 – Qt code commit December last year: <https://codereview.qt-project.org/#/c/213677/>.
[HR][/HR]Yes, you are correct: the world is not very amused …
Another aspect is, how KDE Plasma uses “QPageSetupWidget::setPrinter” …
[HR][/HR]
[HR][/HR]An explanation of the KDAB activity with respect to Qt printer support is here: <https://www.kdab.com/better-support-for-cups-features-in-qt-5-11/>.
There’s also this short openSUSE Forum discussion: <https://forums.opensuse.org/showthread.php/530655-Changes-being-made-to-KDE-(Qt)-printer-support>.
Let’s keep this discussion at the technical level. Descending into accusations or speculation won’t help progress this bug.
Can anyone confirm that, this issue has been resolved by Qt 5.11 running on the current Tumbleweed version?
Please note that, we’re chasing repairs which may be available with Qt version 5.11 and KDE Frameworks version 5.48.
The corresponding Leap 15.0 ** EXPERIMENTAL ** – meaning: “you’re on your own” – repositories are:
- KDE:Qt5
- KDE:Frameworks5
[HR][/HR]Also, please be aware that, the current openSUSE Leap policy is to use “Long Term Support” (LTS) versions of items such as KDE and Qt.
Whether or not, proper support for international paper sizes will be an argument to, temporarily, move away from this policy or, not, remains to be seen … 
@SUSEtoad:
A couple of questions:
- Does the hardware status page of the printers indicate that, they’re setup for a default paper size of US-Letter? – usually pressing one of the buttons on the printer will cause it to print a status page including such things as the amount of Toner remaining and the total number of pages printed – needed to estimate how much longer the printer will continue working …
- In the printer’s .PPD file, within the sections related to “Paper Handling”, are ‘*DefaultPageSize:’, ‘*DefaultPageRegion:’, ‘*DefaultImageableArea:’ and ‘*DefaultPaperDimension:’ all set to “Letter”?
@deano_ferrari: and @gogalthorp:
Yes, I’ve now reverted the Imaging Area back to that defined in the equivalent printer model (same Laser Print Engine) which handled Postscript and was therefore directly Linux compatible. As far as DIN A4 paper is concerned, the actual printed area is the same as before; the only difference is that, applications now flag the smallest possible page margins – previously I handled the issue purely on hand of the document’s page margins …
[HR][/HR]If anyone is considering using “Scribus” to produce test pages, please be aware that, the current stable Scribus (not a KDE application) version 1.4.7 uses Qt version 4.8.7 – the “next” Scribus version, currently 1.5.4, has been ported to Qt 5.x …
Not explicity. There is no paper type selection on the hardware. The closest setting is in the “copy” function where “Paper Size Group” can be Inches, A, or AB. It is set to “Inches”.
In the printer’s .PPD file, within the sections related to “Paper Handling”
Some do, others do not – Kyocera does …
Looks OK – default “Letter”
The only small point is the "PCFileName:" value – with the last change done to my PPD file, I’ve changed it to the actual Linux .ppd filename in ‘/etc/cups/ppd/’ – the “as delivered by the manufacturer” value may well be that which their machines used, then, but, the current PPD import routines tend to drop another filename into the “/etc/” sub-directory …
[HR][/HR] A report of Tumbleweed’s US paper size behaviour with the newer Qt and KF5 versions hasn’t yet appeared. *
I’ve created US-Letter, US-Legal and US-Executive PDF files with Scribus (allows accurate positioning of grey boxes with 40 point width on the page borders) for testing a printer’s page border behaviour when printed by KDE KF5 Okular & Co – and, they’re all printing without any error on A4 paper with “Letter”, “Legal” (over-ran the bottom edge of the paper – Legal is longer than A4 …) and “Executive” selected as the paper size in Okular’s print dialogue – needed to select “Force halftoning” to prevent the printed image from being resized – became apparent with the “Executive” paper size test.
Unfortunately, the openSUSE Paste <SUSE Paste; doesn’t allow PDF files to be pasted:
Only gif|jpg|png|jpeg|svg files smaller then 2048k are allowed for this time interval.
If you want a copy, send me a private message and I’ll e-Mail the .pdf’s to you.
Is this bug going to see a fix this year? …
Today’s bad news:
- Qt have closed their Change Request with an “Out of scope” resolution …
- KDE have closed their Change Request with a “RESOLVED UPSTREAM” resolution …
[HR][/HR]We need to poll the North American community to see what percentage is also experiencing this issue – I’ll ping a couple of names I know about …
Ping resulted in two replies out of three – and, they’re not seeing any issues with Okular and US-Letter paper sizes …
[HR][/HR]Returning to the beginning of this issue and the Locale, which is en_CA – Canadian English – and therefore, the default paper size should be “US Letter” …
- Regardless of the user output of ‘locale’ does the user have, included in their ‘~/.profile’ file, the line ‘export LANG=en_CA.UTF-8’ ? – KDE tends to be a little bit particular here: it seems to prefer that, the user also sets what has already been set at system level …
- In the file “/etc/sysconfig/language” is ‘RC_LC_ALL’ set? – it shouldn’t be – it affects $LC_ALL which for most systems should not be set …
- In the file “/etc/sysconfig/language”, setting ‘RC_LC_PAPER’ to “en_CA.UTF-8” will not help at all: ’ RC_LANG=“en_CA.UTF-8” ’ is more than sufficient …
- What are the contents of ‘/usr/lib/locale/en_CA/’ and ‘/usr/lib/locale/en_CA.utf8/’ ? They should both have a file named “LC_PAPER” …
Both of these directories are setup by the Leap 15.0 package “glibc-locale-2.26” – it may help to forcibly re-install that package …
[HR][/HR]One last thought: yes, in Canada the de facto standard paper size is “US Letter” but, the Canadian Government also uses ISO paper sizes.
- Could it be that, “some bright spark” has recently changed the “en_CA” Locale “LC_PAPER” variable to ISO A4?
- Meaning, what happens if, in the file “/etc/sysconfig/language” the variable ‘RC_LC_PAPER’ is set to “en_US.UTF-8”? (Will also need to set “LC_PAPER” in the user’s ‘~/.profile’ file … )
No.
In the file “/etc/sysconfig/language” is ‘RC_LC_ALL’ set? – it shouldn’t be – it affects $LC_ALL which for most systems should not be set
RC_LC_ALL=“”
‘/usr/lib/locale/en_CA/’ and ‘/usr/lib/locale/en_CA.utf8/’ ? They should both have a file named “LC_PAPER”
They do.
First trial suggests that this works. Will do more testing.
Looking deeper into the wonderful world of Locale, I’ve come to the conclusion that, there ain’t a tool to dump the contents of the Locale configuration files located in the directory tree “/usr/lib/locale/” …
- There’s only the C System Library call “nl_langinfo” which can be used to access a C structure’s contents and, the parameters ‘_NL_PAPER_HEIGHT’, ‘_NL_PAPER_WIDTH’, ‘_NL_PAPER_CODESET’ and ‘_NL_NUM_LC_PAPER’ which are part of a massive C enumeration in “/usr/include/langinfo.h” …
[HR][/HR]Some programming needed … But, maybe ‘od’ will show some information – considering the “LC_PAPER” files in “/usr/lib/locale/en_CA.utf8/”, “/usr/lib/locale/en_CA/”, “/usr/lib/locale/en_US”, “/usr/lib/locale/en_US.iso885915/” and “/usr/lib/locale/en_US.utf8/”:
- “od -a LC_PAPER” indicates that:
[LIST] - ‘en_CA’ and ‘en_US’ both contain the string “ISO-8859-1”;
- ‘en_US.iso885915’ contain the string “ISO-8859-15”;
- ‘en_CA.utf8’ and ‘en_US.utf8’ both contain the string “UTF-8”.
[/LIST]
I suspect that, the ASCII strings are the ‘_NL_PAPER_CODESET’ values …
- “od -s LC_PAPER” indicates that, – compared against the “de_DE” contents – decimal integer values indicating a paper size of 297 X 216 (US Letter in millimetres) are present in all the en_US and en_CA files.
[HR][/HR]Conclusion: the issue is possibly being caused by the Paper Code Set value being used by the Locale …
Nope. Printing still broken. Printer just doesn’t fail so catastrophically as before, but it still throws an error and the print image is still distorted.