WebODF, an office suite built on browser technology
Oever, Jos van den
Office suites for the cloud are becoming more popular. All of them are closed source and, worse, running on a server that is outside of the control of the user. A Free Software solution for this problems is urgently needed. WebODF is a library for adding OpenDocument Format (ODF) support to applications, regardless of whether they are running on the web or on the desktop. WebODF is a javascript library of about 1000 lines of code (measured August 2010) that can display ODF documents in browsers and HTML widgets. Currently, editing support is being added. WebODF can be used in web applications and desktop applications. WebODF is extremely innovative because it is the first FOSS implementation of an office suite based on HTML5. Using HTML5 means that the code will run on nearly all modern computing systems. On top of that, it uses CSS in such a way that the ODF document is used nearly unaltered as the run-time presentation. This simplification allows us to develop fast and with little code.
 Welcome everybody to the second talk in the office track. This one will be different from the one before, different from the one after because it's a very different project. This project is not a decade old like the other ones, more than a decade. It doesn't have a million lines of code, only 3,000 at the moment. So it's all running in the browser. So it's quite different than before. I'd like to, by the way, thank Foslan for giving me the opportunity to speak here. I really love this conference and by letting me speak here I really feel honored. So let's start with the overview of the talk so you know what's coming. I'll start with a small demo on how you can use WebODF on your website because it's so very easy to use it. I'm just going to start right off with that. Then I'll go a bit into the history. It's a young project about half a year old and I'll tell you how it came to be, why we thought of this idea. Then I'm going to explain a bit about what is ODF, what does the file format look like and how can we put the information in the file inside of an HTML file. Then I'll go into how you can write JavaScript for WebODF because it's a bit, we're quite strict on how to write JavaScript. It's not so easy as you might think. And then at the end I'm going to show you how to use WebODF not on your website but in your program. So what's the goal of this project? The goal of WebODF is that we're making a JavaScript HTML5 library that makes it easy to add ODF to your website or your software. So if you want to have a way of viewing ODF files, you are not dependent on a browser, sorry, on a cloud service. You can put it on your own website or your company server and it's easy to look at your ODF files then. We will also in the future add editing support and then you can also collaboratively in the browser edit ODF documents and they will be exactly the same documents which you can open in Microsoft Office, LibreOffice, OpenOffice, Kaleegra. It doesn't matter. And just because we're using JavaScript and HTML technology doesn't mean we are limited to the browser. In fact, it's very easy to use this technology to make an ODF application which runs on the desktop or on a mobile phone or on a tablet. And that's an example I will give of that at the end of the presentation. So how to use WebODF? What do you need? You don't really need a lot. You just check out the GitHub repository. It's quite small and you need a web server. That's all you need. There's actually a small script inside of WebODF. It contains a file called HTTPserver.js and that's a script which you can use with Node.js to start a small web server. And I'm going to use that for a small demonstration. But you can just easily use Apache or any other web server. So you take the web server or use the given script and you copy these files. That's all of them. So it's one ODF HTML. That's basically the application. A CSS file with the default styling. The basic startup of the program, ODF.js, and the rest of the functionality is put into classes in separate JavaScript files. But it's just a couple of files you copy into the same directory. Once you've done that, you have an ODF web server with ODF viewing capability. What's missing then is just your files. You take your ODF files, put them in the same directory or relative to the JavaScript, and you're good to go. So you can go to a URL which has a hash and then the name of the file. So if you have a content management system, you want to have ODF support, just copy the files in there, link up the documents which the user's upload with a simple hash to ODF HTML and you're done. So I'm going to demo that now. In fact, I was demoing it all along because, as you can see, I'm running a web browser. This is Chrome. And what you see here is a URL. So I'm running this on localhost. The previous speaker had an objection to using HTML technology because the web might go down and you can't use your software. I'm just running this on localhost so there's absolutely no danger of this going down. It's completely safe. Yeah, and this is just a file. So I'm presenting from this file. I will go to here to show you. This is the server running here, demo directory. I'm calling the note executable with the HTTP server script which just does, if you send a get to it, it will give you the file. It's a very simple server. And here are the files. This is just a JavaScript. So these are all the files in the directory. See that the files are just listed, including then my report, ODT, the open document standard which is something I will use to show you later, and a presentation and a spreadsheet. So we're not just, I'm working now with a presentation, but we're also supporting spreadsheets and text files. So this is the same. This is a different version here. I wrote a small UI into it. This is not the standard part of WebODF, but it's an example of how you can use it in a more sophisticated application. So this is just an XGS. It's a JavaScript library with which you can build UIs. And here it's listing some files. So you can open it, and here's a different presentation. So you see it's got styles. It's got pictures. Here's a big spreadsheet. It takes a bit longer to open, but not really not. If you consider the size of this file, it has colors for styles, colors for the cells, and basically it looks pretty good. So that's how you use it. Now how did it come to be? Why did we think of opening or writing an application which can easily allow you to view ODF documents in your browser? Oh, spacebar stopped working. Yeah. Well, for that I have to start a WebKit. I guess many people know WebKit. The browser I'm using now is Chrome. It's also built on WebKit. It has a history of long ago. It started in the KDE project where the browser was KHTML, and that was a very popular browser. It was pretty good at the time, and so good that at some point Apple decided to fork it and make it into the Safari web browser. At this time, Mozilla was the most popular open source browser, and they didn't choose Mozilla because they liked the design of KHTML better. So initially, Apple wasn't behaving very much as a nice open source citizen in the sense that when it made a new Safari release, what it did was it just dumped a tarball of the source code. But after a couple of years and complaining about it by the KHTML developers that they wanted a more open development process, Apple started the WebKit project. So it became really a proper nice project. From that point on, it gained more ports. That led to Chrome, GTK WebKit, Qt WebKit, and many other adaptations of WebKit. And now, nearly every computer has a version of WebKit running. By computer, I also mean mobile phones and tablets. So it's pervasive. It's a huge success. And within our company, KO, we were thinking, well, can we repeat this for OfficeWeets? So to see why WebKit is so successful, we have to go back a bit and look at how it works on the inside. If you have all these different environments for which there are ports and you look at, for example, the string class for them. Most prices are written in C++. But C++ is different on every platform. In KDE, you have a queue string. Mac OS has an NS string. CF, I don't actually know what that's meant to replace that. WeXWidgets has a reX string and a Hyku has a B string. So there are many different strings. And people can get very obsessed about what type of string they're using. And not just the strings, it's also the vectors. It's also the graphical interface which we're talking to. The clever thing Apple did with WebKit when it ported it from the queue string and the whole queue environment to Mac OS is that they abstracted away all of these things. So they made it possible to implement a few abstract platform-dependent classes and then have a native application, a native WebKit environment. And that's why the adoption was so great. Now we would like to repeat that. At the time we wanted to repeat that, this was an inspiration for a project which we called ODFKit. And since most free open source software is also written in C++, but also the libraries are different. I mean, LibreOffice, Kalihra, and AbiWorth all have different string types and the different widget sets. We thought, well, why don't we take the WebKit approach and build on that? So ODFKit was born and it used the WebKit approach. And the initial scope was to have a server-side handling of ODF documents. So we didn't want to go do graphical route. First we'll say, OK, is this idea of loading, saving ODF documents on different C++ frameworks is that feasible? And we started working on it and one of the excellent things of WebKit is that they have a very good test environment. They have tons and tons of tests. And these tests are all written in HTML with some JavaScript to run them. So we are also writing a lot of unit tests. And our unit tests were reading ODF files. And at some point I was thinking, well, why do we need to have the unzipping inside of the ODFKit part, can we move it to the JavaScript side? And in fact, there are GZ libraries written in JavaScript. So I started playing and at some point I didn't have any C++ left. I just had my JavaScript. And I thought, well, OK, so it's possible in a browser, and I tested it not just with WebKit but also with Opera Firefox, it's possible to unzip a file purely in JavaScript, then take the custom XML and put it into a web page. And that's how Web ODF got started. So now I'll tell you a bit about what ODF looks like and how you can put it inside an HTML page. So ODF, it's a great standard. All three Officeweeds in this Office track today use ODF as their main file format. It reuses many technologies, XML, zip, URLs, XS, RF, RDF recently since version 1.2. And I think that's a great addition. I won't go into too much what it is right now. Scalable vector graphics, Xqueries. And it's very active. There's a weekly call of the people working on the standard. And they are all from different vendors. They're talking together about how to improve the standard. And a couple of years, there's a plug-fest where implementers from different versions of different ODF software come together and see if their ODF documents actually work together well. There are many implementations. Kalira, LibreOffice, well, you know most of these. The ones on this side are actually cloud services, well, Microsoft Office is also a desktop application but also has a cloud service. And the growth of cloud service was actually one of the reasons why we said that Web ODF would be important because more people want to work on documents in the browser. But they don't always want to put their documents on a Google server or on a Microsoft server. So how does Web ODF work? Well, you start with an HTML file. And in your HTML file, you figure out what the path to the zip file is and you start loading it. The loading is usually done with an HTML HTTP request, which gets the binary data and it doesn't get the whole file at once. If you have a file with large images, it will not get that at once it will be too slow. So we will first get the index of the zip file, then it will get all the bits which are important to load. The content XML file, which is the most important file, the settings XML, the styles XML file. And then it will put the information which is in there in the DOM tree which forms your HTML document. Then you've got a lot of XML added to your document. And the HTML standard says if it doesn't recognize a tag, it will do nothing with it. So any normal text which is in there is just shown as plain text. And it doesn't look like an Office document, let alone a spreadsheet at all. So what we need to do is we need to use CSS with namespace support and I'll show you later how that works to hide and show the important bits and to format them on a page, on a slide or in a spreadsheet cells. Then we look at what the custom styles are, the bold, the italic, the font used, the size of the font and we also convert that to CSS so that the file in itself looks good. And after that, we load the images. So that's basically all the different steps and we'll go into each of these in more detail now. So most ODF files are zip files, not all of them, and they contain XML files and pictures. HTML has one DOM, so it's usually an XML file or at least if it's not a proper XML file it will be read as one, it will be corrected. ODF has a different serialization, so the problem is, HTML has one DOM, but in a ODF file there are many zip files, so which, sorry, many XML files, which of the XML files will you actually put in the HTML DOM or how will you put it in there? Well, there's a solution for that because the ODF standard has a different serialization which is just one XML file. Everybody's using it, actually, or not really, but it's still useful. The fact that it's in the standard gives us at Web ODF a good idea of how to put the different parts which are normally in a zip file into one DOM tree. And this is what this will look like. So here's the HTML. This is the live tree. I've collapsed the head and you see the body. That's an HTML body and then the document tag there, that's an office tag. It's in the office namespace. It's not shown like that. That's just something typical in the way Chrome shows this. And then you see different tags and each of those tags contains parts from the different XML files in an ODF file. So by following the standard, we can put all the components inside of one DOM tree. And once we have it there, we can do lots of stuff. I mean, suppose you would like to do some editing or custom scripting. You could just go wild with JavaScript like you do with HTML pages and modify it to your heart's content. It's all available with the DOM API now. So that's step one. We've got the whole document loaded in the DOM tree, but it doesn't look very good yet. So what do we do? We want to use the styling information. But the styling used by ODF is not the same as HTML. HTML uses CSS, CSS3 by now, and that's quite different from the styles in ODF which are based on XSLfo. So we need to convert it. But there are two issues. ODF uses style names. So whenever you have a style, you just say, OK, this element has this style. This element has that style. Whereas in CSS, you have selectives. You say, OK, this is a div and all divs which are inside of a paragraph or which have an ID like this should be green. So it's a bit different. And the properties themselves are different. So if bold might have a different name, then bold in ODF might have a different name than bold in CSS. Well, for bold, actually, it is the same, but there are many tweaks you have to do. So here's an example. This top part is an extract from styles.xml, and it defines a style called myBold. And basically what it says is, OK, text property, this is bold. And then below, you see how we would convert this so that the browser shows us properly. You see text pipe p. Now the pipe is the equivalent of the colon in XML. It's a divider between the namespace prefix and the local name. Then you see the angular brackets. And the angular brackets say, if the text style name is myBold, then this applies. So we have directly translated the selector based on just name to below the selector based on a paragraph with that name. Of course, there's not just paragraphs. You have also headers and lots of other elements. And all of these elements will have to have the same rules. So in practice, we have to repeat this rule quite a few times to cover all of the styling. And you'll see that later when I show you some introspection in the browser. So that's basically how the conversion works, and you see that I should go back one step. What we're doing here is because we're changing the styles into a CSS, but when we're editing, we will first edit the top part. So we'll change the actual ODF, and then redo the translation. So when we're editing, which we're actually not supporting yet, but which we're planning, we will be editing the actual ODF, and then we calculate what CSS looks like. And this brings us to a point, a problem with many Office suites is that they usually try to warn you from using ODF, or they try to warn you from the document which is not your native format. Microsoft doesn't like you using open document formats. Well, it doesn't even matter if they like it or not. Their runtime model is quite different from what ODF looks like, and that's why some features may be lost when you're saving. Unfortunately, they never tell you which features exactly so that you could make a reasoned decision on whether or not to use ODF or not. But the same thing goes for LibreOffice, for example. When you're opening something in ODF and you want to save it as PowerPoint, they will give you the same warning. They'll say, yeah, we're not sure if PowerPoint has exactly the same features, so are you really sure that you want to use it? Well, in ODF, our runtime model is ODF, just like the model which we're saving. So there is very little difference. It's just the XML which you have on disk is the way it looks in the browser. And I want to give a small demonstration of that by actually just going and looking inside of this browser now. So this is the live document. And by the way, do you know what this is? This in office text editor terms, you call this an underwater screen. It was popular and worked perfect. And basically in the browser, it's back. You can actually see what your document looks like. So you see here the XML. And here you see if you select an element, for example, the first page, you see what CSS applies to it. So you can directly see when you're developing or improving web ODF if the CSS translation is correct. And you can even see where it was defined. OK. But that's just the underwater screen. OK. The next part will be a bit of a JavaScript. Because writing JavaScript is something many people like to do, but few people like to learn. The problem with JavaScript is it's quite flawed. There are many problems with it. But you can avoid the problems. And that's what I want to go into a bit right here. You have to be very careful when writing JavaScript. But with the right tools, it's a doddle. It's just fine. Just you have to be aware of them. So I want to talk a bit about that now. So these are the practices which I want to talk about quickly. So you have to use the good parts of JavaScript. There are many bad parts. You want to use JSLint, which is just a checker, which checks is my JavaScript good. You want to use runtime abstraction. And we really need that here, because web ODF might be running in a browser. It might be running on a command line. It might be running in a native application. So we are abstracting that way in our project. You want to use callbacks for fast IO. And you want to compile your JavaScript using the closure compiler. And of course, use a lot of unit tests. So the first part. I saw that a standard of a Rylea, that the biggest sponsor of the event. So I think it's good that I say this is an excellent book. And you should probably buy it if you want to write JavaScript. It's called JavaScript the Good Parts. And it explains which part of JavaScript are bad and which you should avoid. And yeah, it's a very thin book. It's a great read. I think you should really have a look at it. The author of the book also wrote a program called JSLint. And JSLint will tell you what, if you're using a bad part of JavaScript. So you can avoid it. So the runtime. WebODF runs in different runtimes. And the only common thing between all the runtimes is that, of course, they're all JavaScript. And some may have a DOM. If they don't have a DOM, you cannot do anything. You cannot do everything. But you can still do the unzipping, for example. You can still do base64 encoding. And the runtime is a thin abstraction layer that gives you access to the file system, logging, use of timers, the window object. And we have currently runtimes for the browser, for Node.js, which is the server which is currently running this presentation. And Rhino, which is a JavaScript implementation. You should also use callbacks. This is a very cool feature of JavaScript. And since IEO is often the bottleneck in your application, instead of waiting for an event that may be slow, you should pass a function. So here's a function loadxml. We want to read the file myfile.xml. Instead of waiting for the result, we just pass along a function. And the function has two arguments, error and data. And if the loading has been done, then this function will be called with either the error message or the data. So because the function loadxml itself returns immediately, sending a request to the file system and then hanging this function on there, it can immediately continue with all of the rest of your applications. So your application becomes a bit faster, quite a bit faster. Well, it's very important to write unit tests. It's tricky to write a program which runs in a browser. I mean, browsers are so different. They're getting much better, but they're still very different. So you really need to test a lot. And also, I have to admit, I didn't mention this yet. But we are not even supporting Internet Explorer at all right now because it's not worth it. I looked at Internet Explorer 9, and we might support that. It's a lot better, but I'm not sure it's following the standards good enough. We tried, when we endowed on how to develop something, we just read the standards and use that. And if Internet Explorer adheres to that, we may start using that. I don't see that as a big problem for adoption of the project because if you want to use a native application, you're free to choose any browser you like. A WebKit component, for example. If you want to use it on an Internet, you control who is using that browser. So selecting on quality of browser is not really an issue, I think. So we also test with command line programs just so that we can do unit testing easily. We don't have to press reload in all the browsers. We can just run something on the command line. Instrumenting the code, there's a very cool tool called the JS coverage. What you do is you run an executable over your JavaScript code, and it will instrument it. That means it will add monitors in all of your code, and then when you run your tests, it will tell you how often every line of your code was executed. And that's very good because you can check if you are actually testing all of your application. Okay, Node.js, I want to say a few things about that because you want to run unit tests on the command line. Node.js is a V8 engine. It's the JavaScript engine which is in Chrome, and it uses callbacks extensively, so it's very good for a server. If you want to implement a server in JavaScript, well, this is the thing you need. It's really up and coming. We're also using Rhino. It's a very slow JavaScript engine, and it doesn't use callbacks, so the reason why we're using that is because it's so different. Because the callbacks do need special attention. You need to make sure that if you pass a callback that you don't need it before you actually leave the current execution loop. And lastly, we're using Qt WebKit because neither Node.js nor Rhino has a DOM, and we also would like to do tests on the DOM on the command line. So we have Qt WebKit which runs with no user interface, and which we can do more testing with. Okay, next in the list of tools which you want to use with JavaScript is a Closure compiler. Since what does it do? It combines all your JavaScript files into one big file and optimizes that, and in itself that's not really too important for this project because the code isn't so huge, but it also does syntax checking, and it also does type checking. So instead of waiting for your browser to give an error, you can already on the command line see if your code is any good. How does this type checking work? Below here is a small code fragment, and you basically, you set comments saying what type every argument to your code is. And even if you pass a callback function, you can say what the arguments to the callback function should be. And it's surprising how many type errors this will catch. Okay, that was most of the talk already. I would like to at the end show a way of how to use WebODF in your own program. If you download the code, you'll see two examples there. One example is to use WebODF in a Qt application where you're using Qt WebKit and you create a canvas where you can load ODF documents. And another example which is in there is to make an Android application which could show ODF documents. At the moment, there's no decent application on Android to show ODF documents. And this one is also just a demo. So it's not released as a decent solution which is in the marketplace yet, but it's very small because most of the code is in the JavaScript which is shared. And it would be very easy also to make, for example, an iPhone or a BlackBerry version of this application. So this is a small excerpt of the code of it. It's basically two classes. And here you see some of the magic happening. Here, what you do is you load this ODF.HTML file in your WebKit widget. And when it's loaded, you change the current runtime. You change the read function. You change the function for the get file size. And once you've done that, then you instantiate a new ODF container. So we're overloading two functions. And then this gives our application the ability to read any file on the file system. So the advantage of this application is that it can actually show you files which are on your disk. And I'll run it now. It's here. So this is the simulator. It's an older version of Android. I purposefully used an older version to show that it also works there. You don't need all the new features in Android to get this running. So here it goes. Let's open a spreadsheet. The emulator is a bit slow. And then the device will be faster. So here you see very simple spreadsheets. Let's open a small text file. And you see that this is just a, it's really just an HTML page, but also Android Proverger with nice UI here. And yeah, it's a very small application. Most of it is just the JavaScript which is shared. Okay. So what are the current activities in the projects? We've been going for half a year. We're being sponsored by an LNET. We still have about three months left of funding, well, not full-time, but part-time funding. And during this time, we want to improve the rendering of your documents because we're suddenly, if you open a document in WebODF, it certainly doesn't completely look like it would do in LibreOffice or Caligula right now. So there's still some questions and improvements to be made there. We're making API so that you can control the ODF canvas. If you want to write your own custom JavaScript HTML5 application, which just an ODF widget in there, it would be nice to have a nice API in there. We do have something, API where you can zoom in and out and where you can exchange parts of the document programmatically, but we want to extend that a bit to make it nicer. And of course, suggestions of people who are using the code are welcome. We want to have write support so we can actually save a file back. This is partially done already, and we want to support limited editing in the user interface. Not complete editing. You won't be able to completely modify a whole table. That's quite complicated. If somebody would like to write this code, they're more than welcome, but this is not our initial focus. And if you're interested in this code, it's only 3,000 lines of JavaScript right now, so you can check it out and become creative. Just put it on your web server and see what's missing. And I'm sure it's whatever is missing for you, it's easy to fix, unless it's some big feature. Okay, summarizing. Open document format is great. I guess all three speakers in this track will agree with that. The community for ODF is very active, and WebODF is great because it can bring ODF to websites and to many devices. And WebODF is also great because it doesn't mess around with your ODF. It just keeps it in your document as ODF. It doesn't convert it to some internal runtime. So WebODF makes ODF easy and fun. Thank you. So we now have actually 50 minutes for questions. Have you considered turning WebODF into a Firefox extension so that you can preview ODF files on sites which don't have WebODF installed? You can read ODF on what? So there's lots of ODF documents on the web, right? But in this system, the owner of the website has to install ODF.html on their domain in order to be able to preview them. If you took this code and made it into a browser extension, then the owner of the browser could preview any ODF document. That sounds like a very good idea. Yeah, I haven't thought about that because I wasn't aware that an extension might be able to handle a MIME type. Oh, absolutely. I don't know about other browsers, but certainly Firefox. It would be very easy to make this then. I think this has actually been tried before. There was a Firefox extension that did some very simple stuff, but you seem to have got a whole lot further. So it would be really interesting. I personally think that it would be a cool feature for Firefox to have in the core, eventually, a kind of preview mode for ODF files and would really drive ODF adoption. And if your code could get to a certain level of fidelity and a certain level of reliability, then why not? Yeah. Also, if it's an extension, you can just, when somebody clicks on it, you can open it, show it, but on the top have a big button saying, actually open it on your desktop. Yeah. Good suggestion. Are there any more questions? Oh, all the way up there. Where are you again? Maybe you have said it. I was a bit late, but what is the added value of Web ODF compared to native HTML? Well, that's native HTML isn't ODF. So if you have Office documents, which people are creating with LibreOffice, Microsoft Office, Caligra, and you also want to publish them on the Web, how are you going to do that? You need something for that. And I think Web ODF is a very nice way of doing that as true to the original document as HTML allows, so that HTML runtime allows. Any more questions? Yeah. Dan, here's a question. Sorry. I'm not sure if I remember correctly, but you said something like that since you modify directly the ODF out of the document model, then you re-render it into the HTML5 DOM. And this I think could be a problem for the speed, the performance of the program. Maybe it's unfeasible to do the other way around to keep true changes in sync or to use another document object model in the middle of, well, what you are doing currently, it will be outright, so it's not feasible. But do you think at least for the simple editing capabilities that you're planning to do now, it won't be a problem? Yes, I completely see where you see that there might be a performance problem. And for small documents, actually there's no performance problem because loading is pretty fast as well. I didn't actually show a benchmark here, but if you want to load, for example, the ODF specification, which is a 600-page document, it takes double as long as LibreOffice does it. It's about as fast as OpenOffice, but the latest LibreOffice release was quite a bit faster, so unfortunately I can't say anymore that it's comparable speed. It's double the speed right now, but it's pretty fast. Now that's of course the unzipping and then the rendering. If you just update the rendering, that certainly takes several hundred milliseconds for a decent document, and your suggestion of if there's an editor in one place, just do an update and only a fragment of the CSS I think makes sense. But I don't think you should change the CSS, and then when you start saving, then only at that point go back to the styles because then your programming logic becomes quite complex. It makes more sense to say, okay, the styles XML is sort of the real value, and the CSS is a reflection of it, but updating, it can be done in small parts to make it faster. Thank you. Right. Any more questions? There's a question. Behind you Jonathan. Yes, you said we can use WebODF in a Qt application. Could you list which Qt modules you may use for that? The Qt four modules, for example WebKit or some other modules? Yes, WebODF itself doesn't need Qt, but you can use the Qt WebKit module to display WebODF. In WebODF we have a small demo application, which is just a couple hundred lines of Qt C++, which basically embeds the JavaScript files, starts a Qt WebKit page, and then says, okay, now just render this. So all the application does is it says, okay, there's file access. The Web component is not allowed to access the file system usually, especially not via XML HTTP requests. So it just goes back to the Qt code, there's a binding for that, and then the Qt code will read the file and pass it on. But it's just a little bit of Qt code. Most of it is shared. So even if your application is Android, GTK, Qt, the whole layer should be quite small. Most of it is all JavaScript code. The native binding is something which you need to write dedicated code for. I'm currently publishing some ODF documents just by exporting them to HTML from OpenOffice. It's just a few, but I probably could automate that. Why would I move to WebODF? What would be the advantages? Well, you would do less work. You don't need to convert your documents because what you would do, I don't know what your Web server looks like. If it's just a page saying, okay, these are my documents, here are links to the HTML versions and here are links to the real documents. That's probably what it looks like. So what you would then do is you could remove the HTML link or at least change it to go to this odf.ml with the hash and then just link to the file. And you're saving a tiny bit of disk space because you don't need to store the HTML version. And also, I think that this version might look better, but I don't know what the converter looks like. Is it something which creates bitmaps or does it create, which filter are you using? Well, there are just a few pictures. It shouldn't be a problem, but I'll give it a try. Yeah, okay. There's nothing. Of course, if it's pictures, by the way, if it's pictures, you can't select text anymore. So, and here you can. Well, you had one slide briefly mentioning a project named ODFKit in the concept of WebKit. Is that superseded now by WebODF? Sorry, you're quite hard to understand. Can you speak up a bit? Is that better? Yeah. Okay. You mentioned a project on one slide called ODFKit. Yes. And in the context of WebKit, so assume it's C++ something or C. And you continue to talk about WebODF. So is WebODF now superseding the ODFKit or? No, they're separate projects. Okay. ODFKit came first, and ODFKit basically is as largest patch on WebKit to give WebKit support for ODF files. So we added some logic there to do unzipping and to go to read either the XML format or read the zip format and also load it into the DOM tree and then do some JavaScript work on that. However, when we were writing this, we saw that actually most of the things which we were patching WebKit for, you could just write in JavaScript, and that would be easier. So I do think that WebODF is a more elegant solution, but if you really want wall speed, then you can still, then ODFKit is nicer because then you have the unzipping support, for example, in the browser itself. That being said, I do think that, and we might actually submit a patch to the WebKit people saying, okay, why don't you add unzipped support as a faster version just by having it in C++ code? It would require an extension of their interfaces. Not sure if they would accept it, but yeah, it would benefit sort of everybody using WebKit and also WebODF would then be faster because it wouldn't need to implement that itself. The way JavaScript handles binary, binary arrays is basically non-existent. It's just an array of numbers. So that's really quite inefficient, but it's fast enough. All right. Are there any more questions? I don't see any, I think. Well, thank you all for your attention. Thanks to the speaker.
 Welcome everybody to the second talk in the office track.  This one will be different from the one before, different from the one after because it's  a very different project.  This project is not a decade old like the other ones, more than a decade.  It doesn't have a million lines of code, only 3,000 at the moment.  So it's all running in the browser.  So it's quite different than before.  I'd like to, by the way, thank Foslan for giving me the opportunity to speak here.  I really love this conference and by letting me speak here I really feel honored.  So let's start with the overview of the talk so you know what's coming.  I'll start with a small demo on how you can use WebODF on your website because it's so  very easy to use it.  I'm just going to start right off with that.  Then I'll go a bit into the history.  It's a young project about half a year old and I'll tell you how it came to be, why  we thought of this idea.  Then I'm going to explain a bit about what is ODF, what does the file format look like  and how can we put the information in the file inside of an HTML file.  Then I'll go into how you can write JavaScript for WebODF because it's a bit, we're quite  strict on how to write JavaScript.  It's not so easy as you might think.  And then at the end I'm going to show you how to use WebODF not on your website but  in your program.  So what's the goal of this project?  The goal of WebODF is that we're making a JavaScript HTML5 library that makes it easy  to add ODF to your website or your software.  So if you want to have a way of viewing ODF files, you are not dependent on a browser,  sorry, on a cloud service.  You can put it on your own website or your company server and it's easy to look at your  ODF files then.  We will also in the future add editing support and then you can also collaboratively in the  browser edit ODF documents and they will be exactly the same documents which you can  open in Microsoft Office, LibreOffice, OpenOffice, Kaleegra.  It doesn't matter.  And just because we're using JavaScript and HTML technology doesn't mean we are limited  to the browser.  In fact, it's very easy to use this technology to make an ODF application which runs on the  desktop or on a mobile phone or on a tablet.  And that's an example I will give of that at the end of the presentation.  So how to use WebODF?  What do you need?  You don't really need a lot.  You just check out the GitHub repository.  It's quite small and you need a web server.  That's all you need.  There's actually a small script inside of WebODF.  It contains a file called HTTPserver.js and that's a script which you can use with Node.js  to start a small web server.  And I'm going to use that for a small demonstration.  But you can just easily use Apache or any other web server.  So you take the web server or use the given script and you copy these files.  That's all of them.  So it's one ODF HTML.  That's basically the application.  A CSS file with the default styling.  The basic startup of the program, ODF.js, and the rest of the functionality is put into  classes in separate JavaScript files.  But it's just a couple of files you copy into the same directory.  Once you've done that, you have an ODF web server with ODF viewing capability.  What's missing then is just your files.  You take your ODF files, put them in the same directory or relative to the JavaScript,  and you're good to go.  So you can go to a URL which has a hash and then the name of the file.  So if you have a content management system, you want to have ODF support, just copy the  files in there, link up the documents which the user's upload with a simple hash to ODF  HTML and you're done.  So I'm going to demo that now.  In fact, I was demoing it all along because, as you can see, I'm running a web browser.  This is Chrome.  And what you see here is a URL.  So I'm running this on localhost.  The previous speaker had an objection to using HTML technology because the web might go  down and you can't use your software.  I'm just running this on localhost so there's absolutely no danger of this going down.  It's completely safe.  Yeah, and this is just a file.  So I'm presenting from this file.  I will go to here to show you.  This is the server running here, demo directory.  I'm calling the note executable with the HTTP server script which just does, if you send  a get to it, it will give you the file.  It's a very simple server.  And here are the files.  This is just a JavaScript.  So these are all the files in the directory.  See that the files are just listed, including then my report, ODT, the open document standard  which is something I will use to show you later, and a presentation and a spreadsheet.  So we're not just, I'm working now with a presentation, but we're also supporting spreadsheets  and text files.  So this is the same.  This is a different version here.  I wrote a small UI into it.  This is not the standard part of WebODF, but it's an example of how you can use it in a  more sophisticated application.  So this is just an XGS.  It's a JavaScript library with which you can build UIs.  And here it's listing some files.  So you can open it, and here's a different presentation.  So you see it's got styles.  It's got pictures.  Here's a big spreadsheet.  It takes a bit longer to open, but not really not.  If you consider the size of this file, it has colors for styles, colors for the cells,  and basically it looks pretty good.  So that's how you use it.  Now how did it come to be?  Why did we think of opening or writing an application which can easily allow you to  view ODF documents in your browser?  Oh, spacebar stopped working.  Yeah.  Well, for that I have to start a WebKit.  I guess many people know WebKit.  The browser I'm using now is Chrome.  It's also built on WebKit.  It has a history of long ago.  It started in the KDE project where the browser was KHTML, and that was a very popular browser.  It was pretty good at the time, and so good that at some point Apple decided to fork it  and make it into the Safari web browser.  At this time, Mozilla was the most popular open source browser, and they didn't choose  Mozilla because they liked the design of KHTML better.  So initially, Apple wasn't behaving very much as a nice open source citizen in the sense  that when it made a new Safari release, what it did was it just dumped a tarball of the  source code.  But after a couple of years and complaining about it by the KHTML developers that they  wanted a more open development process, Apple started the WebKit project.  So it became really a proper nice project.  From that point on, it gained more ports.  That led to Chrome, GTK WebKit, Qt WebKit, and many other adaptations of WebKit.  And now, nearly every computer has a version of WebKit running.  By computer, I also mean mobile phones and tablets.  So it's pervasive.  It's a huge success.  And within our company, KO, we were thinking, well, can we repeat this for OfficeWeets?  So to see why WebKit is so successful, we have to go back a bit and look at how it works  on the inside.  If you have all these different environments for which there are ports and you look at,  for example, the string class for them.  Most prices are written in C++.  But C++ is different on every platform.  In KDE, you have a queue string.  Mac OS has an NS string.  CF, I don't actually know what that's meant to replace that.  WeXWidgets has a reX string and a Hyku has a B string.  So there are many different strings.  And people can get very obsessed about what type of string they're using.  And not just the strings, it's also the vectors.  It's also the graphical interface which we're talking to.  The clever thing Apple did with WebKit when it ported it from the queue string and the  whole queue environment to Mac OS is that they abstracted away all of these things.  So they made it possible to implement a few abstract platform-dependent classes and then  have a native application, a native WebKit environment.  And that's why the adoption was so great.  Now we would like to repeat that.  At the time we wanted to repeat that, this was an inspiration for a project which we  called ODFKit.  And since most free open source software is also written in C++, but also the libraries  are different.  I mean, LibreOffice, Kalihra, and AbiWorth all have different string types and the different  widget sets.  We thought, well, why don't we take the WebKit approach and build on that?  So ODFKit was born and it used the WebKit approach.  And the initial scope was to have a server-side handling of ODF documents.  So we didn't want to go do graphical route.  First we'll say, OK, is this idea of loading, saving ODF documents on different C++ frameworks  is that feasible?  And we started working on it and one of the excellent things of WebKit is that they have  a very good test environment.  They have tons and tons of tests.  And these tests are all written in HTML with some JavaScript to run them.  So we are also writing a lot of unit tests.  And our unit tests were reading ODF files.  And at some point I was thinking, well, why do we need to have the unzipping inside of  the ODFKit part, can we move it to the JavaScript side?  And in fact, there are GZ libraries written in JavaScript.  So I started playing and at some point I didn't have any C++ left.  I just had my JavaScript.  And I thought, well, OK, so it's possible in a browser, and I tested it not just with  WebKit but also with Opera Firefox, it's possible to unzip a file purely in JavaScript, then  take the custom XML and put it into a web page.  And that's how Web ODF got started.  So now I'll tell you a bit about what ODF looks like and how you can put it inside an  HTML page.  So ODF, it's a great standard.  All three Officeweeds in this Office track today use ODF as their main file format.  It reuses many technologies, XML, zip, URLs, XS, RF, RDF recently since version 1.2.  And I think that's a great addition.  I won't go into too much what it is right now.  Scalable vector graphics, Xqueries.  And it's very active.  There's a weekly call of the people working on the standard.  And they are all from different vendors.  They're talking together about how to improve the standard.  And a couple of years, there's a plug-fest where implementers from different versions  of different ODF software come together and see if their ODF documents actually work together  well.  There are many implementations.  Kalira, LibreOffice, well, you know most of these.  The ones on this side are actually cloud services, well, Microsoft Office is also a desktop application  but also has a cloud service.  And the growth of cloud service was actually one of the reasons why we said that Web ODF  would be important because more people want to work on documents in the browser.  But they don't always want to put their documents on a Google server or on a Microsoft server.  So how does Web ODF work?  Well, you start with an HTML file.  And in your HTML file, you figure out what the path to the zip file is and you start  loading it.  The loading is usually done with an HTML HTTP request, which gets the binary data and it  doesn't get the whole file at once.  If you have a file with large images, it will not get that at once it will be too slow.  So we will first get the index of the zip file, then it will get all the bits which are important  to load.  The content XML file, which is the most important file, the settings XML, the styles XML file.  And then it will put the information which is in there in the DOM tree which forms your  HTML document.  Then you've got a lot of XML added to your document.  And the HTML standard says if it doesn't recognize a tag, it will do nothing with it.  So any normal text which is in there is just shown as plain text.  And it doesn't look like an Office document, let alone a spreadsheet at all.  So what we need to do is we need to use CSS with namespace support and I'll show you later  how that works to hide and show the important bits and to format them on a page, on a slide  or in a spreadsheet cells.  Then we look at what the custom styles are, the bold, the italic, the font used, the size  of the font and we also convert that to CSS so that the file in itself looks good.  And after that, we load the images.  So that's basically all the different steps and we'll go into each of these in more detail  now.  So most ODF files are zip files, not all of them, and they contain XML files and pictures.  HTML has one DOM, so it's usually an XML file or at least if it's not a proper XML  file it will be read as one, it will be corrected.  ODF has a different serialization, so the problem is, HTML has one DOM, but in a ODF  file there are many zip files, so which, sorry, many XML files, which of the XML files will  you actually put in the HTML DOM or how will you put it in there?  Well, there's a solution for that because the ODF standard has a different serialization  which is just one XML file.  Everybody's using it, actually, or not really, but it's still useful.  The fact that it's in the standard gives us at Web ODF a good idea of how to put the  different parts which are normally in a zip file into one DOM tree.  And this is what this will look like.  So here's the HTML.  This is the live tree.  I've collapsed the head and you see the body.  That's an HTML body and then the document tag there, that's an office tag.  It's in the office namespace.  It's not shown like that.  That's just something typical in the way Chrome shows this.  And then you see different tags and each of those tags contains parts from the different  XML files in an ODF file.  So by following the standard, we can put all the components inside of one DOM tree.  And once we have it there, we can do lots of stuff.  I mean, suppose you would like to do some editing or custom scripting.  You could just go wild with JavaScript like you do with HTML pages and modify it to your  heart's content.  It's all available with the DOM API now.  So that's step one.  We've got the whole document loaded in the DOM tree, but it doesn't look very good yet.  So what do we do?  We want to use the styling information.  But the styling used by ODF is not the same as HTML.  HTML uses CSS, CSS3 by now, and that's quite different from the styles in ODF which are  based on XSLfo.  So we need to convert it.  But there are two issues.  ODF uses style names.  So whenever you have a style, you just say, OK, this element has this style.  This element has that style.  Whereas in CSS, you have selectives.  You say, OK, this is a div and all divs which are inside of a paragraph or which have an  ID like this should be green.  So it's a bit different.  And the properties themselves are different.  So if bold might have a different name, then bold in ODF might have a different name than  bold in CSS.  Well, for bold, actually, it is the same, but there are many tweaks you have to do.  So here's an example.  This top part is an extract from styles.xml, and it defines a style called myBold.  And basically what it says is, OK, text property, this is bold.  And then below, you see how we would convert this so that the browser shows us properly.  You see text pipe p.  Now the pipe is the equivalent of the colon in XML.  It's a divider between the namespace prefix and the local name.  Then you see the angular brackets.  And the angular brackets say, if the text style name is myBold, then this applies.  So we have directly translated the selector based on just name to below the selector based  on a paragraph with that name.  Of course, there's not just paragraphs.  You have also headers and lots of other elements.  And all of these elements will have to have the same rules.  So in practice, we have to repeat this rule quite a few times to cover all of the styling.  And you'll see that later when I show you some introspection in the browser.  So that's basically how the conversion works, and you see that I should go back one step.  What we're doing here is because we're changing the styles into a CSS, but when we're editing,  we will first edit the top part.  So we'll change the actual ODF, and then redo the translation.  So when we're editing, which we're actually not supporting yet, but which we're planning,  we will be editing the actual ODF, and then we calculate what CSS looks like.  And this brings us to a point, a problem with many Office suites is that they usually try  to warn you from using ODF, or they try to warn you from the document which is not your  native format.  Microsoft doesn't like you using open document formats.  Well, it doesn't even matter if they like it or not.  Their runtime model is quite different from what ODF looks like, and that's why some features  may be lost when you're saving.  Unfortunately, they never tell you which features exactly so that you could make a reasoned decision  on whether or not to use ODF or not.  But the same thing goes for LibreOffice, for example.  When you're opening something in ODF and you want to save it as PowerPoint, they will give  you the same warning.  They'll say, yeah, we're not sure if PowerPoint has exactly the same features, so are you  really sure that you want to use it?  Well, in ODF, our runtime model is ODF, just like the model which we're saving.  So there is very little difference.  It's just the XML which you have on disk is the way it looks in the browser.  And I want to give a small demonstration of that by actually just going and looking inside  of this browser now.  So this is the live document.  And by the way, do you know what this is?  This in office text editor terms, you call this an underwater screen.  It was popular and worked perfect.  And basically in the browser, it's back.  You can actually see what your document looks like.  So you see here the XML.  And here you see if you select an element, for example, the first page, you see what  CSS applies to it.  So you can directly see when you're developing or improving web ODF if the CSS translation  is correct.  And you can even see where it was defined.  OK.  But that's just the underwater screen.  OK.  The next part will be a bit of a JavaScript.  Because writing JavaScript is something many people like to do, but few people like to  learn.  The problem with JavaScript is it's quite flawed.  There are many problems with it.  But you can avoid the problems.  And that's what I want to go into a bit right here.  You have to be very careful when writing JavaScript.  But with the right tools, it's a doddle.  It's just fine.  Just you have to be aware of them.  So I want to talk a bit about that now.  So these are the practices which I want to talk about quickly.  So you have to use the good parts of JavaScript.  There are many bad parts.  You want to use JSLint, which is just a checker, which checks is my JavaScript good.  You want to use runtime abstraction.  And we really need that here, because web ODF might be running in a browser.  It might be running on a command line.  It might be running in a native application.  So we are abstracting that way in our project.  You want to use callbacks for fast IO.  And you want to compile your JavaScript using the closure compiler.  And of course, use a lot of unit tests.  So the first part.  I saw that a standard of a Rylea, that the biggest sponsor of the event.  So I think it's good that I say this is an excellent book.  And you should probably buy it if you want to write JavaScript.  It's called JavaScript the Good Parts.  And it explains which part of JavaScript are bad and which you should avoid.  And yeah, it's a very thin book.  It's a great read.  I think you should really have a look at it.  The author of the book also wrote a program called JSLint.  And JSLint will tell you what, if you're using a bad part of JavaScript.  So you can avoid it.  So the runtime.  WebODF runs in different runtimes.  And the only common thing between all the runtimes is that, of course, they're all JavaScript.  And some may have a DOM.  If they don't have a DOM, you cannot do anything.  You cannot do everything.  But you can still do the unzipping, for example.  You can still do base64 encoding.  And the runtime is a thin abstraction layer that gives you access to the file system,  logging, use of timers, the window object.  And we have currently runtimes for the browser, for Node.js, which is the server which is  currently running this presentation.  And Rhino, which is a JavaScript implementation.  You should also use callbacks.  This is a very cool feature of JavaScript.  And since IEO is often the bottleneck in your application, instead of waiting for an event  that may be slow, you should pass a function.  So here's a function loadxml.  We want to read the file myfile.xml.  Instead of waiting for the result, we just pass along a function.  And the function has two arguments, error and data.  And if the loading has been done, then this function will be called with either the error  message or the data.  So because the function loadxml itself returns immediately, sending a request to the file  system and then hanging this function on there, it can immediately continue with all  of the rest of your applications.  So your application becomes a bit faster, quite a bit faster.  Well, it's very important to write unit tests.  It's tricky to write a program which runs in a browser.  I mean, browsers are so different.  They're getting much better, but they're still very different.  So you really need to test a lot.  And also, I have to admit, I didn't mention this yet.  But we are not even supporting Internet Explorer at all right now because it's not worth it.  I looked at Internet Explorer 9, and we might support that.  It's a lot better, but I'm not sure it's following the standards good enough.  We tried, when we endowed on how to develop something, we just read the standards and  use that.  And if Internet Explorer adheres to that, we may start using that.  I don't see that as a big problem for adoption of the project because if you want to use  a native application, you're free to choose any browser you like.  A WebKit component, for example.  If you want to use it on an Internet, you control who is using that browser.  So selecting on quality of browser is not really an issue, I think.  So we also test with command line programs just so that we can do unit testing easily.  We don't have to press reload in all the browsers.  We can just run something on the command line.  Instrumenting the code, there's a very cool tool called the JS coverage.  What you do is you run an executable over your JavaScript code, and it will instrument  it.  That means it will add monitors in all of your code, and then when you run your tests,  it will tell you how often every line of your code was executed.  And that's very good because you can check if you are actually testing all of your application.  Okay, Node.js, I want to say a few things about that because you want to run unit tests  on the command line.  Node.js is a V8 engine.  It's the JavaScript engine which is in Chrome, and it uses callbacks extensively, so it's  very good for a server.  If you want to implement a server in JavaScript, well, this is the thing you need.  It's really up and coming.  We're also using Rhino.  It's a very slow JavaScript engine, and it doesn't use callbacks, so the reason why we're  using that is because it's so different.  Because the callbacks do need special attention.  You need to make sure that if you pass a callback that you don't need it before you actually  leave the current execution loop.  And lastly, we're using Qt WebKit because neither Node.js nor Rhino has a DOM, and we  also would like to do tests on the DOM on the command line.  So we have Qt WebKit which runs with no user interface, and which we can do more testing  with.  Okay, next in the list of tools which you want to use with JavaScript is a Closure compiler.  Since what does it do?  It combines all your JavaScript files into one big file and optimizes that, and in itself  that's not really too important for this project because the code isn't so huge, but  it also does syntax checking, and it also does type checking.  So instead of waiting for your browser to give an error, you can already on the command  line see if your code is any good.  How does this type checking work?  Below here is a small code fragment, and you basically, you set comments saying what type  every argument to your code is.  And even if you pass a callback function, you can say what the arguments to the callback  function should be.  And it's surprising how many type errors this will catch.  Okay, that was most of the talk already.  I would like to at the end show a way of how to use WebODF in your own program.  If you download the code, you'll see two examples there.  One example is to use WebODF in a Qt application where you're using Qt WebKit and you create  a canvas where you can load ODF documents.  And another example which is in there is to make an Android application which could show  ODF documents.  At the moment, there's no decent application on Android to show ODF documents.  And this one is also just a demo.  So it's not released as a decent solution which is in the marketplace yet, but it's  very small because most of the code is in the JavaScript which is shared.  And it would be very easy also to make, for example, an iPhone or a BlackBerry version  of this application.  So this is a small excerpt of the code of it.  It's basically two classes.  And here you see some of the magic happening.  Here, what you do is you load this ODF.HTML file in your WebKit widget.  And when it's loaded, you change the current runtime.  You change the read function.  You change the function for the get file size.  And once you've done that, then you instantiate a new ODF container.  So we're overloading two functions.  And then this gives our application the ability to read any file on the file system.  So the advantage of this application is that it can actually show you files which are on  your disk.  And I'll run it now.  It's here.  So this is the simulator.  It's an older version of Android.  I purposefully used an older version to show that it also works there.  You don't need all the new features in Android to get this running.  So here it goes.  Let's open a spreadsheet.  The emulator is a bit slow.  And then the device will be faster.  So here you see very simple spreadsheets.  Let's open a small text file.  And you see that this is just a, it's really just an HTML page, but also Android Proverger  with nice UI here.  And yeah, it's a very small application.  Most of it is just the JavaScript which is shared.  Okay.  So what are the current activities in the projects?  We've been going for half a year.  We're being sponsored by an LNET.  We still have about three months left of funding, well, not full-time, but part-time funding.  And during this time, we want to improve the rendering of your documents because we're  suddenly, if you open a document in WebODF, it certainly doesn't completely look like  it would do in LibreOffice or Caligula right now.  So there's still some questions and improvements to be made there.  We're making API so that you can control the ODF canvas.  If you want to write your own custom JavaScript HTML5 application, which just an ODF widget  in there, it would be nice to have a nice API in there.  We do have something, API where you can zoom in and out and where you can exchange parts  of the document programmatically, but we want to extend that a bit to make it nicer.  And of course, suggestions of people who are using the code are welcome.  We want to have write support so we can actually save a file back.  This is partially done already, and we want to support limited editing in the user interface.  Not complete editing.  You won't be able to completely modify a whole table.  That's quite complicated.  If somebody would like to write this code, they're more than welcome, but this is not  our initial focus.  And if you're interested in this code, it's only 3,000 lines of JavaScript right now,  so you can check it out and become creative.  Just put it on your web server and see what's missing.  And I'm sure it's whatever is missing for you, it's easy to fix, unless it's some big  feature.  Okay, summarizing.  Open document format is great.  I guess all three speakers in this track will agree with that.  The community for ODF is very active, and WebODF is great because it can bring ODF to  websites and to many devices.  And WebODF is also great because it doesn't mess around with your ODF.  It just keeps it in your document as ODF.  It doesn't convert it to some internal runtime.  So WebODF makes ODF easy and fun.  Thank you.  So we now have actually 50 minutes for questions.  Have you considered turning WebODF into a Firefox extension so that you can preview  ODF files on sites which don't have WebODF installed?  You can read ODF on what?  So there's lots of ODF documents on the web, right?  But in this system, the owner of the website has to install ODF.html on their domain in  order to be able to preview them.  If you took this code and made it into a browser extension, then the owner of the browser could  preview any ODF document.  That sounds like a very good idea.  Yeah, I haven't thought about that because I wasn't aware that an extension might be  able to handle a MIME type.  Oh, absolutely.  I don't know about other browsers, but certainly Firefox.  It would be very easy to make this then.  I think this has actually been tried before.  There was a Firefox extension that did some very simple stuff, but you seem to have got  a whole lot further.  So it would be really interesting.  I personally think that it would be a cool feature for Firefox to have in the core, eventually,  a kind of preview mode for ODF files and would really drive ODF adoption.  And if your code could get to a certain level of fidelity and a certain level of reliability,  then why not?  Yeah.  Also, if it's an extension, you can just, when somebody clicks on it, you can open it,  show it, but on the top have a big button saying, actually open it on your desktop.  Yeah.  Good suggestion.  Are there any more questions?  Oh, all the way up there.  Where are you again?  Maybe you have said it.  I was a bit late, but what is the added value of Web ODF compared to native HTML?  Well, that's native HTML isn't ODF.  So if you have Office documents, which people are creating with LibreOffice, Microsoft Office,  Caligra, and you also want to publish them on the Web, how are you going to do that?  You need something for that.  And I think Web ODF is a very nice way of doing that as true to the original document  as HTML allows, so that HTML runtime allows.  Any more questions?  Yeah.  Dan, here's a question.  Sorry.  I'm not sure if I remember correctly, but you said something like that since you modify  directly the ODF out of the document model, then you re-render it into the HTML5 DOM.  And this I think could be a problem for the speed, the performance of the program.  Maybe it's unfeasible to do the other way around to keep true changes in sync or to use  another document object model in the middle of, well, what you are doing currently, it  will be outright, so it's not feasible.  But do you think at least for the simple editing capabilities that you're planning to do now,  it won't be a problem?  Yes, I completely see where you see that there might be a performance problem.  And for small documents, actually there's no performance problem because loading is pretty  fast as well.  I didn't actually show a benchmark here, but if you want to load, for example, the ODF  specification, which is a 600-page document, it takes double as long as LibreOffice does  it.  It's about as fast as OpenOffice, but the latest LibreOffice release was quite a bit  faster, so unfortunately I can't say anymore that it's comparable speed.  It's double the speed right now, but it's pretty fast.  Now that's of course the unzipping and then the rendering.  If you just update the rendering, that certainly takes several hundred milliseconds for a decent  document, and your suggestion of if there's an editor in one place, just do an update  and only a fragment of the CSS I think makes sense.  But I don't think you should change the CSS, and then when you start saving, then only  at that point go back to the styles because then your programming logic becomes quite  complex.  It makes more sense to say, okay, the styles XML is sort of the real value, and the CSS  is a reflection of it, but updating, it can be done in small parts to make it faster.  Thank you.  Right.  Any more questions?  There's a question.  Behind you Jonathan.  Yes, you said we can use WebODF in a Qt application.  Could you list which Qt modules you may use for that?  The Qt four modules, for example WebKit or some other modules?  Yes, WebODF itself doesn't need Qt, but you can use the Qt WebKit module to display WebODF.  In WebODF we have a small demo application, which is just a couple hundred lines of Qt  C++, which basically embeds the JavaScript files, starts a Qt WebKit page, and then  says, okay, now just render this.  So all the application does is it says, okay, there's file access.  The Web component is not allowed to access the file system usually, especially not via  XML HTTP requests.  So it just goes back to the Qt code, there's a binding for that, and then the Qt code will  read the file and pass it on.  But it's just a little bit of Qt code.  Most of it is shared.  So even if your application is Android, GTK, Qt, the whole layer should be quite small.  Most of it is all JavaScript code.  The native binding is something which you need to write dedicated code for.  I'm currently publishing some ODF documents just by exporting them to HTML from OpenOffice.  It's just a few, but I probably could automate that.  Why would I move to WebODF?  What would be the advantages?  Well, you would do less work.  You don't need to convert your documents because what you would do, I don't know what your  Web server looks like.  If it's just a page saying, okay, these are my documents, here are links to the HTML versions  and here are links to the real documents.  That's probably what it looks like.  So what you would then do is you could remove the HTML link or at least change it to go  to this odf.ml with the hash and then just link to the file.  And you're saving a tiny bit of disk space because you don't need to store the HTML  version.  And also, I think that this version might look better, but I don't know what the converter  looks like.  Is it something which creates bitmaps or does it create, which filter are you using?  Well, there are just a few pictures.  It shouldn't be a problem, but I'll give it a try.  Yeah, okay.  There's nothing.  Of course, if it's pictures, by the way, if it's pictures, you can't select text anymore.  So, and here you can.  Well, you had one slide briefly mentioning a project named ODFKit in the concept of  WebKit.  Is that superseded now by WebODF?  Sorry, you're quite hard to understand.  Can you speak up a bit?  Is that better?  Yeah.  Okay.  You mentioned a project on one slide called ODFKit.  Yes.  And in the context of WebKit, so assume it's C++ something or C.  And you continue to talk about WebODF.  So is WebODF now superseding the ODFKit or?  No, they're separate projects.  Okay.  ODFKit came first, and ODFKit basically is as largest patch on WebKit to give WebKit  support for ODF files.  So we added some logic there to do unzipping and to go to read either the XML format or  read the zip format and also load it into the DOM tree and then do some JavaScript work  on that.  However, when we were writing this, we saw that actually most of the things which we  were patching WebKit for, you could just write in JavaScript, and that would be easier.  So I do think that WebODF is a more elegant solution, but if you really want wall speed,  then you can still, then ODFKit is nicer because then you have the unzipping support,  for example, in the browser itself.  That being said, I do think that, and we might actually submit a patch to the WebKit people  saying, okay, why don't you add unzipped support as a faster version just by having it in C++  code?  It would require an extension of their interfaces.  Not sure if they would accept it, but yeah, it would benefit sort of everybody using WebKit  and also WebODF would then be faster because it wouldn't need to implement that itself.  The way JavaScript handles binary, binary arrays is basically non-existent.  It's just an array of numbers.  So that's really quite inefficient, but it's fast enough.  All right.  Are there any more questions?  I don't see any, I think.  Well, thank you all for your attention.  Thanks to the speaker.
webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_0_131.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_132_179.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_180_239.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_240_1103.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_1104_4175.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_4176_4235.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_4236_5915.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_5916_6623.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_6624_6707.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_6708_7583.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_7584_7667.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_7668_8063.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_8064_8147.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_8148_8315.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_8316_8747.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_8748_8915.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_8916_9443.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_9444_9527.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_9528_9575.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_9576_9659.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_9660_9731.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_9732_9779.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_9780_9827.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_9828_9911.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_9912_10067.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_10068_10139.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_10140_10511.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_10512_17579.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_17580_17927.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_17928_32483.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_32484_32531.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_32532_32591.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_32592_32639.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_32640_33947.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_33948_33995.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_33996_34187.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_34188_35015.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_35016_36107.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_36108_45131.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_45132_46511.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_46512_47831.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_47832_47879.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_47880_47927.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_47928_48227.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_48228_48287.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_48288_48335.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_48336_48479.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_48480_48575.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_48576_48647.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_48648_48803.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_48804_49067.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_49068_49175.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_49176_49319.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_49320_68543.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_68544_68603.png webODF__an_office_suite_built_on_browser_technolog_TpAsk69vI0k_1_68604_68754.png
Welcome everybody to the second talk in the office track. This one will be different from the one before, different from the one after because it's a very different project. This project is not a decade old like the other ones, more than a decade. It doesn't have a million lines of code, only 3,000 at the moment. So it's all running in the browser. So it's quite different than before. I'd like to, by the way, thank Foslan for giving me the opportunity to speak here. I really love this conference and by letting me speak here I really feel honored. So let's start with the overview of the talk so you know what's coming. I'll start with a small demo on how you can use WebODF on your website because it's so very easy to use it. I'm just going to start right off with that. Then I'll go a bit into the history. It's a young project about half a year old and I'll tell you how it came to be, why we thought of this idea. Then I'm going to explain a bit about what is ODF, what does the file format look like and how can we put the information in the file inside of an HTML file. Then I'll go into how you can write JavaScript for WebODF because it's a bit, we're quite strict on how to write JavaScript. It's not so easy as you might think. And then at the end I'm going to show you how to use WebODF not on your website but in your program. So what's the goal of this project? The goal of WebODF is that we're making a JavaScript HTML5 library that makes it easy to add ODF to your website or your software. So if you want to have a way of viewing ODF files, you are not dependent on a browser, sorry, on a cloud service. You can put it on your own website or your company server and it's easy to look at your ODF files then. We will also in the future add editing support and then you can also collaboratively in the browser edit ODF documents and they will be exactly the same documents which you can open in Microsoft Office, LibreOffice, OpenOffice, Kaleegra. It doesn't matter. And just because we're using JavaScript and HTML technology doesn't mean we are limited to the browser. In fact, it's very easy to use this technology to make an ODF application which runs on the desktop or on a mobile phone or on a tablet. And that's an example I will give of that at the end of the presentation. So how to use WebODF? What do you need? You don't really need a lot. You just check out the GitHub repository. It's quite small and you need a web server. That's all you need. There's actually a small script inside of WebODF. It contains a file called HTTPserver.js and that's a script which you can use with Node.js to start a small web server. And I'm going to use that for a small demonstration. But you can just easily use Apache or any other web server. So you take the web server or use the given script and you copy these files. That's all of them. So it's one ODF HTML. That's basically the application. A CSS file with the default styling. The basic startup of the program, ODF.js, and the rest of the functionality is put into classes in separate JavaScript files. But it's just a couple of files you copy into the same directory. Once you've done that, you have an ODF web server with ODF viewing capability. What's missing then is just your files. You take your ODF files, put them in the same directory or relative to the JavaScript, and you're good to go. So you can go to a URL which has a hash and then the name of the file. So if you have a content management system, you want to have ODF support, just copy the files in there, link up the documents which the user's upload with a simple hash to ODF HTML and you're done. So I'm going to demo that now. In fact, I was demoing it all along because, as you can see, I'm running a web browser. This is Chrome. And what you see here is a URL. So I'm running this on localhost. The previous speaker had an objection to using HTML technology because the web might go down and you can't use your software. I'm just running this on localhost so there's absolutely no danger of this going down. It's completely safe. Yeah, and this is just a file. So I'm presenting from this file. I will go to here to show you. This is the server running here, demo directory. I'm calling the note executable with the HTTP server script which just does, if you send a get to it, it will give you the file. It's a very simple server. And here are the files. This is just a JavaScript. So these are all the files in the directory. See that the files are just listed, including then my report, ODT, the open document standard which is something I will use to show you later, and a presentation and a spreadsheet. So we're not just, I'm working now with a presentation, but we're also supporting spreadsheets and text files. So this is the same. This is a different version here. I wrote a small UI into it. This is not the standard part of WebODF, but it's an example of how you can use it in a more sophisticated application. So this is just an XGS. It's a JavaScript library with which you can build UIs. And here it's listing some files. So you can open it, and here's a different presentation. So you see it's got styles. It's got pictures. Here's a big spreadsheet. It takes a bit longer to open, but not really not. If you consider the size of this file, it has colors for styles, colors for the cells, and basically it looks pretty good. So that's how you use it. Now how did it come to be? Why did we think of opening or writing an application which can easily allow you to view ODF documents in your browser? Oh, spacebar stopped working. Yeah. Well, for that I have to start a WebKit. I guess many people know WebKit. The browser I'm using now is Chrome. It's also built on WebKit. It has a history of long ago. It started in the KDE project where the browser was KHTML, and that was a very popular browser. It was pretty good at the time, and so good that at some point Apple decided to fork it and make it into the Safari web browser. At this time, Mozilla was the most popular open source browser, and they didn't choose Mozilla because they liked the design of KHTML better. So initially, Apple wasn't behaving very much as a nice open source citizen in the sense that when it made a new Safari release, what it did was it just dumped a tarball of the source code. But after a couple of years and complaining about it by the KHTML developers that they wanted a more open development process, Apple started the WebKit project. So it became really a proper nice project. From that point on, it gained more ports. That led to Chrome, GTK WebKit, Qt WebKit, and many other adaptations of WebKit. And now, nearly every computer has a version of WebKit running. By computer, I also mean mobile phones and tablets. So it's pervasive. It's a huge success. And within our company, KO, we were thinking, well, can we repeat this for OfficeWeets? So to see why WebKit is so successful, we have to go back a bit and look at how it works on the inside. If you have all these different environments for which there are ports and you look at, for example, the string class for them. Most prices are written in C++. But C++ is different on every platform. In KDE, you have a queue string. Mac OS has an NS string. CF, I don't actually know what that's meant to replace that. WeXWidgets has a reX string and a Hyku has a B string. So there are many different strings. And people can get very obsessed about what type of string they're using. And not just the strings, it's also the vectors. It's also the graphical interface which we're talking to. The clever thing Apple did with WebKit when it ported it from the queue string and the whole queue environment to Mac OS is that they abstracted away all of these things. So they made it possible to implement a few abstract platform-dependent classes and then have a native application, a native WebKit environment. And that's why the adoption was so great. Now we would like to repeat that. At the time we wanted to repeat that, this was an inspiration for a project which we called ODFKit. And since most free open source software is also written in C++, but also the libraries are different. I mean, LibreOffice, Kalihra, and AbiWorth all have different string types and the different widget sets. We thought, well, why don't we take the WebKit approach and build on that? So ODFKit was born and it used the WebKit approach. And the initial scope was to have a server-side handling of ODF documents. So we didn't want to go do graphical route. First we'll say, OK, is this idea of loading, saving ODF documents on different C++ frameworks is that feasible? And we started working on it and one of the excellent things of WebKit is that they have a very good test environment. They have tons and tons of tests. And these tests are all written in HTML with some JavaScript to run them. So we are also writing a lot of unit tests. And our unit tests were reading ODF files. And at some point I was thinking, well, why do we need to have the unzipping inside of the ODFKit part, can we move it to the JavaScript side? And in fact, there are GZ libraries written in JavaScript. So I started playing and at some point I didn't have any C++ left. I just had my JavaScript. And I thought, well, OK, so it's possible in a browser, and I tested it not just with WebKit but also with Opera Firefox, it's possible to unzip a file purely in JavaScript, then take the custom XML and put it into a web page. And that's how Web ODF got started. So now I'll tell you a bit about what ODF looks like and how you can put it inside an HTML page. So ODF, it's a great standard. All three Officeweeds in this Office track today use ODF as their main file format. It reuses many technologies, XML, zip, URLs, XS, RF, RDF recently since version 1.2. And I think that's a great addition. I won't go into too much what it is right now. Scalable vector graphics, Xqueries. And it's very active. There's a weekly call of the people working on the standard. And they are all from different vendors. They're talking together about how to improve the standard. And a couple of years, there's a plug-fest where implementers from different versions of different ODF software come together and see if their ODF documents actually work together well. There are many implementations. Kalira, LibreOffice, well, you know most of these. The ones on this side are actually cloud services, well, Microsoft Office is also a desktop application but also has a cloud service. And the growth of cloud service was actually one of the reasons why we said that Web ODF would be important because more people want to work on documents in the browser. But they don't always want to put their documents on a Google server or on a Microsoft server. So how does Web ODF work? Well, you start with an HTML file. And in your HTML file, you figure out what the path to the zip file is and you start loading it. The loading is usually done with an HTML HTTP request, which gets the binary data and it doesn't get the whole file at once. If you have a file with large images, it will not get that at once it will be too slow. So we will first get the index of the zip file, then it will get all the bits which are important to load. The content XML file, which is the most important file, the settings XML, the styles XML file. And then it will put the information which is in there in the DOM tree which forms your HTML document. Then you've got a lot of XML added to your document. And the HTML standard says if it doesn't recognize a tag, it will do nothing with it. So any normal text which is in there is just shown as plain text. And it doesn't look like an Office document, let alone a spreadsheet at all. So what we need to do is we need to use CSS with namespace support and I'll show you later how that works to hide and show the important bits and to format them on a page, on a slide or in a spreadsheet cells. Then we look at what the custom styles are, the bold, the italic, the font used, the size of the font and we also convert that to CSS so that the file in itself looks good. And after that, we load the images. So that's basically all the different steps and we'll go into each of these in more detail now. So most ODF files are zip files, not all of them, and they contain XML files and pictures. HTML has one DOM, so it's usually an XML file or at least if it's not a proper XML file it will be read as one, it will be corrected. ODF has a different serialization, so the problem is, HTML has one DOM, but in a ODF file there are many zip files, so which, sorry, many XML files, which of the XML files will you actually put in the HTML DOM or how will you put it in there? Well, there's a solution for that because the ODF standard has a different serialization which is just one XML file. Everybody's using it, actually, or not really, but it's still useful. The fact that it's in the standard gives us at Web ODF a good idea of how to put the different parts which are normally in a zip file into one DOM tree. And this is what this will look like. So here's the HTML. This is the live tree. I've collapsed the head and you see the body. That's an HTML body and then the document tag there, that's an office tag. It's in the office namespace. It's not shown like that. That's just something typical in the way Chrome shows this. And then you see different tags and each of those tags contains parts from the different XML files in an ODF file. So by following the standard, we can put all the components inside of one DOM tree. And once we have it there, we can do lots of stuff. I mean, suppose you would like to do some editing or custom scripting. You could just go wild with JavaScript like you do with HTML pages and modify it to your heart's content. It's all available with the DOM API now. So that's step one. We've got the whole document loaded in the DOM tree, but it doesn't look very good yet. So what do we do? We want to use the styling information. But the styling used by ODF is not the same as HTML. HTML uses CSS, CSS3 by now, and that's quite different from the styles in ODF which are based on XSLfo. So we need to convert it. But there are two issues. ODF uses style names. So whenever you have a style, you just say, OK, this element has this style. This element has that style. Whereas in CSS, you have selectives. You say, OK, this is a div and all divs which are inside of a paragraph or which have an ID like this should be green. So it's a bit different. And the properties themselves are different. So if bold might have a different name, then bold in ODF might have a different name than bold in CSS. Well, for bold, actually, it is the same, but there are many tweaks you have to do. So here's an example. This top part is an extract from styles.xml, and it defines a style called myBold. And basically what it says is, OK, text property, this is bold. And then below, you see how we would convert this so that the browser shows us properly. You see text pipe p. Now the pipe is the equivalent of the colon in XML. It's a divider between the namespace prefix and the local name. Then you see the angular brackets. And the angular brackets say, if the text style name is myBold, then this applies. So we have directly translated the selector based on just name to below the selector based on a paragraph with that name. Of course, there's not just paragraphs. You have also headers and lots of other elements. And all of these elements will have to have the same rules. So in practice, we have to repeat this rule quite a few times to cover all of the styling. And you'll see that later when I show you some introspection in the browser. So that's basically how the conversion works, and you see that I should go back one step. What we're doing here is because we're changing the styles into a CSS, but when we're editing, we will first edit the top part. So we'll change the actual ODF, and then redo the translation. So when we're editing, which we're actually not supporting yet, but which we're planning, we will be editing the actual ODF, and then we calculate what CSS looks like. And this brings us to a point, a problem with many Office suites is that they usually try to warn you from using ODF, or they try to warn you from the document which is not your native format. Microsoft doesn't like you using open document formats. Well, it doesn't even matter if they like it or not. Their runtime model is quite different from what ODF looks like, and that's why some features may be lost when you're saving. Unfortunately, they never tell you which features exactly so that you could make a reasoned decision on whether or not to use ODF or not. But the same thing goes for LibreOffice, for example. When you're opening something in ODF and you want to save it as PowerPoint, they will give you the same warning. They'll say, yeah, we're not sure if PowerPoint has exactly the same features, so are you really sure that you want to use it? Well, in ODF, our runtime model is ODF, just like the model which we're saving. So there is very little difference. It's just the XML which you have on disk is the way it looks in the browser. And I want to give a small demonstration of that by actually just going and looking inside of this browser now. So this is the live document. And by the way, do you know what this is? This in office text editor terms, you call this an underwater screen. It was popular and worked perfect. And basically in the browser, it's back. You can actually see what your document looks like. So you see here the XML. And here you see if you select an element, for example, the first page, you see what CSS applies to it. So you can directly see when you're developing or improving web ODF if the CSS translation is correct. And you can even see where it was defined. OK. But that's just the underwater screen. OK. The next part will be a bit of a JavaScript. Because writing JavaScript is something many people like to do, but few people like to learn. The problem with JavaScript is it's quite flawed. There are many problems with it. But you can avoid the problems. And that's what I want to go into a bit right here. You have to be very careful when writing JavaScript. But with the right tools, it's a doddle. It's just fine. Just you have to be aware of them. So I want to talk a bit about that now. So these are the practices which I want to talk about quickly. So you have to use the good parts of JavaScript. There are many bad parts. You want to use JSLint, which is just a checker, which checks is my JavaScript good. You want to use runtime abstraction. And we really need that here, because web ODF might be running in a browser. It might be running on a command line. It might be running in a native application. So we are abstracting that way in our project. You want to use callbacks for fast IO. And you want to compile your JavaScript using the closure compiler. And of course, use a lot of unit tests. So the first part. I saw that a standard of a Rylea, that the biggest sponsor of the event. So I think it's good that I say this is an excellent book. And you should probably buy it if you want to write JavaScript. It's called JavaScript the Good Parts. And it explains which part of JavaScript are bad and which you should avoid. And yeah, it's a very thin book. It's a great read. I think you should really have a look at it. The author of the book also wrote a program called JSLint. And JSLint will tell you what, if you're using a bad part of JavaScript. So you can avoid it. So the runtime. WebODF runs in different runtimes. And the only common thing between all the runtimes is that, of course, they're all JavaScript. And some may have a DOM. If they don't have a DOM, you cannot do anything. You cannot do everything. But you can still do the unzipping, for example. You can still do base64 encoding. And the runtime is a thin abstraction layer that gives you access to the file system, logging, use of timers, the window object. And we have currently runtimes for the browser, for Node.js, which is the server which is currently running this presentation. And Rhino, which is a JavaScript implementation. You should also use callbacks. This is a very cool feature of JavaScript. And since IEO is often the bottleneck in your application, instead of waiting for an event that may be slow, you should pass a function. So here's a function loadxml. We want to read the file myfile.xml. Instead of waiting for the result, we just pass along a function. And the function has two arguments, error and data. And if the loading has been done, then this function will be called with either the error message or the data. So because the function loadxml itself returns immediately, sending a request to the file system and then hanging this function on there, it can immediately continue with all of the rest of your applications. So your application becomes a bit faster, quite a bit faster. Well, it's very important to write unit tests. It's tricky to write a program which runs in a browser. I mean, browsers are so different. They're getting much better, but they're still very different. So you really need to test a lot. And also, I have to admit, I didn't mention this yet. But we are not even supporting Internet Explorer at all right now because it's not worth it. I looked at Internet Explorer 9, and we might support that. It's a lot better, but I'm not sure it's following the standards good enough. We tried, when we endowed on how to develop something, we just read the standards and use that. And if Internet Explorer adheres to that, we may start using that. I don't see that as a big problem for adoption of the project because if you want to use a native application, you're free to choose any browser you like. A WebKit component, for example. If you want to use it on an Internet, you control who is using that browser. So selecting on quality of browser is not really an issue, I think. So we also test with command line programs just so that we can do unit testing easily. We don't have to press reload in all the browsers. We can just run something on the command line. Instrumenting the code, there's a very cool tool called the JS coverage. What you do is you run an executable over your JavaScript code, and it will instrument it. That means it will add monitors in all of your code, and then when you run your tests, it will tell you how often every line of your code was executed. And that's very good because you can check if you are actually testing all of your application. Okay, Node.js, I want to say a few things about that because you want to run unit tests on the command line. Node.js is a V8 engine. It's the JavaScript engine which is in Chrome, and it uses callbacks extensively, so it's very good for a server. If you want to implement a server in JavaScript, well, this is the thing you need. It's really up and coming. We're also using Rhino. It's a very slow JavaScript engine, and it doesn't use callbacks, so the reason why we're using that is because it's so different. Because the callbacks do need special attention. You need to make sure that if you pass a callback that you don't need it before you actually leave the current execution loop. And lastly, we're using Qt WebKit because neither Node.js nor Rhino has a DOM, and we also would like to do tests on the DOM on the command line. So we have Qt WebKit which runs with no user interface, and which we can do more testing with. Okay, next in the list of tools which you want to use with JavaScript is a Closure compiler. Since what does it do? It combines all your JavaScript files into one big file and optimizes that, and in itself that's not really too important for this project because the code isn't so huge, but it also does syntax checking, and it also does type checking. So instead of waiting for your browser to give an error, you can already on the command line see if your code is any good. How does this type checking work? Below here is a small code fragment, and you basically, you set comments saying what type every argument to your code is. And even if you pass a callback function, you can say what the arguments to the callback function should be. And it's surprising how many type errors this will catch. Okay, that was most of the talk already. I would like to at the end show a way of how to use WebODF in your own program. If you download the code, you'll see two examples there. One example is to use WebODF in a Qt application where you're using Qt WebKit and you create a canvas where you can load ODF documents. And another example which is in there is to make an Android application which could show ODF documents. At the moment, there's no decent application on Android to show ODF documents. And this one is also just a demo. So it's not released as a decent solution which is in the marketplace yet, but it's very small because most of the code is in the JavaScript which is shared. And it would be very easy also to make, for example, an iPhone or a BlackBerry version of this application. So this is a small excerpt of the code of it. It's basically two classes. And here you see some of the magic happening. Here, what you do is you load this ODF.HTML file in your WebKit widget. And when it's loaded, you change the current runtime. You change the read function. You change the function for the get file size. And once you've done that, then you instantiate a new ODF container. So we're overloading two functions. And then this gives our application the ability to read any file on the file system. So the advantage of this application is that it can actually show you files which are on your disk. And I'll run it now. It's here. So this is the simulator. It's an older version of Android. I purposefully used an older version to show that it also works there. You don't need all the new features in Android to get this running. So here it goes. Let's open a spreadsheet. The emulator is a bit slow. And then the device will be faster. So here you see very simple spreadsheets. Let's open a small text file. And you see that this is just a, it's really just an HTML page, but also Android Proverger with nice UI here. And yeah, it's a very small application. Most of it is just the JavaScript which is shared. Okay. So what are the current activities in the projects? We've been going for half a year. We're being sponsored by an LNET. We still have about three months left of funding, well, not full-time, but part-time funding. And during this time, we want to improve the rendering of your documents because we're suddenly, if you open a document in WebODF, it certainly doesn't completely look like it would do in LibreOffice or Caligula right now. So there's still some questions and improvements to be made there. We're making API so that you can control the ODF canvas. If you want to write your own custom JavaScript HTML5 application, which just an ODF widget in there, it would be nice to have a nice API in there. We do have something, API where you can zoom in and out and where you can exchange parts of the document programmatically, but we want to extend that a bit to make it nicer. And of course, suggestions of people who are using the code are welcome. We want to have write support so we can actually save a file back. This is partially done already, and we want to support limited editing in the user interface. Not complete editing. You won't be able to completely modify a whole table. That's quite complicated. If somebody would like to write this code, they're more than welcome, but this is not our initial focus. And if you're interested in this code, it's only 3,000 lines of JavaScript right now, so you can check it out and become creative. Just put it on your web server and see what's missing. And I'm sure it's whatever is missing for you, it's easy to fix, unless it's some big feature. Okay, summarizing. Open document format is great. I guess all three speakers in this track will agree with that. The community for ODF is very active, and WebODF is great because it can bring ODF to websites and to many devices. And WebODF is also great because it doesn't mess around with your ODF. It just keeps it in your document as ODF. It doesn't convert it to some internal runtime. So WebODF makes ODF easy and fun. Thank you. So we now have actually 50 minutes for questions. Have you considered turning WebODF into a Firefox extension so that you can preview ODF files on sites which don't have WebODF installed? You can read ODF on what? So there's lots of ODF documents on the web, right? But in this system, the owner of the website has to install ODF.html on their domain in order to be able to preview them. If you took this code and made it into a browser extension, then the owner of the browser could preview any ODF document. That sounds like a very good idea. Yeah, I haven't thought about that because I wasn't aware that an extension might be able to handle a MIME type. Oh, absolutely. I don't know about other browsers, but certainly Firefox. It would be very easy to make this then. I think this has actually been tried before. There was a Firefox extension that did some very simple stuff, but you seem to have got a whole lot further. So it would be really interesting. I personally think that it would be a cool feature for Firefox to have in the core, eventually, a kind of preview mode for ODF files and would really drive ODF adoption. And if your code could get to a certain level of fidelity and a certain level of reliability, then why not? Yeah. Also, if it's an extension, you can just, when somebody clicks on it, you can open it, show it, but on the top have a big button saying, actually open it on your desktop. Yeah. Good suggestion. Are there any more questions? Oh, all the way up there. Where are you again? Maybe you have said it. I was a bit late, but what is the added value of Web ODF compared to native HTML? Well, that's native HTML isn't ODF. So if you have Office documents, which people are creating with LibreOffice, Microsoft Office, Caligra, and you also want to publish them on the Web, how are you going to do that? You need something for that. And I think Web ODF is a very nice way of doing that as true to the original document as HTML allows, so that HTML runtime allows. Any more questions? Yeah. Dan, here's a question. Sorry. I'm not sure if I remember correctly, but you said something like that since you modify directly the ODF out of the document model, then you re-render it into the HTML5 DOM. And this I think could be a problem for the speed, the performance of the program. Maybe it's unfeasible to do the other way around to keep true changes in sync or to use another document object model in the middle of, well, what you are doing currently, it will be outright, so it's not feasible. But do you think at least for the simple editing capabilities that you're planning to do now, it won't be a problem? Yes, I completely see where you see that there might be a performance problem. And for small documents, actually there's no performance problem because loading is pretty fast as well. I didn't actually show a benchmark here, but if you want to load, for example, the ODF specification, which is a 600-page document, it takes double as long as LibreOffice does it. It's about as fast as OpenOffice, but the latest LibreOffice release was quite a bit faster, so unfortunately I can't say anymore that it's comparable speed. It's double the speed right now, but it's pretty fast. Now that's of course the unzipping and then the rendering. If you just update the rendering, that certainly takes several hundred milliseconds for a decent document, and your suggestion of if there's an editor in one place, just do an update and only a fragment of the CSS I think makes sense. But I don't think you should change the CSS, and then when you start saving, then only at that point go back to the styles because then your programming logic becomes quite complex. It makes more sense to say, okay, the styles XML is sort of the real value, and the CSS is a reflection of it, but updating, it can be done in small parts to make it faster. Thank you. Right. Any more questions? There's a question. Behind you Jonathan. Yes, you said we can use WebODF in a Qt application. Could you list which Qt modules you may use for that? The Qt four modules, for example WebKit or some other modules? Yes, WebODF itself doesn't need Qt, but you can use the Qt WebKit module to display WebODF. In WebODF we have a small demo application, which is just a couple hundred lines of Qt C++, which basically embeds the JavaScript files, starts a Qt WebKit page, and then says, okay, now just render this. So all the application does is it says, okay, there's file access. The Web component is not allowed to access the file system usually, especially not via XML HTTP requests. So it just goes back to the Qt code, there's a binding for that, and then the Qt code will read the file and pass it on. But it's just a little bit of Qt code. Most of it is shared. So even if your application is Android, GTK, Qt, the whole layer should be quite small. Most of it is all JavaScript code. The native binding is something which you need to write dedicated code for. I'm currently publishing some ODF documents just by exporting them to HTML from OpenOffice. It's just a few, but I probably could automate that. Why would I move to WebODF? What would be the advantages? Well, you would do less work. You don't need to convert your documents because what you would do, I don't know what your Web server looks like. If it's just a page saying, okay, these are my documents, here are links to the HTML versions and here are links to the real documents. That's probably what it looks like. So what you would then do is you could remove the HTML link or at least change it to go to this odf.ml with the hash and then just link to the file. And you're saving a tiny bit of disk space because you don't need to store the HTML version. And also, I think that this version might look better, but I don't know what the converter looks like. Is it something which creates bitmaps or does it create, which filter are you using? Well, there are just a few pictures. It shouldn't be a problem, but I'll give it a try. Yeah, okay. There's nothing. Of course, if it's pictures, by the way, if it's pictures, you can't select text anymore. So, and here you can. Well, you had one slide briefly mentioning a project named ODFKit in the concept of WebKit. Is that superseded now by WebODF? Sorry, you're quite hard to understand. Can you speak up a bit? Is that better? Yeah. Okay. You mentioned a project on one slide called ODFKit. Yes. And in the context of WebKit, so assume it's C++ something or C. And you continue to talk about WebODF. So is WebODF now superseding the ODFKit or? No, they're separate projects. Okay. ODFKit came first, and ODFKit basically is as largest patch on WebKit to give WebKit support for ODF files. So we added some logic there to do unzipping and to go to read either the XML format or read the zip format and also load it into the DOM tree and then do some JavaScript work on that. However, when we were writing this, we saw that actually most of the things which we were patching WebKit for, you could just write in JavaScript, and that would be easier. So I do think that WebODF is a more elegant solution, but if you really want wall speed, then you can still, then ODFKit is nicer because then you have the unzipping support, for example, in the browser itself. That being said, I do think that, and we might actually submit a patch to the WebKit people saying, okay, why don't you add unzipped support as a faster version just by having it in C++ code? It would require an extension of their interfaces. Not sure if they would accept it, but yeah, it would benefit sort of everybody using WebKit and also WebODF would then be faster because it wouldn't need to implement that itself. The way JavaScript handles binary, binary arrays is basically non-existent. It's just an array of numbers. So that's really quite inefficient, but it's fast enough. All right. Are there any more questions? I don't see any, I think. Well, thank you all for your attention. Thanks to the speaker.
WebODF is that we're making a JavaScript HTML5 a way of viewing ODF files, you are not dependent edit ODF documents and they will be exactly the application which runs on the desktop or on a to here to show you. This is the server running popular open source browser, and they didn't So most ODF files are zip files, not all of them, solution for that because the ODF standard has a and then the document tag there, that's an office HTML uses CSS, CSS3 by now, and that's quite directly translated the selector based on just editing, we will first edit the top part. So brings us to a point, a problem with many Office So you can avoid it. So the runtime. WebODF runs Rhino, which is a JavaScript implementation. You browsers. We can just run something on the of the code is in the JavaScript which is shared. interested in this code, it's only 3,000 lines of So there's lots of ODF documents on the web, allows, so that HTML runtime allows. Any more LibreOffice does it. It's about as fast as give WebKit support for ODF files. So we added