[Mono-bugs] [Bug 332246] New: Strange problem in Mono's XML and/or XSLT code

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=332246

           Summary: Strange problem in Mono's XML and/or XSLT code
           Product: Mono: Class Libraries
           Version: unspecified
          Platform: x86
        OS/Version: SLED 10
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Sys.XML
        AssignedTo: atsushi at ximian.com
        ReportedBy: tlillqvist at novell.com
         QAContact: mono-bugs at ximian.com
          Found By: ---


We are having some odd problems when we build odf-converter with
Mono. The problems show up the same way both on Windows and Linux. I
have verified them today with a fresh Mono built from SVN. 

(Running odf-converter with .NET works fine.)

(odf-converter is the XSLT-based tool that converts between
OpenDocument formats and Microsoft's OfficeOpen XML formats. We ship
odf-converter as an extension to the Novell Edition of OpenOffice.org,
until the native built-in OOXML filters we are working on are complete
enough.)

I am reporting two related (?) things here:

Adding a single non-significant (as far as I know) space in one of the
xml files that a .ods file contains makes the program behave
differently. Without the space odf-converter stops with an exception:

This XmlWriter does not accept EndElement at this state Error.(  at
System.Xml.XmlTextWriter.WriteEndElementCore (Boolean full)
 at System.Xml.XmlTextWriter.WriteEndElement ()
 at System.Xml.XmlTextWriter.Close ()

(rest of stack is the odf-converter code)

Another issue is then that if I insert that one space and the
odf-converter then runs to a normal finish, some of the .xml files
included in the .xlsx file it produces are actually illegal XML.

To reproduce the problems on Linux, proceed as follows:

- Download
http://download.go-oo.org/tstnvl/odf-converter/odf-converter-1.0.6/odf-converter-1.0.6.tar.gz
 Unpack it into some folder. 

- Download
http://download.go-oo.org/tstnvl/odf-converter/odf-converter-1.0.6/odf-converter-1.0.3-broken-move.diff
,
http://download.go-oo.org/tstnvl/odf-converter/odf-converter-1.0.6/odf-converter-1.0.3-zlibwapi-link-path.diff
,
http://download.go-oo.org/tstnvl/odf-converter/odf-converter-1.0.6/odf-converter-1.0.6-RemoveAttribute.diff
and
http://download.go-oo.org/tstnvl/odf-converter/odf-converter-1.0.6/odf-converter-1.0.6-value-of.diff
 Apply these diffs to the odf-converter-1.0.6 sources.

With a recent Mono in PATH and PKG_CONFIG_PATH, run "make" in the top
level. It should produce in source/Shell/OdfConverterTest an
executable called OdfConverter, which is a mkbundle2-produced
executable.

(I am sorry, but making this work with normal assemblies and not
mkbundle2-ified executables requires some changes to the zlib
interface code in source/Common/OdfZipUtils. I haven't looked that
closely into that yet. If you need to run a non-bundled assembly I
could try to see what is required. There are different issues on
Windows and Linux related to this. It's rather a mess. I don't
understand why the upstream odf-converter people insist on interfacing
to an external zlib shared library, why can't they use some managed
reimplementation of zlib, aren't there any such suitably (for them)
licensed?  (MIT or X11 style))

cd to source/Shell/OdfConverterTest, and download
http://download.go-oo.org/tstnvl/tml/t00001.ods there. Run:

/OdfConverter /ODS2XLSX /I t00001.ods /O t00001.xlsx /LEVEL 1

You should see:

[INFO][t00001.ods] Converting file: t00001.ods into t00001.xlsx
progress:table:table-cell[ERROR][t00001.ods] Conversion failed - Error during
conversion
[DEBUG][t00001.ods] This XmlWriter does not accept EndElement at this state
Error.(  at System.Xml.XmlTextWriter.WriteEndElementCore (Boolean full)
[0x00000]
  at System.Xml.XmlTextWriter.WriteEndElement () [0x00000]
  at System.Xml.XmlTextWriter.Close () [0x00000]
  at CleverAge.OdfConverter.OdfZipUtils.ZipArchiveWriter.Close () [0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractPostProcessor.Close ()
[0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractPostProcessor.Close ()
[0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractPostProcessor.Close ()
[0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractPostProcessor.Close ()
[0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractPostProcessor.Close ()
[0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractPostProcessor.Close ()
[0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractPostProcessor.Close ()
[0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractConverter._Transform
(System.String inputFile, System.String outputFile) [0x00000]
  at CleverAge.OdfConverter.OdfConverterLib.AbstractConverter.Transform
(System.String inputFile, System.String outputFile) [0x00000]
  at CleverAge.OdfConverter.CommandLineTool.OdfConverter.ConvertFile
(System.String input, System.String output, Direction transformDirection)
[0x00000] )
Done.

Now unzip t00001.ods (OpenDocument files are actually .zip archives)
into some temporary new empty folder, and edit the content.xml
file. Find the place close to the end where it has:

..<table:table-row table:style-name="ro1"><table:table-cell
office:value-type="string">...

Insert a single space so it becomes:

..<table:table-row table:style-name="ro1"> <table:table-cell
office:value-type="string">...

Make sure you don't use a "too clever" editor that would make other
formatting changes to the file... 

Replace the content.xml in t00001.ods with the edited version and
retun OdfConverter. This time it proceeds to the end, producing a
xlsx file.

The second issue is that if you unzip the .xlsx file produced by
OdfConverter into some empty temp folder, and look at the
xl/sharedStrings.xml file, you will notice that it is not valid
XML. The <si> element is ended by a </t> end tag.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.