unable to save pdf file withe 0.47, works with 0.46

Not reproduced with Inkscape 0.46+devel r22240 (with cairo 1.8.8) on OS X 10.5.8

'encombrement NL ARBRE NU.svg' opened with Inkscape and saved as PDF (see attached file)
- Displays without error in 'Preview.app', the osx default pdf viewer.
- Default PDF export settings used (with new 'preferences.xml').

Reproduced on Windows Vista, Inkscape rev. 22250, but not with 0.46 and Ubuntu 9.04 (0.46 and 22250).

When I try to save as PDF, I get a popup saying that the file could not be saved, but no console message.
Only happens when the Convert text to path option in NOT checked. If checked, the export takes a long time (there are lots of texts in the file) but works well.

Also affects PS and EPS exports.
Could it be a problem with the cairo version used in the devlibs?

Could be related to bug #271695 “Kerned text embeds too many fonts and blows up the file size in EPS/PS” even though that doesn't result in 'damaged' PDF files.

The text in the dimensions table of the SVG file is positioned inside a <tspan> element containing the complete text of one row at the time, similarly to the examples attached to bug #271695 (e.g. one of the legends for the graphs: <http://launchpadlibrarian.net/33647219/271695-Grafikoni-legend-only.svg>). Exporting these text objects with the cairo-based renderer currently results in too many embedded fonts (on win32 only).

I tried to Save a Copy with by 0.47pre4 (r22130) build on Vista Business 32-bit with the default export settings and got an Inkscape error message: "File C:\Users\user\Documents\test.pdf could not be saved." (It generated the faulty PDF file as reported by the original poster, 89338 bytes long, looking in a text editor like a proper PDF... but only as far as it goes, more at the end of this). Changing the file name didn't help at all. Another SVG file I have made (can't share its contents but it has one tspan, some patterning, an image and a bit more, fairly small and simple overall) worked fine, the PDF it generated was fine (Adobe Reader 9.2).

The devlibs version I used was the latest when I built it (or at least half an hour before I built it), r20 in the modevia SVN repository. I believe that the Inkscape 0.47pre4 build on SourceForge is the one I built.

Further analysis of the faulty generated PDF file:
It has the PDF header, then a compressed stream, then the obj which specifies the size of the compressed stream (number is correct), then nothing else. This I presume is the header, as in the valid PDF file I generated it went on with page definitions, contents, more streams, and all the stuff you'd expect. But the "header" (if such it be) stream was 240 bytes in my other PDF file and 89223 bytes in this broken one.

@Chris - thanks for testing on windows! You used the file 'encombrement NL ARBRE NU.svg' I assume? Could you try the other small sample file <http://launchpadlibrarian.net/33647219/271695-Grafikoni-legend-only.svg> to export to PDF as well? I wonder if that fails to export too (on win32)...

I was using encombrement NL ARBRE NU.svg (though by the time I was using it on Windows it was D%3A%5CJ.D... (just opened the URL directly in Inkscape, one of the great benefits of using the Windows file chooser, you can just download a file into a temp directory and open it as such)).

I just went to close it and got an interesting error. 'The file "[...].svg" was saved with a format (org.inkscape.output.svg.inkscape) that may cause data loss! Do you want to save this file as Inkscape SVG?' It's seeing it as a different format. What version was it originally saved in? I suspect that that may have something to do with the issue.

I'll try saving it again as Inkscape SVG tomorrow or so but I can't do it tonight. I'll also test that other small sample file, ~suv.

Actually I did just squeeze it in then - resaving the big 'un still didn't work (same thing happens), and that sample works fine.

> and that sample works fine
Thanks. That confirms that multiple (absolute) positioning coordinates inside a 'tspan' don't cause the failure of PDF export. Good to know.

> ('encombrement NL ARBRE NU.svg') What version was it originally saved in?
As the bug reporter describes he imported the document as PDF into Inkscape, edited it and saved it as SVG. I don't know which software was originally used to create the PDF.

I don't know how the pdf file "NL..." was originally produced, probably from a dwg file, but I can't be sure.
I often works with pdf files, and I always save them as "Inkscape SVG", in that way, I never received the message "....loss of data"
On other hand, I noticed that the pdf files produced with the version 0.47 are far bigger than thoses produced with 0.46. (I prefer the smaller files when e-mailing them).
So I wonder if this could cause the problem: not enough memory in the computer? too long time to save?
I can't help you more, informatic is like chinese for me

If you get a small broken PDF file it means cairo aborted due to an error. ie cairo_surface_status() returns non zero. The most likely cause is due to a font subsetting failure usually as a result of an unusual or broken font that cairo does not handle well.

