Export to PS/EPS/PDF of 'object' per id ignores viewBox

[su_v]

Inkscape's cairo-based export of object per id ignores the information from the viewBox of the current document for the export of the 'object' (and any objects contained within). The size of the exported area though (%%DocumentMedia, %%BoundingBox in the PostScript file, MediaBox in the PDF file) is based on correctly calculated absolute unit lengths as expected.

Observed symptoms:
* unexpected scaling of 'object' if uu ≠ CSS Pixels (ui/units.xml)
* unexpected scaling of 'object' if internal dpi (i.e. length of CSS Pixel) differ between creator and exporter (inkscape version)
* some cases may produce an invalid %%BoundingBox in the PostScript file (%%DocumentMedia still ok), or an empty PDF file.

Steps to reproduce:
===================
1) create two documents from template (use 0.91+devel!):
   A: page format A4, user unit mm (default template)
   B: page format A4, user unit px (template 'default px')

In each document:
2) add objects of the same size relative to the page
3) group them and note the id of the group ('Shift+Ctrl+O')
4) save a copy as PS (or PDF) with:
   [x] use exported object's size
   Limit export to the object with ID: __enter noted id here__

Result:
=======
*) A, B: Both generated PostScript files have a correct and identical page format (%%DocumentMedia) and %%BoundingBox, but the size of the object(s) differs: the file generated from case A has wrongly scaled objects.
*) C: PostScript file does have an invalid %%BoundingBox ("%%BoundingBox: 0 232 0 233"), the generated PDF file renders empty.

System:
=======
Reproduced with attached test cases on OS X 10.7.5 using
- Inkscape 0.91+devel r13857
- Inkscape 0.91pre3, Inkscape 0.48.5

Notes:
======
1) The reported issue affects PostScript as well as PDF export of an object per id.

2) The attached SVG files have been created with trunk, i.e. the viewBox is set correctly to define the scalefactor of the SVG user units. The bug is not a regression in trunk (0.91+devel) as such, but more obvious there because the default template uses a drawing scale other than CSS Pixels (“uu = mm”) - any cairo-based exports of an object per id in documents based on the default template in trunk will be affected.

3) The reported issue also affects files with 'px'-based user units, if the internal resolution of the exporting Inkscape build doesn't match the internal resolution of the version which originally created the file. Even though the files render and measure as expected on-canvas if viewBox and page width/height are defined correctly, the cairo-based export of an object by id ignores the viewBox information and exports objects at the "wrong" scale (note that the page size of the output document is still correct).

4) The reported issue does not affect cairo-based exports based on page area, or on drawing content (in 0.91 now labeled "use exported object's size", but without specifying an object's id)

Attachments:
============
A: a4-mm-test1.svg
B: a4-px-test1.svg
C: test5_mm.svg (invalid PostScript output, empty PDF)

Possibly related earlier reports:
=================================
Bug #743987 “export-id with export-pdf/export-eps/export-ps wrong bbox”
Bug #1155036 “Reversed Output when limiting export on selected Objects”

[Nicolas Gama (gama-nicolas)]

This is particularly critical in 0.92.2pre0, because the viewbox is not in pt anymore.

[Nicolas Gama (gama-nicolas)]

and now, it also affect exporting to png.

[Jonathan Hofinger (jhofinger)]

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.

Moved to: https://gitlab.com/inkscape/inbox/issues/2249
Closed by: https://gitlab.com/jhofinger