ODG 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 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

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