Cairo-based export not exporting all elements

[Laussy]

In some cases (may be when I merge various elements from various svg files, but I am not sure of what causes it), inkscape does not export the result with "save as", as it appears in inkscape's window, missing many, sometimes most, of the elements.

For instance, the attached svg file gives the following result, if I save as png:

http://laussy.org/download/inkscape/figure.png

when it should be:

http://laussy.org/download/inkscape/wanted_figure.png

as is what appears on the screen. The good image was obtained with 'export as' rather than 'save as'. I have the same problem if I save as pdf, rather than png (my ultimate goal). When it works, the exported pdf is lightweight and of good quality. Converting the pdf through an image however gives ugly and heavy files, so I would prefer exporting directly as pdf. I have encountered this problem on many occasions but cannot figure out what causes it (many times it would export just fine).

I have Inkscape 0.47pre4 r22446 (Oct 15 2009) on kubuntu, installed by apt-get.
I use the extension textext (http://www.elisanet.fi/ptvirtan/software/textext/index.html) v°0.4.1.

Best regards,

F.P.L.

[su_v (suv-lp)]

When you say 'Save as' vs 'Export' - do you mean 'Save as Inkscape SVG' or as 'Cairo PNG'?

Note: 'Cairo PNG' was originally used for testing Cairo-based export and probably should have been removed from the filetype list in the 'Save as' dialog. To obtain good PNG files from your SVG files use 'File > Export Bitmap'.

related discussion in inkscape-devel:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.user/13069>

[su_v (suv-lp)]

reproduced with Inkscape 0.47 and 0.47+devel r9165 on OS X 10.5.8

the export extension 'Cairo PNG' should be either renamed or removed/hidden in the user-visible list for 0.48.

[su_v (suv-lp)]

side note: there are many repeated console messages when opening 'figure.svg' in Inkscape (I have seen them with imported svg or pdf files attached to other bug reports too):

** (inkscape-bin:13794): WARNING **: Called helperfns_read_number with value==null_ptr, this can lead to unexpected behaviour.

[Laussy (fabrice-laussy)]

Dear suv

> When you say 'Save as' vs 'Export' - do you mean 'Save as Inkscape SVG' or as 'Cairo PNG'?

I mean 'Save as' (shift+ctrl+s) then among the various possibilities, choose png, as opposed to 'Export bitmapt' (shift+ctrl+e), which is working fine.

My actual problem is to save as pdf, not png (as I can export bitmap for that). As png looks more robust to me, I thought the essence of the bug could be traced to saving as png. I understand that Cairo is also invoked in the process of saving as pdf. In this case, I see no way around this bug (converting from the bitmap to pdf loose vector format and produce heavy files with reduced quality). Can you suggest something?

Indeed there are lots of '** (inkscape-bin:13794): WARNING **: Called helperfns_read_number with value==null_ptr, this can lead to unexpected behaviour' output.

Best,

Fabrice.

[su_v (suv-lp)]

missing drawing contents in PDF confirmed with Inkscape 0.47 (cairo 1.8.8) and 0.47+devel r9165 (cairo 1.8.10) on OS X 10.5.8

[su_v (suv-lp)]

The console messages disappear after cleaning the <defs> section from many unreferenced clippaths, fonts, perspectives and markers (File > Vacuum Defs) - so that doesn't seem related to the export error.

Export to 'PDF via Cairo' in Inkscape 0.46 with 'Convert texts as paths' checked includes all elements of the drawing -> regression?

[Laussy (fabrice-laussy)]

Interesting... I see no way at all, even after a lot of tweaking, to export a good pdf whenever this problem arises. I tried all combinations of options, including ticking or not "convert texts to paths' (my installation only allows me PDF version 1.4).

The complete figure I'm trying to get as pdf is attached. It has some filling with transparency, an inset (bitmap) and other things. However I removed most of these to get a simpler reproducible problem. Can you export this as pdf as well? If so, what should I do? To downgrade to version 0.46?

[to me this bug's priority is not medium but critical because I see no way around it but exporting massive bitmap and converting brute-force to ugly, unvectorized pdf, which kills most of the point of using inkscape -- and it's rather unpredictable when it will occur].

Thanks for your efforts and insights.

[su_v (suv-lp)]

attaching 'fig1.svg' converted to PDF using Inkscape 0.46: is this output correct?

[Laussy (fabrice-laussy)]

Yes! Thank you very much!

Should I then downgrade to 0.46? (as far as I remember, I had this problem ever since I have been using inkscape, which goes much beyond 0.46, but again, I could never correlate it with anything in particular, may be using textext or merging various svg files together... I used to have a lot of troubles with exporting transparency, which was notoriously badly supported by pdf and not at all by postscript, but it got solved at some point and I think it's unrelated to this present problem).

[su_v (suv-lp)]

I don't know if downgrading to 0.46 would be the answer for other graphs or drawings that fail to export via Cairo. I'm not a developer - just doing bug triage - and couldn't figure out what elements cause this regression or omission when exporting to PDF in 0.47 (and in 0.46 when exporting without converting texts to paths).

Let's wait and see if someone with more knowledge about the current cairo renderer code can pin-point the issue to certain elements (text? svg fonts? polylines? opacity?) and - hopefully - provide a fix that can be included in the next stable release.

[mc^2 (mkoren)]

This is a very serious bug for me.

I attach my example files (see below), maybe it will help. The arrows and the point in the middle are missing on EVERY Cairo-based export - INCLUDING the ones in the older version (0.46) - but before 0.47 then there was the `old` .ps export option which worked well so it didn't hurt that much.

The interesting part is that the very same parts are missing when I open arrow.svg with Eye of GNOME 2.28.1 while only the arrows are missing with GNOME 2.16.0.1 (the x in the middle is there).

This bug practically makes Inkscape 0.47 not usable for me.

Files attached in the archive:
- arrow.svg is the original Inkscape file
- arrow.png is a CORRECT bitmap made by File -> Export Bitmap...
- arrow_cairo.png is the INCORRECT bitmap made by File -> Save a Copy (Save As does the same) with option Cairo PNG.
- arrow_cairo.eps is the file made in the same way & containing the same error as arrow_cairo.png - I could also attach .ps and .pdf - they have the exact same errors (missing parts). Saving in Inkscape 0.46 as .ps with no Cairo does its job well.

I would like to repeat to make myself loud and clear: this DOES NOT look like a regression error to me because i get THE VERY SAME errors using Cairo exports in 0.46.

[su_v (suv-lp)]

@mc^2

I don't know yet why, but your problem with the file arrow.svg is easily solved: there is a line far outside the drawing and page border - when deleting it, all cairo-based exports include all visible elements of the drawing.

The path in question has the id "path12080" and all paths following it (in z-order) are omitted in cairo-based exports.

[su_v (suv-lp)]

(tested and reported problem reproduced with Inkscape 0.47+devel r9607 on OS X 10.5.8)

[su_v (suv-lp)]

It seems that the path in question is corrupt - causing the SVG reference renderer of Inkscape (Batik 1.7.) to render the SVG file the same way as Cairo-based export from Inkscape: up to and no further than object "path12080".

The path as is (visible in outline view mode) can't be properly edited with the node tool - did you manually edit the source or add its transform matrix(1,1,1,1,0,0)? Or remember how it got there?

    <path
       style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mstart);stroke-opacity:1"
       d="M 28.847077,933.4988 L 62.847077,933.4988 L 61.847077,933.4988"
       id="path12080"
       transform="matrix(1,1,1,1,0,0)" />

[mc^2 (mkoren)]

Holy cow! Or should I say: holy gnu!

You're right - that was the source of the problem! Thanks a lot, man.

I certainly haven't edited the source of svg file by hand (I never even looked there - I should have done that to find the error!) and I've got no idea how that path got there. Must have been there for a while cause the roots of this drawing come all the way back to Inkscape in Ubuntu 6.06. :-)

