All right, our next speaker is Jes van den Uver on the future of open document. Please go ahead.

Thank you for this wonderful applause. It's the most applause I've had for setting up the monitor so far. It's encouraging. So well, my first remark this afternoon I think would be it's awesome that you're

all here, but the room is way too crowded because this topic is very important. We're talking about ODF and ODF means power. ODF is something which is a tool to spread more freedom for users everywhere because it's a standard format which we would like to have on as many machines as possible and

which is essential for exchanging data in a free manner. So that's what this talk is going to be about and let's hope that the room gets even fuller during the talk. A bit about me, I am a civil servant for the Dutch government. I work for the Ministry of the Interior and there I am tasked partially, part of my job

is to work on the ODF specification. Since 2015, the Dutch government has taken an important interest more than they did before in the ODF standards and they decided they want somebody on the ODFTC to speak on their behalf and make sure that the standard stays stable and stays useful for them

and maybe even incorporates new features which are useful for the government. I have quite a history in ODF and in software relating to ODF. You can see the Web ODF logo over there. I was in this room five years ago talking about Web ODF which is an ODF viewer for

the browser. It's just JavaScript and it opens your ODF files. I've also worked on Caligra which is Qt-based office suite which is part of the KDE project. Those are my two main coding tasks on ODF.

So the Dutch government has set itself a very ambitious goal. They want to do all communication with their citizens digitally from 2017. And that's a big thing. I mean everybody here is carrying mobile phones, computers, but it's another thing.

It's only since a decade that people are carrying slightly powerful mobile phones and governments are not always known for being very good at doing software and being digital. So setting this goal is very ambitious.

I'm not sure if we're going to make it but at least we're going to try. There's a big difference though between analog and digital. When you were talking with the government analogly, you would have to speak the language of the country, right? So if you knew the dictionary and how to string all the words together, you could talk

to somebody from government, the police officer, the judge, the person in your municipality, your mayor. But if you do it digitally, somehow there's a lot more protocol involved, right? You have a whole stack of stuff you need to know. TCP, DNS, HTTPS, and that's just the network stuff.

And then you go down and SVG, ODF, PDF. It's quite complicated. So sure, everybody has a machine which does it for them, but this machine somehow has to be made, right? The software also has to be written and it has to stay stable. It has to be trustworthy in communicating this information with you.

So these standards have to be solid. Well, going towards this ambition, there are already quite a few things the government is doing digitally. One of them is a very popular thing for governments to do these days. It's putting data online, just huge blobs of data about any topic you can imagine.

This is the portal for the Dutch government. So, overhead.nl, that means government. And data, well, that's data. So you can search here in a lot of different data sets and get the data in a number of different file formats.

And the licenses are open of most data sets. I see the total number of data sets, 7,393, and only two of them don't have an open license. So people are encouraged to reuse this data.

That's one of the ways in which we communicate. Another way is to publish government documents online. If your municipality or your province is going to work on a road, they used to publish that in your local newspaper, but these days, at least in the Netherlands, all decentralized parts of government have to publish that in a central website.

And on this website, you can download these documents in a number of formats. Now, unfortunately, the icon for the formats has dropped off the screen here, but you can still see the names. I hope you can read them. It says ODT format, XML format, and PDF format.

So this document is text from a discussion in our parliament, and it's available in these formats. I give you a slight view into how we create those, and here you can see the icons better, so it's a bit more obvious what the file formats are.

So internally, we create all these documents in a government-specific XML format. It's specific for the Netherlands at the moment, but we're looking into adopting international standards for that. That is the file format with the highest information. We also convert it to PDF.

That's nice. It's a fixed layout. If you want to print it, it looks good. And it's a mature format. We also support XHTML, because that's easy to view in the browser. And lastly, we publish the document as ODT, because that's the best format for you to reuse parts of the document. If you want to copy and paste into a different document, that's the best format to use.

So these are just three standards, and the government should be using standards. It has to make a list of what are the best standards, and we have a website for that as well. This is the website for the standardization on standards within the Dutch government. You can get the list as CSV or ODS.

So using their own standards, both of these standards are on this list. The list is very long, so it doesn't fit on the screen, but it has a search function. And so it looks like the policy is very good, right? We're creating thousands of documents every day in standard formats. And we have this whole list of files formats to use.

