invalid eps file created from null/empty svg file, crash in current trunk

Bug #882167 reported by Alan Post
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Invalid
High
Unassigned

Bug Description

I'm running OpenBSD 4.9 on x86. I'm using inkscape version 'Inkscape 0.48.0 r9654 (Feb 17 2011)'. I've generated the following svg file:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
 "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg version="1.0" xmlns="http://www.w3.org/2000/svg" width="0" height="0">
<metadata>M0x0</metadata>

Using a program called SignPuddle. This file is my empty/null image file, when I don't have an image--I want in this to generate a blank .svg which I then convert to a blank .eps. I run inkscape using the following command-line:

inkscape -f nil.svg -E nil.eps

The following .eps file is generated:

%!PS-Adobe-3.0 EPSF-3.0
%%Creator: cairo 1.10.2 (http://cairographics.org)
%%CreationDate: Wed Oct 26 09:41:00 2011
%%Pages: 1
%%BoundingBox: 0 -2147483648 0 -2147483648
%%DocumentData: Clean7Bit
%%LanguageLevel: 2
%%EndComments
%%BeginProlog
/cairo_eps_state save def
/dict_count countdictstack def
/op_count count 1 sub def
userdict begin
/q { gsave } bind def
/Q { grestore } bind def
/cm { 6 array astore concat } bind def
/w { setlinewidth } bind def
/J { setlinecap } bind def
/j { setlinejoin } bind def
/M { setmiterlimit } bind def
/d { setdash } bind def
/m { moveto } bind def
/l { lineto } bind def
/c { curveto } bind def
/h { closepath } bind def
/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto
      0 exch rlineto 0 rlineto closepath } bind def
/S { stroke } bind def
/f { fill } bind def
/f* { eofill } bind def
/n { newpath } bind def
/W { clip } bind def
/W* { eoclip } bind def
/BT { } bind def
/ET { } bind def
/pdfmark where { pop globaldict /?pdfmark /exec load put }
    { globaldict begin /?pdfmark /pop load def /pdfmark
    /cleartomark load def end } ifelse
