Export to PS/EPS/PDF of 'object' per id ignores viewBox
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Invalid
|
Undecided
|
Unassigned |
Bug Description
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-
Bug #1155036 “Reversed Output when limiting export on selected Objects”
This is particularly critical in 0.92.2pre0, because the viewbox is not in pt anymore.