But if you look at how they are actually used in smaller, less centralized areas of the government, then the numbers can look less good. And that's what the next slide is about. And the reason, well, I'll come into the reason a bit later.

So here are some numbers from a report which will be published in a few days, which is doing something very simple. What's being done is just look at two websites, in this case from cities and from provinces, and count how many instances of each file type are available on the website. And you can see that, well, it's done for three years, that ODT has zero in nearly all columns.

But .doc does have significant numbers. So these are parts of government which still have to comply to the policy. They're not following the national policy yet.

Here's another graph showing the ratio between use of ODT and doc. And you can see that there's only one column in the summer of 2014 where the ratio for ODT over .doc was higher than zero, which is good, right?

That means there's more ODT than .doc. But then, for some reason, it deteriorated again the year after. I don't know why this is. I haven't looked into that yet. Suffice to say, adoption is not optimal. Here's another graph, and this is showing what people are requiring in their procurement.

If a government needs a bit of software, they have to make a procurement. And in this procurement, they have to say, I want this software to follow these and these standards. And the policy is that they should ask for standards. So this lists how many of the tenders actually list the right standards. And you can see that for ODF 1.2, which is a version of ODF the Dutch government,

follows only 90% of the relevant tenders actually mention this number. So this is something that also can be improved. The reason why these numbers are relatively low is partially because the policy does not have, if you don't comply with the policy, there's no consequence to it.

So it's just goodwill from the different parts of government at the moment. So maybe we should be a bit stricter in that sense. Now, here's another website which allows you to search for municipalities

to see what software packages they are using. So you can see if the software packages your municipality is using is using ODF. And if you do a search, there are 16 available government-related software packages

which do ODF at the moment. OK, let's go to a different country, the UK. The UK is doing very well with open standards. They had one and a half years ago, two years ago actually, they made a call to ask the people in England, in the UK, sorry,

what standards do you think are more important? What should we as a government standardize on? There was a lot of feedback. And most of it was very, very positive that the government should be using ODF. So that's what they did. This is the proposal they wrote and, well, I'm going to lingo on this one.

But this is the actual guidance for the UK government to use ODF. So this is a document which was written to help all the civil servants to learn how to deal with ODF.

And what I very much like about this document is that at the bottom, it tells especially the reasons for using ODF in just a couple of bullet points. It says we use ODF 1.2 because it allows citizens, businesses, and other organizations to share and edit documents with government and the other way around.

It allows people working in government to share and edit documents with each other. It's very simple language. It's very good. And it's a reliable, long-term solution for storing and accessing information and it's compatible with the right range of software. Very good reasons. It's basically boiled down this very long discussion they had with their citizens about what to use.

And, well, this document was last updated the 11th of September. And they are really making good progress in actually implementing this. The people who are responsible for steering all of government towards this are in the cabinet office and that's just below the prime minister. So they have the right force to be able to make this happen.

And it's necessary because if you look across the EU, adoption of ODF could really improve. There was a campaign, Fix My Documents, which was about just counting how many ODF documents I used within Europe.

And if you look at those numbers, you see that it's also not great. You see two huge columns for .doc and .pdf. But ODS is almost empty, ODP is completely empty and ODT is quite pitiful. And only within the European Commission.

So the European Parliament and the Council of the EU, they are not using this excellent file format. So I think we should tell them more forcefully what the advantages of this format are. And what the potential savings are and what the long-term storage improvements of this file format are.

But there's also good news. There was a talk by Italo Vignoli yesterday that the English army is switching to liberal office and is standardizing on the ODF file format.

They, because of the heavy equipment they use, have certain security-related requirements. And that was part of the reason why they chose ODF. The Liberal Italia Association is very active in getting people to switch to ODF.

They're doing an excellent job and this is a great success for them. And if you look outside of Europe, there are also highlights. The current status in Taiwan is very good. ODF becomes the national standard format and becomes the national policy to use ODF to make documents.

This is great news, right? And they're aiming to fully migrate to ODF and liberal office in 2017. That's great. By the way, you may notice that this is a different themed slide because I stole it from the person who was reporting on this at the liberal office conference last autumn.

And he actually encouraged people because this was his last slide. Tell the world, Taiwan is migrating to ODF now. So that's very good and I hope they succeed. But there's still a lot to do. As you can see, many people just don't know what's so urgent about using ODF as a file format.

