 Good afternoon, everybody. Thank you for coming for this presentation. The idea I have here is to express some of the achievements and concerns that I have with the subject of documentation and to try to foresee in the future what kind of developments that we can do in terms of documentation for LibreOffice. What I think it's important, and it is my personal view, is that we are good at developing software, but we should also be able to transmit the beauty of the software to our customers and to our users. And that includes documentation of the software. From the very beginning, it was clear that we were developing software, and we were not documenting the features. And this is not good because, of course, users don't get the information about the features. So that's important for us. And what we have at the moment in terms of documentation, it's a very broad subject, and it includes the help. It includes the user guides. It includes the technical documentation of the technical aspects of the software and many other aspects, as well as, for example, new medias and new forms of media. So what we have in terms of documentation, the help, which is connected to the product, is something that we deliver when we download it. The guides, which is written by the community and it's available to increase the user awareness of the features. The API, which is this focus for development and also for some advanced users. The Wiki, which is community-driven and it's free for addition and including whatever kind of topic is relevant. Tutorials and others. Well, the help for help. This is a situation that we have. The help is an application that is written in XML. XML is complicated. It's not very readable. It's something that we use. It has some advantage, but also it's not an easy way to edit information. The help is online and offline. And also it's a steep entry barrier. If you have to explain the XML that we use to someone that is just coming, that takes a lot of work and a lot of time to get familiar with the help. And also, in order to see what are the results of the help, you also need to likely have a build of LibreOffice. And also the help also has to address the translations. So everything is already in place in terms of XML. But again, for the editor of the help, it's not so easy. So what's XML? You are using whoever already read the help in source code. We have that kind of verbals editing. You absolutely need to be familiar with the XMLs. We need to build the software. It's very easy to make mistakes. It's very easy to break the DTD. So again, this is knowledge that people need to be sort of a developer to really address that. And steep entry barrier. Very often I get in the chats, in telegram, shall we keep the XML? Is there anything else that we can use to improve the access of the help? Some requirements of these new tools, support for the translation in the build, provide ways to support translation tools, such as weblates, be easy to learn for new volunteers, produce online and offline help pages. So I got a lot of suggestions. People always come with bright ideas. Let's do that. And then of course, when we start to look at the requirements, that's not so easy. So for example, first thing is markdown. Let's change the XML for markdown. It's very easy. It's pure text, many standards editors. Pure text editor is enough. Syntax is easy to learn, build tools exist. However, we have several standards. There is not one markdown syntax. There are several. It depends on the tools that you use. And it has to address or raise the translation. For example, one of the interesting things is why don't we use Hugo, which also is a markdown-based text editor. And then we run Hugo. It's very fast. And we get all the pages that we want in HTML, for example. The other one is why not use pure XML. Here again, we have many editors. It's non-syntax. It's much more flexible, but it's much more popular. We have support for translation. And it's very quite close to the XML that we have, except for some specific features. And also, this advantage, it can be quite verbose. So that's not so. The other things that I thought, people also already said, use LibreOffice Writer and then export to HTML. The point is that the export for HTML is very old. It has not been updated since ages. There is a sanity check for script necessary, so that you don't do the mistakes. The translation framework is not very easy to implement. And export to XHTML is a little bit better, but it needs some manual tweak. So what is your choice? You have to tell me. You have to draft a project on what is the best tool that we need to have for the help. And one thing that is very, very common is that I have an idea. Why don't you do that? That's not going to work. OK? If you have an idea and you want people to join, then you have to start explaining and developing your idea, and then you get people to join. That's the way, for example, Linus Torvald started. He made a small idea, and he publicized his idea, and then he got support. Here's the same. Don't ask me to implement your idea. That's not going to work. Well, the second big challenge that we have in documentation are the guides. The guides, what's the problem that we have at the moment? We have a small team of skilled people, usually people like myself, Peter Schofield, Gene Webber, and a couple of others' names that really understand what is not only the content that we have to write, but also the formatting and the production of a book. Very often I have people that comes to the documentation, I want to help. I want to be a technical writer. Help me. And then we have to put all the efforts to make the people understand that's not so easy, and it's not just writing a couple of paragraphs, but also to understand what is styles, what you have to do, and what you can't do, and things like that. At the moment, we are quite close to the release. So mostly what we do in the guides is the updates and revision. So new features go to the guides. And then this is a thing that I already asked in the steering committee for engineering, is that please developers, if you implement the new features, please let us know the new feature. Please put an image of what you are doing. I discovered later that we have a lot of very visual features that were just aligned in the release notes. So I didn't imagine that we had so many new features in 7.6 that deserves a good documentation. So be verbose when you explain what you are doing. It's important for us. You know? I have tons of examples. And the first one is that I discovered by myself that we have the spotlight for styles. This is a wonderful feature. And I discovered by chance, you know? And I said, oh my god, if you write a book and you use styles, the spotlight of styles is an amazing feature. OK, the guides you produce, PDFs and ODT. I am a bit, at the moment, a bit skeptic on the effectiveness of publishing PDFs, 500 pages PDF for user guides. I think that it is important that we make the content more accessible for the people in the sense that it make it more popular. And we are very good in producing PDFs and ODT. But the people that are used now, the Z generation or the Y generation that use only cell phones, do they want to download the PDF and read on the phone? That's not going to work, OK? So I invested quite a lot in terms of online reading. And I evaluated several tools to make my life easier. At the moment, I use this extension, write it to HTML extension. And I create this small web server, well called the bookshelf. OK, sorry, this is in Portuguese, but it's the bookshelf. And I have all the guides available for download, not only on PDF, on ODF, but also on HTML. But the point is that to transform 500 pages book into a readable HTML, it requires a lot of sanity checking on the books, OK? So I had to run scripts to check the anchoring of the images, the anchoring of the frames, existence of direct formatting, several issues with lists, and fake, I call that fake list, which is a body text with a bullet, not a specific style. So that makes quite a lot of work to transform it. But at the end, it works, OK? So this is the layout of one of the guides. I was able to put the table of contents of the chapter here, some auxiliary information here, and the contents there, OK? And also all the books, all the chapters, are accessible on the left, sorry, on the right. OK, so this is the layout I have, OK? That's not so easy, why it's not so easy? Because when I export into XTML, then I have to manually introduce JavaScript and CSS to get the layout of the page like that, OK? So it's not so easy. I will explain some of the details here. This is the way we see a chapter. We have the logo. We have the guide name, the title, the subtitle, the copyright, the table of contents, and the contents of the chapter. This is the way that you leave a book. It's a sequence of contents. Then you have to shuffle. These are sections, and you have to shuffle that to get the other layouts. So I have to introduce sections, these sections then, so that I can get the sections here, OK? So you may recognize that we have the table of contents on the left, chapter and subtitle, guide name, et cetera. And for the sake of usability, I also introduced a couple of more sections, OK, so that I can have the layouts that I show in there. So what is all this effort? This is, at the moment, very manual. And I'm just wondering if we can evolve and have what I call the web output, which is I have a document. And can I export this document into a true web system, a web page, because this is the book page and this is the web page. So it's different, but the contents is the same, OK? So question, do we have a page grid that is something that could remind me, could remind us about the grid used in HTML5, the CSS grid, so that we can reposition elements of my content into different real estate positions, associate or locate the sections in the grid so that I can shuffle everything, OK? So my question is, can I get an attribute of page grid ID into my section? This, of course, are extensions of the ODF. This is OK. And the idea is to have that, OK? This is a page type, and I could have grids to divide my page types into several others' ways. And then I can attribute the sections. How about translation? OK, translation is done by communities. It's a lot of work. It's a lot of work. Everybody knows that. Leo knows that. I know that. It takes a lot of time to translate. Now, I would like to have translation assistance. Fortunately, we started to use web leads for guides to make an evaluation of how it's effective or not. But machine translation is something that I would like very much to consider, either using external service or an internal service with another force project, namely Libre Translate. Well, the API documentation is something I try to touch. It's created by developers. It's an automatic export of the code, the IDL thing. But for the end user and for whoever wants to make a script, this is very, very hard to read. It's not designed for the end user. If I am an accountant and I want to make a spreadsheet with a specific operation, it's extremely hard to get into the information with the current API. So we don't have a good idea for completion. I know that there is an experimental code, but it's not complete. It's very hard to navigate in the right API page. Let me adjust the challenge you to get a specific paragraph into a text document. This is just crazy. You need to traverse a lot of collections of things. The notation is not user-friendly. Critical lack of code snippets, et cetera. This is an example of what is created by Ranch. You really, really need to be developers to read that and apply it in your scripts. So that's my presentation ends here. I'm open to questions, to suggestions, but suggestions will have to be followed by a bit of work from you. So thank you for your time. And, well, I'm open for questions. Yes, the ebook, EPUB, I saw the contents is there, but it's very, very badly shaped. And most of the EPUB, you need to have a specific tool for that. You need to have an extension on a browser for EPUB. So I prefer to get it directly in the navigator, in the browser, and get to the page immediately. But I found that the export for HTML, it's good, but it has some glitches, some small things that need to be fixed. Yes? Perhaps we can work together with Michael and Simone today. We use an export to generate web pages from the EPUB document. It's a special large as our documentation, and they are the one who made it as smooth. So when you see problems with the export of HTML, you should speak with Michael and Simone. Yeah. When do you export? Can you repeat the question? Regina is suggesting me to work with Michael Stahl and Svante for exports of HTML. Is that correct? Yeah. I have made some tests with exporting of HTML. And the layout is very faithful. I mean, it renders correctly, but it's a very, very, very long page, and the table of contents is exactly where it was in the book. It's not shuffled in another position. And that's my specific demand. I have this demand, too. When I export to HTML, it would be nice that I could have a dialogue where I can add some specific parameters so that it will help me to produce automatically the web page, including a link for a JavaScript and a link for a CSS. The CSS is to get the grid, and the JavaScript is to add some other features that I don't have in ODF. So that's it. Question? No question? You have a question? Yeah. A challenge. Deepak has been mentioned. I have been working with the Ministry of Defense for an innovation department there who invested in the initial export. And you are perfectly right that there are some open issues that are not as correct in even as exports, not yet in government. On the other hand, Deepak has some advantages that it's flexible. It shows on various devices, small and large, manipulating your screen, and it allows scrolling. There is already an extra dialogue. It has some advantages connected with library and meter data, et cetera. But still, you may be right that the export in improving deeper exports to the level that is needed for this work is huge compared to the effort that is needed to get the HHML export work nicely and the manual tweets, et cetera. So could you be challenged by making some comparison of the effort for route one and route two? And it's not something the HHML do that. I think it might be very convincing to see something like that. Deepak's question, sorry. Yeah, I mean, I made some tests. I used the extension that was available. Unfortunately, this extension is not very well maintained by his author. So I may consider to come back to HHML and do the scripts that I use for the extension. I can eventually try to make it work with the export to HHML. So I'm not close to any specific. As long as I get the results I was showing here, what is the tool I don't care very much in the sense that, well, I am focusing on the results. But when I export, for example, here, let's put the draw guide and read online. So this is what I have. And you see it's quite fast. It's just static HTML. So no servers, no database, no snorting. But as long as I get this kind of layout or even something that is even more better, but at the moment, this is enough. And it can be the export for HHML or it can be the extension. The point is that the current export to HTML, which is 4.0, it's broken. It's really need to be completely updated. Yes, I love the idea to get a lightweight output of the great content, because that is obviously a drain. Yes? It's a map. Formulas exploded. Mathematics? You can run. You can run, but then you need to get much. There is a JavaScript library specific for that. Firefox has it internally. It renders all the equations nicely, but Chrome and Edge, I don't think they have. So you need the JavaScript. And well, I consider the results quite good, at least on Firefox. The formula part from there to HHML, including the formula, which is JavaScript division, and it renders corrective. Yeah, it's very good. Any question? OK, thank you very much.