Well, you now have one confirmed source of error, so that's good - I wonder if there is any strange path in Laussy's problem.

Thanks again for your swiftness in finding the solution to my problem!

[su_v (suv-lp)]

Attaching console output from Batik1.7 when opening 'arrow.svg'

[mc^2 (mkoren)]

And I have found the guilty one in Laussy's file:

<text transform="scale(1.06682, 0.937365)" style="font-size: 0px; fill: rgb(0, 0, 0); font-family: Times;" x="583.412" y="706.271" font-size="0px" id="text5338">0.0</text>

If you remove this line from the file figure.svg then the rendering is successful both in EOG and in Cairo exports!

Hope this helps you!

[su_v (suv-lp)]

One question might be, which application created the invalid SVG objects (the diagrams included in Laussy's file appear to have been generated by a tool like gnuplot or similar; not sure about the origins of 'arrow.svg' - LaTeX maybe for the arrows and math symbols?) . The behavior of rendering up to, but not including, the first element which has an error, basically is in accordance with the SVG 1.1 specification:

<http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing>

The other question seems to be: Should Inkscape (and/or Cairo) «provide whatever additional detail it can to enable the user or developer to quickly find the source of the error.»? This is of importance because Inkscape by itself (like other SVG renderers e.g. Firefox) seems to render the affected paths nevertheless (or drop them silently and continue rendering the rest of the file), thus obfuscating the error.

[su_v (suv-lp)]

Removing milestone 0.48 because branching has already happened, unfortunately.

[mc^2 (mkoren)]

arrow.svg is pure Inkscape as far as I can remember - I created the first version of it probably with Inkscape 0.43 though (so many things might have changed from that time).

I think there should be a validator added - finding & perhaps dropping the invalid statements - I'd put it next to or maybe integrate it with File -> Vacuum...

[Laussy (fabrice-laussy)]

Dear ~suv and mc^2:

To answer #19, the data was initially generated by Mathematica (with Export[]) which usually works fine in conjunction with inkscape. A rule of thumb to "predict" when problems of this type might arise is when the svg consists in various exports put together (in the example above, two Mathematica plots were exported--to make the left and right panel--and merged in the same document which I do typically by grab and drop of one in the other).

About #18: how did you find the culprit path? How do you know this is corrupt?

Thanks for your detective work.

[mc^2 (mkoren)]

Brute force, dear Watson :-)