/BDC { mark 3 1 roll /BDC pdfmark } bind def
/EMC { mark /EMC pdfmark } bind def
/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def
/Tj { show currentpoint cairo_store_point } bind def
/TJ {
  {
    dup
    type /stringtype eq
    { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse
  } forall
  currentpoint cairo_store_point
} bind def
/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore
    cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def
/Tf { pop /cairo_font exch def /cairo_font_matrix where
      { pop cairo_selectfont } if } bind def
/Td { matrix translate cairo_font_matrix matrix concatmatrix dup
      /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point
      /cairo_font where { pop cairo_selectfont } if } bind def
/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def
      cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def
/g { setgray } bind def
/rg { setrgbcolor } bind def
/d1 { setcachedevice } bind def
%%EndProlog
%%Page: 1 1
%%BeginPageSetup
%%PageBoundingBox: 0 -2147483648 0 -2147483648
%%EndPageSetup
q 0 -2147483648 0 0 rectclip q
Q
showpage
%%Trailer
count op_count sub {pop} repeat
countdictstack dict_count sub {end} repeat
cairo_eps_state restore
%%EOF

I believe the Bounding Box line:

%%BoundingBox: 0 -2147483648 0 -2147483648

Is incorrect, though I don't know enough about .eps to confirm. When I try to include this file in a resulting TeX document, I get the following error (from the epsf.tex package):

! Number too big.
\epsfury ->-2147483648

I was expecting to have a document with a blank/null/empty image, rather than the above error.

su_v (suv-lp)
tags: added: cairo exporting
removed: svg
Revision history for this message
su_v (suv-lp) wrote :

> invalid eps file created from null/empty svg file

Neither gs (Ghostscript 9.04) nor evince nor Apple's Preview.app complain about an invalid EPS file when opeing such an empty EPS file generated by Inskcape: they all display an empty EPS file. Could this be a limitation of the epsf.tex package?

(your pasted SVG code is broken, btw - it lacks the closing tag for <svg>).

Revision history for this message
su_v (suv-lp) wrote :

AFAIK the bbox line in the EPS file:
> %%BoundingBox: 0 -2147483648 0 -2147483648
is generated by the (external) cairo library used in Inkscape 0.48.x for PDF/EPS/PS export.

Revision history for this message
su_v (suv-lp) wrote :

Current trunk (r10696) fails to export such an 'empty' SVG file - backtrace from gdb:

(gdb) r -f 882167-nil-closed.svg -E 882167-nil-closed-r10696-gdb.eps
Starting program: /Volumes/green/mp-inkscape/src/inkscape-trunk/Build/bin/inkscape -f 882167-nil-closed.svg -E 882167-nil-closed-r10696-gdb.eps

(…)

** Message: CairoRenderer: empty bounding box.
terminate called after throwing an instance of 'Inkscape::Extension::Output::save_failed'

Program received signal SIGABRT, Aborted.
0x95087d52 in __kill ()
(gdb) bt
#0 0x95087d52 in __kill ()
#1 0x95087d44 in kill$UNIX2003 ()
#2 0x950fa242 in raise ()
#3 0x95106681 in abort ()
#4 0x97154005 in __gnu_cxx::__verbose_terminate_handler ()
#5 0x9715210c in __gxx_personality_v0 ()
#6 0x9715214b in std::terminate ()
#7 0x97152261 in __cxa_throw ()
#8 0x0032dee5 in Inkscape::Extension::Output::save (this=0x45465f0, doc=0x5f4bf60, filename=0x4544080 "882167-nil-closed-r10696-gdb.eps") at extension/output.cpp:221
#9 0x00004aa9 in do_export_ps_pdf (doc=0x5f4bf60, uri=0x4544080 "882167-nil-closed-r10696-gdb.eps", mime=0x9f72b6 "image/x-e-postscript") at main.cpp:1565
#10 0x000067c6 in sp_process_file_list (fl=0x44201c0) at main.cpp:1043
#11 0x00007466 in sp_main_console (argc=5, argv=0xbffff008) at main.cpp:1168
#12 0x000081b5 in main (argc=5, argv=0xbffff008) at main.cpp:711
(gdb)

Revision history for this message
su_v (suv-lp) wrote :

If opening the 'empty' zero-sized SVG file with the GUI, Inkscape 0.48.x and current trunk (r10696) both save an EPS file with this bounding box:

  %%BoundingBox: 0 841 0 842

as opposed to

  %%BoundingBox: 0 -2147483648 0 -2147483648

generated by Inkscape 0.48.x on the command line (the command line conversion fails in current trunk).

-> confirming bug in Inkscape: the results of using the command line or the GUI to export to EPS should be consistent (either fail both, or result in identical files).

Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
su_v (suv-lp) wrote :
Revision history for this message
Alan Post (alanpost) wrote :

I've engaged the author of the software that is generated my SVG file:

http://listserv.linguistlist.org/cgi-bin/wa?A2=ind1110D&L=SW-L&F=&S=&P=14857

It appears the file being generated by my local installation of his software is different that what is current online. I've switched to using the online service until I get a software refresh, and I note his latest version sets a non-zero width and height.

Revision history for this message
Alan Post (alanpost) wrote :

It appears also the final </svg> line was not being generated because of a bug in another program/library:

https://bugs.call-cc.org/ticket/721

Revision history for this message
Alan Post (alanpost) wrote :

Summarizing my activity:

The missing </svg> line resulted because of a copy-and-paste error: the file I retrieved online ends with a linefeed, and my terminal did not show the last line when I ran it through cat, so it didn't get included in my copy&paste. The actual processing pipeline doesn't use a terminal, and isn't affected by this problem: it seems the final </svg> line. To be sure, I modified the generated file to include a carriage return, and I get the same error.

I also tried adding non-zero width/height to the svg file to see if it makes a difference. It does not.

The second bug I posted, ticket #721; was a problem with my test case that incidentally exposed a problem in the interpreter I was using. That bug no longer applies to this problem, but instead shows a related problem.

It does look like I need to pursue this problem in epsf.tex; or rewrite that BoundingBox line to be consistent with the GUI results until I get a fixed pushed down.

Revision history for this message
Alan Post (alanpost) wrote :

I've spoken with Tom Rokicki, author and maintainer of epsf.tex.

The EPSF spec defines the bounding box:

%%BoundingBox: llx lly urx ury

"The four arguments of the bounding box comment correspond to the lower- left (llx, lly) and upper-right (urx, ury) corners of the bounding box. They are expressed in the default PostScript coordinate system. For an EPS file, the bounding box is the smallest rectangle that encloses all the marks painted on the single page of the EPS file. Graphics state information, such as the current line width and line join parameters, must be considered when calcu- lating the bounding box. Example 1: shows a minimally conforming EPS file that draws a square with a line width of 10 units."

A bounding box of "%%BoundingBox: 0 -2147483648 0 -2147483648" is a negative-space box, and cannot be printed or included in a file as a result. You might have noticed that 2147483648 is 0x80000000, and I wonder if what we're seeing is truncation, rounding error, or overflow.

Tom made the case to me that such "broken" .eps files should not be properly handled, though he is willing to continue the discussion should I present a compelling case.

I myself cannot really present a compelling case for what a negative-space box is, other than a software error. It seems I should escalate this problem to the cairo team, though my only test case is unfortunately inkscape, and I do have some confusion over the difference between what we're seeing on the command-line vs what we're seeing from the GUI.

Do you think the 2147483648 value is being set by inkscape, and therefor the bug is in how inkscape is using cairo, or is this in fact a bug in cairo that inkscape has nothing to do with?

Revision history for this message
su_v (suv-lp) wrote :

> Do you think the 2147483648 value is being set by inkscape,
> and therefor the bug is in how inkscape is using cairo

Not sure (not being a developer myself, just helping with bug triage), but AFAICT it needs to be addressed in inkscape anyway:
- consistency (create the same EPS file from command line / GUI)
- development branch: the crash needs to be fixed: either properly abort the export

The SVG file itself seems valid (Squiggle (Batik 1.7) and current browsers do not complain about the zero width/height; only rsvg-view (librsvg) refuses to render it).

I will add the tag 'crash' (for the development branch) and raise importance to 'High' - hopefully one of the developers will be able to look at the issue (it might take some time though).

tags: added: crash renderer-cairo
removed: cairo
Changed in inkscape:
importance: Medium → High
Revision history for this message
su_v (suv-lp) wrote :

Attaching backtrace of crash when exporting sample SVG file to EPS on the command line with current trunk (debug build r11700, cairo 1.12.2).

su_v (suv-lp)
summary: - invalid eps file created from null/empty svg file
+ invalid eps file created from null/empty svg file, crash in current
+ trunk
Revision history for this message
Beluga (buovjaga) wrote :

I get

nil.svg:6: parser error : Premature end of data in tag svg line 4

^
** Message: CairoRenderer: empty bounding box.

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92pre1 15073 (GTK3)

Revision history for this message
Nathan Lee (nathan.lee) wrote :

I don't experience the crash in trunk, Inkscape 1.2-dev (3495c164d6, 2022-01-17), though I still get inconsistent behavior between GUI and non-GUI modes.

In GUI, we get a file with sorta sensible values (%%BoundingBox: 0 113 0 113) and in CLI, we get no file generated.

Anyway, I've manually migrated it to Inkscape's new bug tracker on GitLab (https://gitlab.com/inkscape/inbox/-/issues/6183), and closed it here (as we no longer use this as our bug tracker).

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

Changed in inkscape:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.