OTG to SVG

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.

The drawing as vector artwork, in the format every browser and every editor opens.

Rectangles, ellipses, lines, polygons, paths, text boxes and embedded pictures come across as real SVG elements with their fills and outlines, at the size the file states — one user unit to the millimetre, so nothing is scaled behind your back. Shapes that cannot be drawn honestly are counted and named rather than approximated, which is explained below.

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.

A template is the drawing, with a different label

An .otg and an .odg are the same file. Same ZIP, same content.xml, same shapes at the same coordinates. One string differs, in the mimetype entry: …opendocument.graphics-template where a plain drawing says …opendocument.graphics. That is the whole of it, and this page exists because the file on your disk says .otg.

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

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