And that's why there are promotion materials being made. This autumn we had a meeting of ODF experts in the Netherlands and this was a document which was handed out and I have copies of it over here. The copies and this version are in Dutch but we have translations in many languages.

If you would like to download a version of this awesome graphic, then you can go to the website of Open Forum Europe and look for it. If you can't find it, you can email me and I will help you find it because I'm not sure it's very easy to find.

But it's a very nice graphic and it just explains in simple terms what the advantages of the format are. You get rid of lock-in, you can change your software provider because you have an open standard.

So these are advantages explained in layman's terms in this nice infographic. Another example which I think will help the adoption of ODF is the document liberation project. I guess not many people here know about this project. Can I see a number of hands who have heard of this?

One, yes of course. Okay, well let's say ten maybe. What is so awesome about the document liberation product? They take old files for which the software has long been outdated and can't run on modern systems anymore. They look at all the binary details of this file format and then they write a translator to make it translate to ODF.

And why did they choose ODF? Because ODF basically has so many features that you can translate almost anything into ODF. And of course it's a stable open standard with very good support in a wide range of software.

The inner workings of ODF. Has anybody ever looked here inside of an ODF file? Ah, that's much more already. Okay, very good. About half the people here know that ODF file is basically a zip file.

And in the zip file there are XML files. The styling involved and the styling in HTML is done with CSS. But in ODF it's done with ODF styles. And ODF styles, they derive from CSS.

So all the statements like saying this font should be bold or the alignment should be left or right, that's all taken from CSS. But what's added on top is to have named styles and automatic styles that can be applied to parts of the document. So it adds something on top of CSS to make it easy to work with CSS type of styling in Office documents.

And for images we use PNG and JPEG and SVG just like HTML does. The only thing which is not part of the ODF standard is to define a scripting language. There are a lot of points in the document format where you can say this is a point where a scripting language could tie in.

But the language itself is not standardized. So your Office suite may offer a number of languages to do your scripting in. You're not limited to just one. But there's a big advantage to ODF compared to HTML. And that is, again, this zip container. Everything is in one file. If you get an HTML file from the web and you check out what service it's reading all the files from, it can be 10 different servers.

So if you try to store your document for later use, that's quite a challenge. Sure, you can browse this all for the possibility to download it. But a lot of the materials which are included are dynamic these days. And with ODF, you're 99% guaranteed that whatever is in your document is simply in a zip file.

Sometimes people will put a link to get document information externally. But the common way of using it is to put everything in the same zip container. And that's very good for people that want to read their document in 10 years time. The website would have been long gone, but the file and all the stuff that's needed to render it is still available.

So ODF has come a long way. It's existed officially since 2005. But work on ODF started in 2001. So it took about four years to get to the first version.

It didn't just come out of nothing. And the first version was very, very complete already. 1.1 just added small things, made some small fixes. And then 1.2 was a big bang because a lot of stuff came in again. At that point, we added RDF support, which means semantic information can be added to your documents.

And a very important addition was to standardize the formulas in your spreadsheets. In ODF 1.1 and 1.0, there was no time to actually write down what the formulas mean and what all the formulas do, all the functions in the formulas.

And this was added in 1.2. So from 1.2 on, it's a very, very complete and nice pack. Another very good addition in 1.2 was the addition of signing your documents. So now you can digitally sign your documents so that you can see how this document was really created by person X.

That's, by the way, something that the government were not yet doing. I would like to see that we sign our documents so that if I download a file from the government website and then send it to somebody, that they can see that it's not a file I created. But it was really from the person that you can really see that it was really an official document.

Yes, ODF is standardized at OASIS. That's where we do all our work. But we also push the standards to ISO. And there it gets another blessing. And that blessing can take quite long. You see this for ODF 1.2.

It took slightly less than four years to finally get approved, but this year it finally happened. So if you are in a place where you need to have only ISO standards, you can now also use ODF 1.2. How do we create this standard? Is it like sausage where you don't really want to see what goes in now?

It's actually a very open process. Part of this list of standards which we have in the Dutch government, the requirements for that list is that it's a very open process and anybody can join. And there are no patent royalties to be paid for the standards. And these are also the guidelines for the work that's being done at OASIS.

OASIS has a number of different other standards. For example, legal XML, which is a standard for writing laws in XML. We have a phone conference once a week and what we do there is we apply to comments on the mailing list.

