Landscape PostScript output prints incorrectly

[Adrian Johnson]

When saving a landscape svg as PostScript (using Save As) then printing the PostScript file, it does not print correctly. The landscape drawing is incorrectly oriented on the paper with 1/3 of the drawing chopped off.

The reason for this is that when generating landscape PostScript, a portrait page size needs to be used and then the drawing rotated 90 degrees counterclockwise to fit onto the portrait page. This is because portable PostScript does not contain the page size or orientation (DSC comments are ignored by printers). Creating a PostScript file where the width is greater than the height does not print correctly because the printer will render it onto a portrait page.

I've placed some information on the cairo wiki describing how to print landscape:
http://www.cairographics.org/documentation/using_the_postscript_surface/

The PageOrientation DSC comment should also be used to tell viewers such as gv and evince the orientation of the document.

Note that printing via the print menu works fine as gtkprint rotates the cairo context when landscape is selected.

[Adrian Johnson (ajohnson-redneon)]

This is the SVG file I used to generate the PostScript output.

[Adrian Johnson (ajohnson-redneon)]

This is the PostScript output from the above test case created using the Save As menu.

While it renders correctly with viewers such as gv or evince, printing this file does not work. It is rotated 90 degrees from its correct position on the page.

[Adrian Johnson (ajohnson-redneon)]

This patch fixes this bug. If the page is landscape (ie width > height), it creates the cairo postscript surface with (height, width) then rotates the cairo context 90 degrees so the the transformed surface has dimensions (width, height) but will be rotated when printed so it will be correctly oriented on the paper. Note that this transformation should not be applied to EPS files otherwise the EPS drawing will be rotated when imported.

The patch also adds the PageOrientation DSC comment so that viewers will display the page correctly even though it has been rotated 90 degrees.

[Adrian Johnson (ajohnson-redneon)]

This the PostScript output from the above test case after applying the above patch. It prints correctly and displays correctly in gv and evince.

[Adrian Johnson (ajohnson-redneon)]

A trivial fix I spotted while working in this function. The cairo version #ifdef incorrectly wraps the cairo_surface_status() function. Only the cairo_surface_ps_restrict_to() and cairo_surface_ps_set_eps() needs the version specific check.

[su_v (suv-lp)]

patch 0001 + 0002 tested with Inkscape 0.46+devel r22312 on OS X 10.5.8
file used: test page attached to bug #166678 (comment #30)
<http://launchpadlibrarian.net/30363086/printtest-landscape-LeWitt-2.svg>

1) fix confirmed: output to PS now respects the page orientation set in Inkscape document properties.

2) related question: the document format though seems disregarded or lost both when
- Print to File (Postscript) via print dialog
- Save as "PostScript (*.ps)"
When I view the PostScript files with 'Preview.app' (OS X PS/PDF viewer), gv or gs (ImageMagick 'display'):
the print format is set to 'US letter' instead keeping 'A4'

The default PS export settings of Inkscape have these options checked:
- export area is drawing
- export area is page
Could you share some insight what the influence of these settings on the PS document format should be - or more specifically: how can I retain the Inkscape document format (i.e. drawing + margins + page size in above used test file) for the exported PS file? Or do I have to use PDF to keep the page format settings?

[ScislaC (scislac)]

Patch committed in r22314. Thanks Adrian!

[Adrian Johnson (ajohnson-redneon)]

~suv wrote:
> 2) related question: the document format though seems disregarded or lost both when
> - Print to File (Postscript) via print dialog
> - Save as "PostScript (*.ps)"
> When I view the PostScript files with 'Preview.app' (OS X PS/PDF viewer), gv or gs (ImageMagick 'display'):
> the print format is set to 'US letter' instead keeping 'A4'
>
> The default PS export settings of Inkscape have these options checked:
> - export area is drawing
> - export area is page
> Could you share some insight what the influence of these settings on the PS document format should be - or more specifically:
> how can I retain the Inkscape document format (i.e. drawing + margins + page size in above used test file) for the exported PS
> file?

When using a PS viewer the DSC comments provide additional information such as page size, begin/end of each page so the document can be navigated.

