0.47pre3: unwanted cropping on PDF export

for those who want to have a look at the svg file (source) directly…

Firefox renders the SVG like the PDF output - the 'cropping' could be the result of a remnant page size of the imported (now nested) original svg document 'problem-zones-background.svg'?

…the PNG is identical to the rendering on-canvas in Inkscape.

(tested with Inkscape 0.46+devel r22514 on OS X 10.5.8)

>Firefox renders the SVG like the PDF output - the 'cropping' could be the result of a remnant page size of the imported (now >nested) original svg document 'problem-zones-background.svg'?

May be.
Which attribute/element can cause this?

BTW, v0.46 export PDF without cropping (see attachement).

cropped:
- Batik 1.7
- Firefox 3.5.3
- PDF exported from 0.47pre with Cairo 1.8.6 and 1.8.8

uncropped:
- Inkscape 0.46 on canvas
- PDF exported from 0.46 with Cairo 1.5.15
- Inkscape 0.47pre3 on canvas
- Bitmap exported from Inkscape 0.47pre3

> Which attribute/element can cause this?
I don't know yet - it was just the first thing that catched my eye when looking at the SVG source.

How did you create the document? The exported PDF seems cropped to the proportions of the 'viewBox' attribute (portrait) which is different from the page size (landscape, width and height attributes).

Hmm, who and why inserts «viewBox="0 0 29700 21000"» on root svg tag, I do not know, I think only inscape can do this.
But all seems OK with Inkscape 0.46.

Thank you, this is probably this SVG-document problem, not Inkscape.

But may be you know how easy fix such documents, without manual editing on Inkscape?
(I have a lot with this incorrect «viewBox»…)
removing «viewBox="0 0 29700 21000"» or replacing it to «viewBox="0 0 21000 29700"» unfortunately do not work.

> who and why inserts «viewBox="0 0 29700 21000"
Inkscape doesn't insert it, but it is often requested as feature because it allows re-sizable SVG (e.g. for embedding in web pages - see the blueprint <https://blueprints.launchpad.net/inkscape/+spec/allow-browser-resizing>)

> how easy fix such documents, without manual editing on Inkscape?
That's why I asked how you created the document. There are elements in it that Inkscape doesn't do itself - like viewBox or font embedding - and hints that this is part of a presention (Master slide). The viewBox is combined with 'transform=matrix(…)' attributes to and inside the second viewport (svg) element and not easily undone by deleting it (I had tried - as you - in the XML Editor to reduce the document to the three essential paths (ellipses) with mixed results).

related links:
ViewBoxToDo - Inkscape Wiki:
<http://wiki.inkscape.org/wiki/index.php/ViewBoxToDo>
BlueprintRealUnit - Inkscape Wiki:
<http://wiki.inkscape.org/wiki/index.php/BlueprintRealUnit>
Release notes/0.47 - Inkscape Wiki: Notable bug fixes
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Notable_bug_fixes>
SVG 1.1 - Coordinate Systems, Transformations and Units
<http://www.w3.org/TR/SVG11/coords.html>

I am no SVG export myself - maybe one of the devs can comment… (speleo3 ? ;-)

> Hmm, who and why inserts «viewBox="0 0 29700 21000"» on root svg tag,
> I do not know, I think only inscape can do this.

Still wondering about this - do you use a custom default template that includes the viewBox and embedded fonts into every new document you create with Inkscape?

No...
I just fork/branch/copy-paste some SVG-files, and now I have dozens of SVG-documents (A4 landscape), tainted with this «viewBox="0 0 29700 21000"».

But first "cursed" SVG (attached) seems also created by Inkscape (as I remember).

Sorry, for disturbance, the bug can be closed.

Apparently, I have to fix all my cursed SVGs by hands-and-eyes…

> But first "cursed" SVG (attached) seems also created by Inkscape (as I remember).
I doubt that looking at the source:

- embed fonts
- multiple <defs>
- elements like:
  <g
     visibility="visible"
     id="Default">
    <desc
       id="desc197">Master slide</desc>
  </g>

are not created by Inkscape (even if it was last edited with Inkscape 0.45). OTOH Inkscape tries to respect attributes like 'viewBox' and doesn't remove them when encountered. IMHO even 'zones.svg' originated from another application.

The bug with Inkscape (if any) is that it doesn't use 'viewBox' to render the SVG content on canvas. PDF export however seems to respect that - as do other SVG viewers like Batik 1.7 and Firefox 3.5.3.

>I doubt that looking at the source
May be the image was originaly exported from OpenOffice Impress,
may be ->EMF->SVG.

Sorry, I do not remember…

>The bug with Inkscape (if any) is that it doesn't use 'viewBox' to render the SVG content on canvas.
Yes, all render engines must be coherent

Setting to 'Confirmed' as the unexpected cropping of the drawing in exported PDF files is reproducible. Maybe one of the developers with insight into the current handling of 'viewBox' in Inkscape can clarify the bug status and importance (be it 'Confirmed'|'Won't Fix' or 'Wishlist').

Unwanted cropping on PDF export exists on version 0.47 (without any "viewbox attribute"-case).

Sample files attached.

source.svg - Source file
source-in-firefox.png - Source file in "independent" SVG viewer (Firefox)
exported-by-46.pdf - PDF exported by Inkscape v4.6 (OK)
exported-by-47.pdf - PDF exported by Inkscape v4.7 (Bad)

> unwanted-cropping-in-v47.zip

This is caused by a nested <svg> element which is not fully supported by Inkscape. Did you paste an SVG file manually into the 'source.svg' using external tools like a text editor? Nesting of <svg> nodes like this does not happen when I import the SVG file using Inkscape's Import dialog.

Cause of the incorrect PDF export:
Bug #168069 “incorrect bounding box for nested svg elements”

Exporting source.svg with Inkscape0.47 using page (--export-area-page) instead of drawing (--export-area-drawing) works correctly.

>Did you paste an SVG file manually into the 'source.svg' using
>external tools like a text editor?
Actually yes.
It is automatically generated files (I wrote small framework for supporting "composite" SVG-images).

>This is caused by a nested <svg> element which is not fully supported by Inkscape.
Very pity. All was OK with version 0.46...