If you have an issue with ODF, you can mail us. And we discuss issues in the issue tracker. What we are currently very busy with is getting through our backlog. We have neglected quite a few issues for a while and we are now doing a lot of churn through all the issues. So if you look at our issue tracker, which is also open, and you can find it via the ODF website.

You can see that we are discussing which issues to put into the next version 1.3. And which issues we are going to postpone until a later version. And then when we accept the change, we change the specification.

And since this year we upgraded the process. Instead of just putting it in files in folders, we are actually using SVN now. OASIS doesn't have Git unfortunately, so we are using SVN, but it works fine. For a specification it's good enough.

These are the members of the TC at the moment. These are the people that write the spec. It's nice to know who they are and to know who's involved. You can see that there are four individuals, so people who just think it's an important standard. And that's why they join.

There's one person from Microsoft. There's no person from IBM anymore unfortunately. They stopped contributing. Of course they took an interest in ODF when they acquired the, when they decided to work. Well they always have had an interest in ODF because of the symphony suite.

But they also took stewardship together with the, in the Apache Foundation of OpenOffice. But they're pulling out of that now. So there's nobody from IBM anymore and the TC. But we have somebody from Multiratio, which is a Hungarian company that makes a version of OpenOffice, LibreOffice, that code base.

Well, the code base with that route is of course split. Somebody from the Document Foundation. Somebody from CIB Labs, which is a company in Munich which does ODF LibreOffice support. Somebody from Red Hat, well the Dutch government.

Yeah, that's it. There used to be somebody from KDE, but he went to the Dutch government. Okay, now, how can we improve ODF for normal people? We have this standard to improve interoperability.

That means if I send you a file, you can open it, edit it, send it back to me and we will have the same file. We will see the same things. And that means that all the software has to implement the standard correctly, right? But from experience, I'm sure you all know that even if you have a different version of a particular office suite, things can still go wrong.

You might miss information. And so these arrows here of document flow, they probably make everybody cringe. Because even though we want to have interoperability, it's not super smooth all the time. So how can we improve that? Well, first of all, we have to convince the people who write the software to join the standardization process.

And actually, we've seen in the past that there are many incentives to not standardize, right? If you control the file format or if you control the extensions that you save, then you have a position where your user is captured, right? So there are incentives for not standardizing, which is why we should applaud the companies that do, even though there might be pressure to do so.

But if they finally do, that's a great thing. And that helps us come to a point where we can say software is not the file format, right? Everybody used to, still many people think that, right?

I send you a Word file. Sorry, what? Could you please send me an ODF file? I don't know what a Word file is. Is that the binary? People don't understand what the difference is, right? And this is an important education point, a very tough one. I mean, yeah.

If somebody could come up with a nice fairy tale to explain people, or a nice simile to explain the difference between software and file format that works every time, that would be a big feat. There's members of my family who have been explaining this to for a long time, but they still don't get it. So it's tough to learn people about this.

But if we learn people in control, so people in large organizations about this, and they understand it, that can really help speed up the adoption. Another thing is that I would like editors of ODF to be gentle. What I mean by that is that when they open this zip file and they open the XML inside it,

what they often do is they translate that into their internal memory model and save that back as a different... Well, it's still ODF, but it has different conventions in there, right? Maybe they have a different scheme for naming the automatic styles, or maybe they

will prefer one type of element over the other when they have similar functionality. And I think software shouldn't do that. It should just take the XML as it is, and when I type in a paragraph, just add the characters there. Now, this is a bit into the future on one hand, for the established Office Suites.

LibreOffice, Microsoft Office, Google Docs, they don't work in this way. And it won't be easy to make them work in that way. But it would be good if they went in that direction. I know of two Office Suites softwares that do this, and that's OX Documents, which is a cloud-based solution. And what they do is they have a document, and then they just send operations to the document.

So on the server, they store the actual ODT, and then they stack the changes to the document on top of that. So you always have the original document and just a minimal set of changes to your document. So if they don't understand something, for example, that graph you see there, their software may not understand it.

But they don't touch it. They just leave it alone, and they can render it. ODF tells you that if you have a sort of fancy object in your file, you should also put an image next to it. So that even if I can't render the fancy object, I can still render the SVG or the PNG, which is next to it.

So yeah, the Web ODF and OX Documents are the only ones at the moment which do this. But I encourage anybody who would like to start programming ODF software to take this approach. Oh, duplicate slides. Uh-oh. I'm not sure if this was the next slide. I don't think it is, actually.

