View Issue Details
|Fixed in Version
|0015778: Margins read from printer driver are wrong in landscape mode
|I set the properties to Letter, Landscape and my HP OfficeJet Pro K8600.
This printer with Word set in this configuration has physical margins as
- Top 3.3 mm
- Bottom 3.4 mm
- Left 11.9 mm
- Right 3.4 mm
Word and many other applications also report the same settings and print properly
Scibus with the same settings as Letter, Landscape and K8600 says,
- Top 3.302 mm
- Bottom 11.94 mm
- Left 3.302 mm
- Right 3.302 mm
In word, the large margin is visually on the left of the page. In Scribus the large margin is visually on the bottom of the page.
Scribus is wrong, as the real physical margin as the paper comes through this duplex capable printer is on the left.
So, some calculation in Scribus appears to be off.
Interestingly, when units is mm, Guides appear to be equal all the way around the page but when in inches, the bad offset is visible.
|No tags attached.
|This image illustrates the problem
|This is what the Margins should look like
i've never used that dialog and i wonder a bit what is its use case.
why is scribus detecting the printer margins at all?
on the one side, on most systems scribus is bad at printing.
on the other side, scribus is made for creating PDFs (that you will send to a print shop for printing) not for direct printing. so there are very few chances that the user will have the final printer attached to her computer are very slim... so why should use the margins from the wrong printer?
in desktop publishing, the user is in charge of setting the margins according to the client's wishes and to the production printer's characteristics.
How can you set accurate print margins without that dialog?
On Windows 10, in my experimentation, it appears that the values chosen by the application avry by what the default printer is and the target output. I'm sure there is some meaning to this but it does appear to be random, though repeatable.
All printers have different physical margins, they must, as they have to handle the paper or other media they print on. So, it is important that when the user wants to maximize the use of the output media, they need to be able to accurately define where the real physical margins of the printer are. If the program is incapable of accurately retrieving the margins from the printer driver and then accurately and properly dealing with the handling of that data, then obviously, even if you artificially set margins with some arbitrary number entry in the margin dialog, you cannot begin to trust the resultant output to be accurate, no matter what you are going to print on.
I guess that could be considered rather telling in that I can get superior output from Microsoft Word 2010 and LibreOffice as they both properly handle margins.
@Rtomkins the computer where i use scribus almost never has access to the printer where the document will finally be printed.
most of the time, i have three types of margins: 1 cm for documents that should be printed on any printer (available on the internet), "0 cm" for documents with bleeds; 5 mm for document that need thin margins (if i know that the printer supports them).
the bug seems to have been fixed, but i still see little interest in this feature.
imo it encourages bad workflows and makes the users unhappy in the long term.
|File Added: ScribusWrong1.jpg
|File Added: ScribusWrongMargins.jpg
|File Added: ScribusWrong2.jpg
|Note Added: 0046480
|File Added: WordGood.jpg
|Note Added: 0046481
|Note Added: 0046482
|Margins read from printer driver are wrong => Margins read from printer driver are wrong in landscape mode
|new => resolved
|open => fixed
|Fixed in Version
|major => minor
|Note Added: 0046491
|Note Added: 0046492
|high => normal
|resolved => closed