STD to HTML

Your drawing never leaves your browser, and nothing is downloaded to make this work. An OpenDocument file is a ZIP of XML and your browser can already unzip; the rest is reading.

A web page with the drawing in it and its text underneath.

The drawing is written into the page as SVG rather than linked, so the file works on its own with nothing beside it, and the text is repeated below it where it can be selected, searched and read by a screen reader. One file, and no pictures to keep track of.

ODF and SVG share a syntax and disagree about what it means

A rotated shape in an OpenDocument drawing carries draw:transform, which looks exactly like SVG's transform attribute. It is not the same thing:

Copy the attribute across unchanged and a shape turned by a right angle arrives turned by a degree and a half, the wrong way. translate() differs too: ODF's takes lengths — translate(1cm 1.3cm) — where SVG's takes plain numbers, so pasted across it is ignored and the shape sits at the origin.

The radians are not a guess. OASIS OpenDocument Essentials, chapter 6: “The argument to this function is the number of radians to rotate, not degrees, as in SVG.” Regina Henschel's note to the ODF technical committee says the same from the other end — that OpenOffice, LibreOffice and Microsoft Office all write radians.

And the order is the third difference, which no specification states. Neither the OASIS text nor that note says whether a list of transformations applies left to right or right to left. This converter assumed SVG's rule — rightmost first — on the reasonable ground that ODF borrowed the syntax. Converting a real drawing and looking at it proved that wrong.

A drawing application writes rotate(t) translate(x y) on a shape that has a width and a height and no svg:x. Under SVG's rule the move happens first and the turn then swings the shape about the corner of the page: a rectangle the file puts at 120,150 mm came out at 150,−160 mm, off the top. Under the other rule it lands where the file says, turning about its own corner. So OpenDocument applies its list leftmost first — turn it, then move it — and the list is reversed on the way into SVG.

That is worth saying plainly because it was not read anywhere. It was found by converting a drawing and looking at it. Every numerical check here passed while half the shapes were off the page.

What an OpenOffice.org 1.x file is

StarOffice 6, StarOffice 7 and OpenOffice.org 1.x wrote these between 2000 and 2005. OpenOffice 2.0 replaced them with OpenDocument — the .odt, .ods and .odp everything uses now — and LibreOffice has been able to read them but not write them since version 4.3. Nothing current produces one, which is exactly why people still have them and nothing will open them.

It is almost OpenDocument, and the gap is small and specific. The namespaces are the old http://openoffice.org/2000/… ones, there is no mimetype entry in the package — the type lives in META-INF/manifest.xml, and in an office:class attribute the specification put there for the purpose — and, the one that matters, the content sits directly inside <office:body> with no wrapper round it. OpenDocument added <office:text>, <office:spreadsheet>, <office:presentation> and <office:drawing>.

That last one is why a converter written by resemblance can hand back an empty file rather than an error: it looks for an element that was never there and finds nothing. What this page does is put the missing element back and then read the file as the OpenDocument it almost is. Everything inside — the paragraphs, the tables, the draw pages — is named identically.

All of that is read from the OpenOffice.org XML File Format technical reference, version 2, December 2002, and not from the file looking similar. What has not been done is said plainly: no file written by a real OpenOffice.org 1.x has been read here. There is none to test against on the machine this was built on, so it is built to the published specification. If yours does not open, that is worth knowing about.

What does not come across

Shapes drawn by formula. LibreOffice's gallery — stars, block arrows, most flowchart symbols — stores an outline in a path language with references into a table of equations and to the handles you can drag. Working those out needs an expression evaluator, which is not here. Those shapes are counted and named rather than replaced by their bounding box: a rectangle where a star should be looks finished, and is wrong. A gap does not.

Gradients, hatches and bitmap fills flatten to a single colour. 3D scenes are rendered rather than outlined, so there is nothing to carry. Text is placed in the middle of its shape at the size the style states — wrapping inside a box is the renderer's job in OpenDocument and is not recalculated here.

Where to go next

• STD to SVG — the same file, another way out
• STD to TXT — the same file, another way out
• SXD to HTML — the template, which is the same format