The DSC specification is at:
http://www.adobe.com/devnet/postscript/pdfs/5001.DSC_Spec.pdf

The DSC comments that the provide page size and drawing area are:

%%DocumentMedia (p55)
%%PageMedia (p78)
%%BoundingBox (p39)
%%PageBoundingBox (p53)

DocumentMedia provides a list of page sizes used in the document. PageMedia specifies the page size for the current page.

PageBoundingBox specifies the smallest rectangle that encloses the printed marks on the page (ie the drawing area). See the diagram on page 39. BoundingBox is the smallest rectangle that encloses the printed marks on every page.

Cairo 1.8.8 does not emit the DocumentMedia/PageMedia comments. I've recently updated cairo git to emit these comments. Cairo currently sets the bounding box of PS output to the page size due to bugs in some viewers that are only using the BoundingBox as the page size.

Setting the bounding box to the page size does not matter much for PS files but for EPS files it is important that the bounding box is set correctly. See for example the problems with importing EPS into latex if the BBox is incorrectly set to the page size:

http://tex.loria.fr/graph-pack/grf/grf.htm#Q1-1-14

Cairo always sets the correct BoundingBox for EPS files.

I'm attaching a test file I use for testing PS viewer handling of page size/bounding box size. It has 3 pages. Two are A4 (portrait and landscape), and one is A5. Some viewers may display the DocumentMedia labels used in this test file which are "a4" and "a5".

Could you attach your PS file that is displayed as Letter in Preview so I can see if there is any obvious reason why Letter is selected.

> Or do I have to use PDF to keep the page format settings?

PDF is the more capable format and in the longer term all PS workflows are switching to PDF.

[su_v (suv-lp)]

Thank you for your detailed answer! I tested your attached
'bbox-test.ps' file with 'Preview.app' and 'gv' (GhostView port from
MacPorts).

a) The error seems to be on Apple's side when converting PostScript to
PDF on-the-fly to load it in 'Preview.app': all pages of your test file
are cut off at the top and the page format is reported as '21.59 × 27.94
cm' for all pages (after the conversion to PDF).

b) Ghostview (gv 3.6.7, gs 8.70) renders all pages of 'bbox-test.ps'
with correct margins and page formats.

I redid my previous tests with the file mentioned in comment #6
<http://launchpadlibrarian.net/30363086/printtest-landscape-LeWitt-2.svg>,
attached are PS exports from Inkscape using all combinations of page and
drawing export options.

All PostScript files are displayed with document format US Letter in
'Preview.app' (after conversion to PDF):

1) the content (drawing) is aligned bottom/left,
   Page size: 21.59 × 27.94 cm
printtest-landscape-LeWitt-2+drawing.ps
printtest-landscape-LeWitt-2+drawing+page.ps

2) the margin between drawing and page is correct,
   but the content gets cut off at the top.
   Page size: 21.59 × 27.94 cm
printtest-landscape-LeWitt-2.ps
printtest-landscape-LeWitt-2+page.ps

'gv' displays them correctly. +drawing (bbox) overrides +page, both off
defaults to +page.