Maybe I just killed it. Sorry about that.

This is a laptop I borrowed because my laptop only has HDMI. And I don't know, maybe this one is a bit slower. I think it's having a hard time rendering all the slides.

So while I'm finding the right slide, I can tell you about what the next slide was going to be. And that's to say that what you should also do instead, as long as we

don't have offer suites which are gentle to the ODF files, we should do testing. Exciting point. Yes. Okay, I didn't show this one before, but here you can see that the styles... I'll just skip this one.

We need gentle editors, but we also need testing. So what we have done in the last six years or so is to have Plugfests. And a Plugfest is where implementers of ODF software come together, they sit in a room, and they test all their implementations to see if they work in the same way.

We had the eleventh Plugfest in The Hague last September, so we already had eleven of them. Which is a lot. You can see we tour all of Europe. We haven't toured out of Europe yet, but that might be in the pipeline. Maybe we'll go to Taiwan in the future. That would be nice.

This was a picture from the first Plugfest, which was also in The Hague. And this is a picture of the eleventh Plugfest. And well, nothing changed really. People got a bit more gray. Some people got exchanged.

So how does it work? How do we go about testing? We come together in one location with your laptop. You go to this website, which is a wiki, and there we have scenarios. For example, we have a scenario for creating a spreadsheet with a graph. You create a spreadsheet with a graph, then you save the file to the wiki,

and somebody opens it in a different office suite. And he looks to see, hey, is this a spreadsheet with a graph? Okay, what are the values in the graph? What are the colors? Is it correct? Okay, is it not correct? And then you analyze the results and write them in the wiki. Well, you saw that we've done it eleven times already, and on one day we can maybe do eight scenarios, if we're lucky,

after setting up the laptop. So that's not really going to give us a lot of coverage for a standard which has hundreds of elements. So we improved this way of working. And the Plugfest we had in London, the one before The Hague, what we did there is we wrote tests and then ran them automatically.

So we went through the specification and wrote small snippets of XML which we wrapped into an ODF document. We scripted all of that so people didn't have to do that. And then we collected the results onto an HTML page. All of this was done before the actual Plugfest,

so the results could be read by the people coming to the Plugfest and they could discuss which office suite was doing it wrong and which was doing it right. Or maybe the test was wrong. And then we collect all of these results in a report. Here's an example of such a test.

So it's a simple text test. It basically says, hello. And that's the input. And then the output has to be an ODT in one of the versions. And the file content XML in this file has to still have one paragraph. And we count that automatically by writing an X path expression there.

So you have an X path and that's the slash slash O column text, text column P. So one paragraph. That count should be one. If that's not one, then something went wrong in loading and saving of that document.

This simple type of test, we have now hundreds of these. So at the last Plugfest we run them and each test results into a page like this. So you see red and green colors. Let's use a universal code for good and wrong. Some are true, some are false.

The first line has the validation errors. Those are easy because every document has to be valid. So we test every document which we save to see if it's valid. I don't know if you can read the headings here, but the first red column is Google Docs. The one next to it is every word.

Then WebODF and LibreOffice are green and Microsoft is red again. So not everybody is validating all the time. Then the second line, the label is a bit incomprehensible. That's a usability issue in the test interface. But basically what this test does is tests if you have a wave through your text,

if a line is a wave, if that's actually retained in the document. At the bottom you can see what a screenshot of the implementation shows. And you can see that Caligra is the only one showing a wave. I took a particularly nasty test, one for which many office weeks failed.

You can see that Google Docs just doesn't even have the line. And the two red blocks above indicate that it's even losing the information that there should be a line through. So not only does it not render it, it's actually losing the information. So your document is less good after going through Google Docs.

And the same is true for every word. Then with WebODF and LibreOffice, it's a mixed story. WebODF comes through nicely, but that's because it's a gentle editor and doesn't touch the XML. LibreOffice does retain the fact that there should be a line, and in the rendering you can see there's a line. By the way, WebODF retains the information, but it doesn't show the line.

But LibreOffice doesn't retain the fact that there's a wiggly line, and neither does Microsoft. So this is a point where we can improve. Now, having hundreds of these tests, we managed to go through a lot of them at the last blogfest, and we counted them all up. First we wrote, per box, 10 more minutes.

