GNOME Bugzilla – Bug 643771
Data Interchange Format DIF Export Does not Conform to Specification
Last modified: 2011-03-03 15:47:02 UTC
[Originally reported as http://bugs.debian.org/616152] Date: Wed, 02 Mar 2011 16:09:09 -0500 From: Stanley Pinchak <stanley.pinchak@gmail.com> Subject: Bug#616152: gnumeric: Data Interchange Format DIF Export Does not Conform to Specification Package: gnumeric Version: 1.10.13-1 Severity: normal Tags: upstream Gnumeric does not export Data Interchange Format files in a standard compliant manner. There are two ways in which it is non-compliant. First, the values stored in the header records for VECTORS (think columns) and TUPLES (think rows) are swapped. This makes programs which conform to the specification fail, or issue a warning when an N x M array of data is specified in the header, but the following Data record structure is actually an M x N array (The data in the gnumeric spreadsheet is M x N on screen). Second, Gnumeric includes an extra blank row in exported DIF files. According to the specification, BOT records are used to indicate the beginning of a table (think a row). Insted of terminating the last row of data with the EOD data record, gnumeric inserts a BOT followed immediately by an EOD. This again plays havoc with standard conforming programs. It essentially turns an M x N array into an M+1 x N array. Below is an example gnumeric output next to expected output for 1 x 4 array gnumeric: expected: TABLE TABLE 0,1 0,1 "GNUMERIC" "GNUMERIC" VECTORS VECTORS 0,1 0,4 "" "" TUPLES TUPLES 0,4 0,1 "" "" DATA DATA 0,0 0,0 "" "" -1,0 -1,0 BOT BOT 0,3.4 0,3.4 V V 0,4 0,4 V V 1,0 1,0 "red" "red" 0,1 0,1 TRUE TRUE -1,0 -1,0 BOT EOD -1,0 EOD More info on the DIF specification can be found: http://www.fileformat.info/format/dif/egff.htm http://en.wikipedia.org/wiki/Data_Interchange_Format -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (901, 'unstable'), (550, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.37-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnumeric depends on: ii debconf [de 1.5.38 Debian configuration management sy ii gconf2 2.28.1-6 GNOME configuration database syste ii gnumeric-co 1.10.13-1 spreadsheet application for GNOME ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2 Fonts for the Ghostscript interpre ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-2 The Cairo 2D vector graphics libra ii libglib2.0- 2.28.1-1+b1 The GLib library of C routines ii libgoffice- 0.8.13-1 Document centric objects library - ii libgsf-1-11 1.14.19-3 Structured File Library - runtime ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libpango1.0 1.28.3-1+squeeze1 Layout and rendering of internatio ii libxml2 2.7.8.dfsg-2 GNOME XML library ii procps 1:3.2.8-10 /proc file system utilities ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnumeric recommends: ii evince 2.30.3-3 Document (PostScript, PDF) viewer ii lp-solve 5.5.0.13-7 Solve (mixed integer) linear progr Versions of packages gnumeric suggests: pn epiphany-browser <none> (no description available) pn gnumeric-doc <none> (no description available) pn gnumeric-plugins-extra <none> (no description available) ii ttf-liberation 1.06.0.20100721-1 Fonts with the same metrics as Tim ii ttf-mscorefonts-instal 3.3 Installer for Microsoft TrueType c -- debconf information: * gnumeric/existing-process: true gnumeric/existing-process-title:
Created attachment 182334 [details] [review] Proposed patch Here is a proposed patch to dif.c to fix the issues addressed above. Recent Excel versions no longer output the extraneous BOT prior the the EOD. I suggest that this non-conforming record be dropped for compatibility with the original VisiCalc and DIF Clearinghouse standard. However, Excel does still swap the VECTORS and TUPLES header records, but is agnostic when importing, looking at the actual data representation. Openoffice outputs standard conforming DIF files, I have not see any bug reports about incompatibility with the MS mangled DIF coming from their camp. Thanks, Stanley Pinchak
Wow. I think the last time this exporter received any attention was when the Queen of Hearts was just a little girl.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.