It seems that I did not verify my previous export results thoroughly
enough (comment #6). It is only Preview.app that assumes a wrong page
format.

[bbyak (buliabyak)]

For me this is an unfortunate change. I use Inkscape to generate PostScript that is used by another program, not for print. That program ignores DSC, and as a result half of my files are suddenly rotated. Can we limit this change to printing only, and let --export-ps and Save As PS work as before, i.e. avoid any unexpected rotations?

[Adrian Johnson (ajohnson-redneon)]

While reverting the change will correct your problem it is going to break landscape printing to a real printer for Inkscape generated from scripts or created from the Save As dialog for later sending to a printer. I would suggest adding an "autorotate" option to the PS Save dialog (like the one in the acroread print dialog) and equivalent command line option.

Have you filed a bug with your application for not correctly handling DSC orientation comments?

[su_v (suv-lp)]

In this recent report another export format is affected: Bug #466479 “AutoCAD R12 DXF export rotates drawing by 90 degrees”
<https://bugs.launchpad.net/inkscape/+bug/466479>

Maybe bug #476059 “Can't print properly on OS X 10.6.1” is related as well (0.47pre4).

[bbyak (buliabyak)]

Adding an option is possible as a last resort, but it's something we should avoid if possible.

In general, this change strikes me as strange. It rotates output on assumption that the paper we print on is portrait. What if it is not? What if the output needs to be scaled to fit even if rotated? Obviously these decisions should be taken by the user, using a dialog with a preview that uses the actual paper settings received from the printer.

And we already have such dialog via File > Print, even with preview. And moreover, now that I reread your report more closely, I see that that dialog already does the right thing:

> Note that printing via the print menu works fine as gtkprint rotates the cairo context when landscape is selected.

That dialogs really needs improvement - I want to see exactly how my output will fit on the page, with margins and all - but anyway, it gives basic control which should be sufficient, and as you admit it solves the autorotation problem.

So, who is this patch for? Only for those who export PS and then print it outside of Inkscape? Why should we decide for them what is better for them? It is much faster and more wholesome to print via File > Print, if print is what you need. And if you export, Inkscape should just assume that you want as close a copy of the document as target format allows, WITHOUT assuming anything about printing this file or any other use of it.

Also, in my experience, it is quite common for software to ignore DSC comments in PS (unlike EPS where almost everyone looks into DSC for the bounding box). Pure PS is often interpreted simply per Adobe's old references, without DSC and other later extensions. And this makes sense, because PS interpreters are often embedded in hardware where it is hard to upgrade (even your patch assumes that all printers ignore DSC - by they way, are you sure of that?), and is itself a pretty much fixed and dead-end format that hasn't been upgraded for many years. So, I think making correct rendering of PS dependent on DSC support is wrong.

So, on reflection, I vote to back out this patch completely. Any other opinions? Anything I'm missing?

[Alvin Penner (apenner)]

I would like to see .ps and .eps behave the same regardless of what that behaviour is. I don't think that users should be asked to understand the difference between them.

[bbyak (buliabyak)]

Adrian: by the way, the reason I'm using PS and not EPS to feed to that program is because there's no way for EPS to have bounding box of the SVG page, if the content is smaller. It always contracts the bbox to the actual content. I think it was you who I discussed this with, and you claimed that this is in accordance with the spec. This seemed and still seems strange to me (though I can't argue because I didn't read the spec all that closely), but I just worked around this by switching to PS. Until now that worked fine :)

[su_v (suv-lp)]

possibly related recent comments regarding EPS bbox calculation:
Bug #186182 in Inkscape: “Bounding box too small in EPS export”:
<https://bugs.launchpad.net/inkscape/+bug/186182>

[Adrian Johnson (ajohnson-redneon)]

As we a so close to a release and it has caused regressions for some people, I have no objections to reverting to patch.

[ScislaC (scislac)]

Sometimes being a release warden is no fun... :) I will revert over the weekend unless there seems to be a happy solution before then.

[bbyak (buliabyak)]

I reverted it myself in rev 22561.

[su_v (suv-lp)]

Setting the status of this report and the dependent bug #466479 "AutoCAD R12 DXF export rotates drawing by 90 degrees" to 'In progress' as the discussion needs to continue once 0.47 has branched and the trunk is re-opened.

@Adrian - the other bug I had mentioned (bug #476059 <https://bugs.launchpad.net/bugs/476059>) was solved by installing Gutenprint drivers for the Canon Pixus 860i, provided and recommended by Apple in case of printing problems: «You can also use the Gutenprint software if it seems that the printer’s software isn’t working properly.»

[tatankam (tatankam)]

How to apply the fix to windows?

[tatankam (tatankam)]

How to apply the patch to windows ?

Thanks

[tatankam (tatankam)]

any news about this problem?
Thanks.

[ScislaC (scislac)]

Adrian: Is this still "in progress"?

[Adrian Johnson (ajohnson-redneon)]

ScislaC: No.

[su_v (suv-lp)]

Related new report:
Bug #1052705 'Postscript "save as" orientation rotated from drawing surface'
<https://bugs.launchpad.net/inkscape/+bug/1052705>