That fits perfectly. Per test, we wrote down, OK, Google Docs has a bug, AB Word has a bug, WebODF has a bug, and then in the end we counted all of that up, and then we solved these numbers. These are actual numbers where the implementers looked at it and said,

yes, these are real numbers and we have to go and fix them. But it's only for one area. We only looked at text rendering at this blogfest. So even though we managed to really a lot of tests, we didn't get through all of the specification. So it's still not fast enough. We still need to level up once more to do more testing.

How are we going to do that? Well, ideally we'd like to come to a situation where we have something like the acid test. The acid test is, this was hit in 2005, right? When browsers were really, really sucky, and somebody came up with a bit of HTML which was so crazy

that if you showed it in the browser, it looked like a smiley face. Well, Internet Explorer 6 shows just a big red block, as does Internet Explorer 7. Well, Opera 8 isn't much better. It's quite horrible, right? With ODF, we are not in a situation as bad as this, but we do want to improve.

And we also want to get to a state where we have a smiley face and we can say that 100 out of 100 passes for most of the Office Suites. But then we first have to make sure that we have to test all of that. And what we would also like is to make it easier for implementers of ODF to find information about what a particular Office Suite supports.

We saw in a previous test that if you want a wavy line and you're sending it to somebody with Google Docs, that he won't see the line at all, right? So can we provide users with this information? Can we make a website where you just drag your file on top of it

and it will tell you this file will look okay in these Office Suites? And this is why. And these are the links to the bug reports about them. That's what we're building right now. And that's what this slide is all about. So we made a design. As you can see, it's very pretty. It's actually almost unreadable.

After we made this, we felt very proud of ourselves that we made this wonderful workflow of doing all the testing. And then when I came home and I tried to decrypt it, it took some time, but I managed. And now we're busy implementing a website

where people can go to and upload ODF documents, see what they look like in the different Office Suites. And if there's something wrong, isolate what the problem is with an XML editor inside. So at that point, you need a bit of expertise or you just label the document, can an expert look at this?

And then we isolate the test case, give it a name, add a commenting function so people from different implementations can talk about what's going wrong if maybe the specification itself is unclear or if it's just an obvious error in a particular Office Suite. And that way, I hope that we can accelerate

that all the Office Suites come to a common understanding of how to show you an ODF file. And this site should have a scoreboard. That would be the most awesome thing, right? So that you come there and you say, which Office Suite is in the lead today

of being the best at rendering ODF documents or editing ODF documents. These numbers are real, but the names are removed, just to avoid. The numbers are from the previous one. They're only about the text. So I removed the Office Suite names

to avoid this ending up on a block somewhere because it's just part of the ODF specification which we've been testing. But we would like to have a picture for the whole ODF specification like this based on actual data, where you can drill down and show data about the text or the formulas

or the graphs or the images or the presentations. That's the next step. Yeah. So that's the future of ODF. But the future of ODF is also you in the audience because your computer uses, everybody here is writing Office documents.

I hope you're all using ODF. I'm not going to ask. I just trust that you do. I also hope that you help spread the word about ODF and talk to your government, talk to your company that they really should use this standard. And if you can, write ODF software.

It's awesome. It's a lot of fun. And if you want to test it, that's also great. We hope to have this testing server up this year, which will streamline the testing process. But we will also continue having the Plugfest. So if you're interested in coming to a Plugfest, you can also do that.

That's it. Other questions?

I can repeat the question if you want. Hi. So you said in Open Document Formats, the specification says only accepted image formats

are PNG and JPEG. And as far as I remember, in the Open Document Format specifications, there was no such restriction. So this allowed OpenOffice and LibreOffice to use their own proprietary image formats as replacement for graphics and so on.

Has it changed recently, or is it just that mistake? Yes. So the specification encourages you to use PNG and SVG as images. JPEG is also fine, of course. And you're asking,

are OpenOffice and LibreOffice still saving to their own vector graphics format when they're saving, right? Well, this presentation was created with LibreOffice 5.0, and it has the SVGs which I put in there. So I looked inside the zip file, and it just had the normal SVGs. So at least in LibreOffice 5, it's fine.

I know it's also fine in Caligua. It's also fine in WebODF. I'm not sure about if... I don't think OpenOffice changed it. So they're probably still right to the SVM format, which is proprietary, as you say. Are there any other questions? No. All right. Well, thank you very much for your talk.