Summary: Wrong margins especially when printing one page
Submitted by: yavor
Submitted on: Fri 13 Jul 2018 06:45:26 PM EEST
Severity: 3 - Normal
Item Group: Bug
Assigned to: None
Discussion Lock: Any
2. In NSPageLayout -tableView:objectValueForTableColumn:row: the margins for
the standard papers are not correctly computed. imageRect already has the
printable margins but that is not taken into account so an expression like
paperSize.height - imageRect.size.height makes the topMargin twice larger than
it should be. Likewise for rightMargin. Also, the result is actually in pts
which gives funny figures; it should be converted to cm/in.
3. In NSPrintInfo -initWithDictionary: the margins should be set according to
ImageableArea as the FIXME comment says.
4. When a page with short text (few lines) has to be printed, the text does
not appear at the top of the page, as is expected, but is shifted way down
below. That's the most annoying item. There are some changes by Greg in the
"printing_fixes" branch which I think are related. I haven't tested them but
IMHO his approach is wrong and breaks printing of multiple pages (which
appears to be working correctly right now).
The attached patch fixes all 4 issues for me although I admit I'm not sure
whether it is correct. The whole repagination logic seems way too
awkward/convoluted to me and breaks reasonable WYSIWYG expectations.
thank you for this bug report and the patch. I already had some similar
changes to NSPrinter implemented after the discussion on the mailing list.
That should be similar to your code but tries to unify different code paths.
As for NSPageLayout clearly the conversion was missing. I didn't like the way
you set the margins on both sides to the same values. So I just added the
I also tried to add the same logic to the NSPrintInfo code.
Now with the NSPrintOperations change I understand which case you try to fix.
But the patch would break scaling and a lot of other stuff. And it does not
address the real issue here, just tries to work around in one special case. I
will try to experiment with the printing code a bit and see whether I can come
up woth something better.
This only applies the following translation when the printed rectangle is
empty. If I remove the last part of the test, a single page print gets
positioned correctly. The question now is, why was this restriction here in
the first place and will it have any negative results on other printing
It really would help here, if you could do some experiments on your side as
well. First to confirm whether this resolves the specific issue and next on
negative side effects.
The last part of the test was removed by Eric Wasylishen on 23 December 2011
(commit d374f0a) precisely because of this problem. However, he reverted it
one hour later (commit 2f0f50c) with a comment that it broke Graphos
I have a CUPS server with two different printers configured. I can confirm
that with this change printing a single page works correctly for me with Ink,
TextEdit and Graphos. I don't know what Graphos breakage he had in mind back
then, perhaps he will remember? Or we can ask Riccardo to test as he is
undoubtedly more familiar with Graphos.
The check was originally introduced by Gregory Casamento on 13 Mar 2009. But
I don't expect that either of them (Eric and Greg) are following our
discussion here. Nor would they probably remember what they where doing back
then. We may have to figure this out ourselves :-(
If your try this change, please also do some multi page tests. I am almost
sure it will improve the single page case but we also need to inspect other
I just committed the change to remove this is empty check before the
translation. This should correct the behaviour for half filled pages. There
surely are a lot more printing issues in GNUstep but the ones referenced in
this report should be fixed by this.