Comment 3 indicates that this only occurs when text to paths is disabled (ie font subsetting in cairo is being used) and an error is displayed. It looks like Inkscape is checking the cairo status but unfortunately does not provide any further information such as would be obtained from cairo_status_to_string().

If a small SVG test case can be created or if it can be determined which font is causing the problem I may be able to determine why cairo is failing.

a) font-families used:
LeWitt:bug suv$ grep font-family "431314-encombrement NL ARBRE NU.svg" | wc -l
      72
LeWitt:bug suv$ grep font-family "431314-encombrement NL ARBRE NU.svg" | grep -v -i Arial
         style="font-size:10.07014465px;font-variant:normal;font-weight:bold;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:'TimesNewRoman,Bold'"
LeWitt:bug suv$

no other fonts than these two are referenced in the SVG file failing to export to PDF: Arial, Times New Roman

b) Arial font style settings:
LeWitt:bug suv$ grep font "431314-encombrement NL ARBRE NU.svg" | grep -i Arial | sort | uniq | wc -l
       5
LeWitt:bug suv$ grep font "431314-encombrement NL ARBRE NU.svg" | grep -i Arial | sort | uniq
         style="font-size:4.55529737px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Arial;-inkscape-font-specification:Arial"
         style="font-size:6.9528966px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Arial;-inkscape-font-specification:Arial"
         style="font-size:7.91209602px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Arial;-inkscape-font-specification:Arial"
         style="font-size:7.91209602px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#ff0000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Arial;-inkscape-font-specification:Arial"
       style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Arial;-inkscape-font-specification:Arial"
LeWitt:bug suv$

Can someone from the Bug Team who has access to a win32 installation create a minimal test case that fails to export to PDF?

I am quite sure the problem comes from the size of the file
I re-open the file "NL ARBRE NU.svg", I delete all the data lines (not the grid, not the comments...) except 2 complete lines, includind one line with the small index 1), in order to have all the fonts used in all sizes.
I saved it with inkscape 0.47, a pdf was produced, size 3.08 Mo
I save the file as Inkscape SVG.
then I re- open and I saved it with Inkscape 0.46, a pdf was produced, size 152Ko
both pdf could be reopened with adobe.
hope this could help

reduced testcase (only the first four lines of the dimensions table
contain text) - does this work on win32 to export?
(attached PDF was exported on OS X 10.5.8, cairo 1.8.8)

If the failure is caused by the sheer number of individual characters
that are subsetted/embedded, how can this be verified? In other memory
or performance related reports on win32 platforms (PDF import, big SVG
maps, export to PNG) there are console messages (complaining about too
many heep sections or similiar) or crashes (due to instances of
'std::bad_alloc').

The reduced version produces a 3,842,024 byte PDF file in Windows which works fine.

The reduced file produced a 3.6 MB PDF for me with version 0.47pre4 and winxp.

Incidentally, Primo PDF produced a PDF of 46 KB under either screen or print quality settings. Primo also produced a PDF from the previous file that would not export.

cheers, erik

It would be nice if Inkscape printed the cairo error message in the error dialog. After adding a printf to the code I found that the cairo error is "out of memory".

It looks like the failure is due to cairo trying to reading and subset a huge number of fonts. It appears to be the same bug as bug #271695.

I'm working on a fix for cairo.

Linking as duplicate to bug #271695. Please add a comment and revert the duplicate status if you don't agree and think these are separate issues.

it could be a duplicaten but I don't think so, because :
the bug 271695 appears on Inkscape 0.46,
right now, to convert SVG files in pdf file, I use the version 0;46 which works very well, no problem.
the problem of "oversizing??" is only with version 0.47.
if bugs were identical, problem will be with version 0.46 also
furthermore, the result of the bug 271695 is a very big file, the result of the bug 431314 is...no file
and last but not least, the description of bug is "...some text appears that was not originally in the file..." wich as never been reproduced with bug 431314.

Please read the comments further down in bug #271695 (I know it's long). That bug report has evolved over time: It was reported against an older Inkscape version, yes. However the reporter of that bug himself confirmed the initial issue as solved ("This problem does not appear in revision 19870") and then went on to describe even more serious issues with current development builds (<https://bugs.launchpad.net/inkscape/+bug/271695/comments/5>) and the new default (embed all fonts) that comes with the switch to the cairo renderer for EPS/PS/PDF export.

attached the original document saved in win32 using patch #54 from https://bugs.launchpad.net/inkscape/+bug/271695

theAdib.