If you ever liked KDE and getting work done is a priority, TDE an option to seriously consider. I have it on more than 20 installations. When I upgrade my primary from 42.3 to 15.0, TDE as a replacement for KDE3 will be included.
Applications receive info about the printer via the print driver. Each app does not magically know about all printers. ie the app thinks there is A4 paper in the printer for some reason. Maybe do to hardware settings on the printer or the print driver or cups.
@gogoalthorp: I know how it works. CUPS gets the appropriate settings from the PPD actually. However, you’ve misunderstood this thread. Read it from the beginning and you’ll realise that the OP has letter size set in the opening post. I had the OP verify this (refer post #4 and post #9). The OP has clearly explained that the problem occurs when using KDE apps (and only KDE apps), with them trying to print letter-size pages as A4, and resulting in distorted printing. This does not happen with GTK applications.
Looking at the comments between last Thursday and today, AFAICS there are two possibilities which, possibly, may have to be executed in parallel:
- Raise the appropriate Qt Bug Report and, a parallel KDE Bug Report for tracking purposes;
- Begin an on-line petition to make it clear to the Qt and KDE developers that, international paper sizes shall never be ignored …
Yes, probably a good strategy…
I now have an account with Qt which allows me to search their Bug Report database and to write Bug Reports …
[HR][/HR]A (Qt) search for “Printer US Letter” revealed:
- QTBUG-35321: “Mac supportedPaperSizes() returns duplicate and invalid values” – Qt version 5.2.0 RC1;
- QTBUG-21613: “QPrinter::setPaperSize(PaperSize) fails on Mac with non-metric paper” – fixed with Qt version 4.8.1;
- QTBUG-6471: “QPrintDialog for unix does not correctly read CUPS settings” – fixed with Qt version 4.6.3.
Despite 2 of the reports being for the Mac world, please realise that, Mac is a (certified) UNIX® and therefore the issue also applies to Linux except that, the Mac world doesn’t seem to be using the Qt API which KDE Plasma is using …
Please realise that, in the Qt world, a bug fixed in an earlier release is also considered to be fixed in later releases …
Be that as it may, the issue seems to be, the way in which the Qt application (in this case KDE Plasma) calls the (Qt) printer routines – the Qt folks seem to suspect that, currently, their printer support routines are OK – at least for the case of “Qt Commercial” …
[HR][/HR]Today’s bad news:
- KDE Plasma code inspection is needed before a Qt Bug Report can be raised to nail the Qt function call which is (possibly) misbehaving …
Can I get some understanding as to why this bug isn’t fixed yet and why it’s taking so long?
I understand that volunteer developers move slowly and there are hundreds of bugs to deal with at any time. But this is CORE FUNCTIONALITY NOT WORKING. How can BASIC PRINTING be broken for EVERY NORTH AMERICAN USER with letter-sized-paper and weeks go past with no fix?
I’m genuinely shocked that alarm sirens aren’t screaming somewhere to get this bug patched, especially with it being known about in several Internet bug-trackers, possibly for months.
SUSEtoad wrote:
>
> Can I get some understanding as to why this bug isn’t fixed yet and
> why it’s taking so long?
>
> I understand that volunteer developers move slowly and there are
> hundreds of bugs to deal with at any time. But this is CORE
> FUNCTIONALITY NOT WORKING. How can BASIC PRINTING be broken for
> EVERY NORTH AMERICAN USER with letter-sized-paper and weeks go past
> with no fix?
>
> I’m genuinely shocked that alarm sirens aren’t screaming somewhere to
> get this bug patched, especially with it being known about in several
> Internet bug-trackers, possibly for months.
>
>
One does begin to wonder whether it’s time to get off the KDE/QT
bandwagon. But what DE to replace it? I really dislike Gnome. So the
choices seem to be old KDE/trinity, XFCE, LXDE, LXQT. What would people
recommend, and why?
–
*********** To reply by e-mail, make w single in address **************
Jus to clarify, it’s the applications that are being used that are relevant here (or rather what they are built with), not the choice of desktop environment one might prefer. For example, if you use Okular (Qt5 app) in XFCE, you’ll still be using the same print subsystem.
I suspect that, with respect to this issue, we should attempt to remain calm …
- Please be aware that, the Qt Company does not have a volunteer community maintaining it’s code – they have (reasonably well paid) employees …
- Yes, KDE does have a volunteer developer community but, there’s also a couple of companies submitting code repairs to the community’s code base …
AFAICS, before we submit a Change Request to the Qt folks, we need to find out if the Qt API being used by the KDE folks really has an issue or not.
If we cannot fault the Qt implementation then, we’ll have to investigate the programming style that the KDE folks are using for the printer support routines.
[HR][/HR]Does anyone have a suggestion for where we can begin an on-line petition to attempt to convince the KDE and Qt folks that, they should take more care with respect to the support of non-European paper sizes?
To that end, I think a KDE bug report is in order. It should fairly easy for them to test/replicate this issue.
@SUSEtoad: Returning to your comment in post #13…
Update: If I change the page margins to 10mm on all sides (Print … Properties … Page), the problem does not occur.
Unfortunately, I have not yet discovered a way for Okular to remember the settings. It always returns to the 5mm L/R & 6mm T/B defaults.
that is an interesting find (to me anyway). Since this works for you, I can help you make the margins permanent.
The default margins are defined in the printer PPD file (located in the /etc/cups/ppd/ directory). Thankfully, they can be changed to suit. In the .ppd file, you’ll find ‘ImageableArea’ values. They represent PostScript points where 72pt = 1" ~= 2.54cm. For example, my Brother DCP-7055 ppd file has the following margins defined…
ImageableArea Letter/Letter: "18 12 594 780"
pertaining to 6.35mm from left and right edges, and 4.23mm from top and bottom. (The corresponding Letter page size is 612 pts x792 pts).
To set 10mm margins for Letter-sized paper, I could edit that file so that I have
ImageableArea Letter/Letter: "28.346 28.346 583.654 763.654"
The next time you go to print, the KDE print dialogue will show the new margins as default.
Hope that helps (and eliminate the need for a bug report).
Apropos Leap 42.3:
- This openSUSE news was posted today: "openSUSE Leap 42.3 End of Life is Extended
" – <https://news.opensuse.org/2018/08/08/opensuse-leap-42-3-end-of-life-is-extended/>.
[HR][/HR]openSUSE News: <https://news.opensuse.org/> – also available as RSS Feed, Tweets, Facebook, Google+ …
@SUSEtoad:
Huh? US Letter is 8½ by 11 inches – how come you’re setting the margins with millimetres? – an often used US Letter page margin is 1 inch: 72 points – 6½ inch line lengths …
- But, you should be adjusting your page margins such that only 65 to 70 (proportional) characters per (US Letter) line are present The Chicago Manual of Style
(I have the 14th edition), section 18.7] – this may mean that, 2 inch (144 points) left and right margins are better suited to your needs …
Hmmm … Thanks!!
I have a Kyocera FS-820 printer – PCL6 only « mistaken purchase … », not the Postscript capable FS-920 – with a corrected PPD but still the default Kyocera margin settings – which don’t take the printable area into account …
*ImageableArea A4/A4: "0 0 595 842"
*ImageableArea Letter/US-Letter: "0 0 612 792
*PaperDimension A4/A4: "595 842"
*PaperDimension Letter/US-Letter: "612 792"
It seems that, I have some maintenance to do – the last change was made during openSUSE 13.1 time – the printer seems to be indestructible – another PPD change is needed … 
Maybe, or, maybe not: US Letter paper is almost impossible to buy here – I’ll see what I can do with some more testing with US Letter sized PDF pages as indicated in my post on the 24th of July …
Your printer might be capable of borderless printing perhaps?
Maybe, or, maybe not: US Letter paper is almost impossible to buy here – I’ll see what I can do with some more testing with US Letter sized PDF pages as indicated in my post on the 24th of July …
I only meant that based on the OPs findings with respect to margin size, it would suffice without a bug report needed from their perspective.
What QT loads from cups for defaults is not used when printing: Loading...
Which references a kde bug:
Defaults to A4 paper, even though ‘US Letter’ is specified in settings: https://bugs.kde.org/show_bug.cgi?id=174354
The last entry says QT 5.11. Tumbleweed is 5.11. Leap 5.9.4.
Note that modern printers CAN NOT print to the edge of the paper there has to be a hardware defined margin that varies from printer model to printer model. The defined printing area normally takes this into account and defines a rectangle into which printing happens. 0 margins may not be good. Also there can be hardware settings on the printer itself that define the paper size and other features.
Also there are 256 mm per inch. The scale used maybe hardware dependent ie Inch/mm But mostly metric is finally becoming the standard
I think that is generally understood. However, not all PPDs reflect actual printer capabilities accurately it would seem.
Also there are 256 mm per inch. The scale used maybe hardware dependent ie Inch/mm But mostly metric is finally becoming the standard
No… ~25.4mm per inch.
Because I live in Canada, where we use the metric system.
Do you need some one from NA to ship you Letter-size paper? Seriously; that’s easy to do.