I was deleting lines from the xml until nothing remained in the Eye of GNOME preview (which saved me some time compared to checking the eps all the time) - then I deleted this line and the rest of the picture appeared - only then I noticed it has the font size 0pix which probably is the source of the problem.

[Pau Coma Ramirez (paucoma)]

Hi All,
Thanks to this thread I managed to fix my drawing Save as Pdf

Inkscape 0.48.2 r9819

I imported a circuit wiring diagram in pdf to inkscape with drag and drop.
- ungrouped all elements and made the modifications I wanted to.
- When saving as Svg, no problem, everything was there.
- When Saving as pdf, most of the paths were missing.
- I tried multiple combinations with no luck.
- nor eps, nor ps
- I was about to give up and print the svg opened in google chrome through a pdf printer. (Everything was rendered there)
- I couldn't get the page to fit properly and started scanning through the internet and then stumbled upon your conversation.

My Solution:
- Opened the SVG file in Notepad++
- Searched for "font-size:0"
- found the guilty culprit.
"<!--
    <tspan
         style="font-size:0px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Helvetica;-inkscape-font-specification:Helvetica"
         x="319.59937"
         y="1680.1399"
         sodipodi:role="line"
         id="tspan9134">TM</tspan>
-->
"
- commented it out, saved svg.
- reopened the svg in inkscape and prints all elements.

Thank you

I would suggest that in the next release of inkscape, while printing as pdf the program should scan the svg document for any element with "font-size:0", warn the user that this may cause an incorrect export and add an option for the user to enable auto commenting out.

[Beluga (buovjaga)]

No problem with save as .png of figure.svg

Win 7 64-bit
Inkscape 0.92pre1_64bit r15044

[jazzynico (jazzynico)]

Reproduced on Windows XP (32-bit) with 0.48.5 and 0.91. With 0.91, the drawing doesn't show on the canvas, but the right part is correctly exported.
Not reproduced with 0.92 (see attachment).

[jazzynico (jazzynico)]

Note that the bug was probably due to the Cairo library, recently updated in the win32 devlibs (and already updated some time ago on the other operating systems), and not a direct Inkscape issue.

[Caroline Kloppert (designomoly)]

This is also my worst trial
what is visible in the inkscape design window and what comes out in the png are so different
elements are lost, or resolution is lost, or the file is blank
sometimes its for the strangest things
you didn't resize the window
you did some erasing
you did some drawing with the draw tool
you stitched two drawings together and they are scanned artworks and stitching takes hours and hours

It is creating a png which is the problem in inkscape
it doesn't matter if it is the save as or export function
both fail for inexplicable reasons
the crazy thing is
One day it works, and the next day you do exactly the same thing and it doesn't work

I have to get a png for the POD platform, they will not accept other file types.
I export or save as depending on what functions I've used and it takes me days to get a png sometimes for a particular set of functions, like stitching, tracing, drawing, erasing, cutting out the image to get a transparent background, or punching out parts of the image. Simple things.
I have used many path and object functions for all of these as each online tutorial has different suggestions.

I have been struggling to get png files from 10 am to 15.55 today
trying every combination I can think of. I use save as actually because exporting causes so many problems, but today I've tried both about 150 times.
if you stitch two traces together they will not both appear
if you do some corrections with the drawing tool an almighty snarlup and I abandoned correction
If you try to cut out the image with some punches in it its too much for the whole system it seems.
I am so frustrated I could weep. I'm an artist not a programmer and I've spent 95 % of my time struggling with design bugs. There is no manual that explains if you do X the unfortunate consequence is that when you do Y it will do Z. All the tutorials tell you how the system is intended to be used, and when things go wrong there is nothing to do but puzzle out what you did wrong on your own, if it takes weeks just to find out how to get a png after you have grouped numerous traces. I'm just writing because the waste of time hurts. I'm in pain, I can't take it anymore.