 So, hello. This talk will be about the new ePubExport filter in LibreOffice Writer. Just shortly about myself, I have been involved with this codebase for a number of years now. And my pet area is Writer. So, I was happy to hear that there is an opportunity to implement a new export filter in the form of the ePubExport. And I keep mentioning that in LibreOffice, but that's a Writer export filter, so far this is only limited to Writer. So, why do we need one more export filter? Making the LibreOffice codebase even more bloated. The motivation is that if you have some mobile phone or tablet or a reader or something like that with a small screen, then for your use case, ePub is kind of the new PDF. PDF is not going away. It's still a very nice format when you have some larger screen, but it's not very good at reflowable text handling. So, instead, what we have is ePub, which is designed exactly for this use case. So, as you probably know, LibreOffice has pretty good PDF export feature. So, wouldn't it be nice if it was support exporting to ePub as well directly as a native feature? Previously, you could export to some other format and then use some second tool to convert from that format to ePub. The problem is that all of these are loosey conversions. So, the more items you have in your pipeline and perhaps the end result is not even something you can recognize. So, it's good to limit the number of building blocks you use. So, directly exporting from LibreOffice itself has its own benefits. Regarding the state of this work, the recently released LibreOffice 6.0 has basic support. And the 6.1 will have much improved support. The good thing is that eBooks are kind of books and I was told that a good book does not have much formatting. So, the formatting does not distract from the actual content, which means that basic support should work for good books already. And if you need some more improved support, maybe you should refine your book. In any case, for the rest of this talk, I will talk about features which are not just basic tech support with just a minimal set of character formatting like board and italics and the minimal set of paragraph formatting like adjusting it to be centered or some paragraph spacing and something easy like this, but more complicated features. So, from now on, all of these will be shipped in 6.1. One frequently used feature in eBooks is hyperlinks. So, this was the first non-basic tech feature I was focusing on. But to be able to fully handle hyperlinks, you need to have support for all these paragraph and character styles or the inheritance of that and so on. But at the end, we have some hyperlink support and hopefully at the end it will end up in your EPUB result the way you saw it in writer. There comes table support where you can have a set of properties on the table itself. At least from the writer perspective then it would be just rows and inside the rows you have the cells and so you have the table properties, row properties and cell properties, but from a high level point of view you also have column properties and then you can have the row spans, the column spans and various properties on this. With the current master LibreOffice, these examples are working nicely. These are screenshots from EPUB readers and it's not hard to construct something similar in a writer. The other new feature is much better image support. 6.0 has support for simple inline images, which I mostly added because I wanted to test the part of the exporter that assembles the EPUB package and for that I wanted to have a use case for the binary content, so I added the minimal image support where the inline images or ask character encode images are a good fit because they don't have special positioning which can be complex. But now in 6.1 you can have much better support for this, the various image borders, image wrap types and image encode types that are supported or at least a considerable amount of combination of these. And again from a user's point of view a caption on an image is just one more property of the image and this is something that EPUB use a lot. Technically that's a tax frame and the tax frame contains an image and with some additional tax and that tax contains tax fields. All of these building blocks are implemented too. At the end you will just see a working caption support for images. Then the next one is font embedding, which is pretty frequently used for EPUBs. The nice thing is that for the font binary format what we have in ODF can be transferred to EPUB as is, so no manipulation of the font data itself is necessary. And here is some very tiny screenshot of some special font that was not available on my system and that's again a screenshot from some EPUB reader. Then we come to features where the writer document itself does not really have a concept for, but the EPUB specification has. The first example is cover images. The writer don't really set the cover image on a document. If we generate thumbnails done we just paint the first page of the document to a meta file and we work with that. So as part of the export options you can specify a cover image. The export options is a dialogue that used to be very simple and as I added more and more features now it's relatively complex. But you can set there is the version of the EPUB, EPUB 3 and EPUB 2 are two major versions which are interesting. EPUB 3 is what we default to. Then you can define how do you want to split your document into EPUB sections. We default to just splitting by having one size but if you have some plain text import that did a document then perhaps splitting on page breaks. Explosive page breaks is a better setting. Also there is support for the reflowable layout which is the default and there is also an EPUB fixed layout which is a bit odd. If we want fixed layout then why don't you use PDF but I will come back to that later. You have an explicit user interface to specify a custom cover image and various metadata. For the custom metadata as part of the EPUB export is interesting because you may want to export to EPUB some classic book where you are not the author of the book. But if you look at that writer document then for that document you are the author. So it makes sense to be able to specify a custom author just as part of the EPUB export. Then one more new feature is support for food notes and image pop-ups. For both of these the point is that you click on an image or some text and some pop-up appears that displays some additional content. And your original position is not lost so you can close this and get back to continue reading the document. One form is that which is perhaps more regular for the regular writer user is the food notes. But this also works that you have some lower resolution image inside the document and if you click on that or tap on your device then some high resolution pop-up as a full screen object appears. So this fixed layout is basically to you as a user it's quite the same as PDF just build on top of XHTML and SVG. Probably the primary use case is when you are working with a publisher that only accepts EPUB and you have some format like a comic book where the fixed layout is important because some reflable text would modify the meaning of your content. Then fixed layout is still wanted and the publisher refuses to work with you if you provide a PDF of them. This is something you can work with and the nice thing is that at the end it was not too complex to add support for this. So even if you don't need it it's not a complexity that much overhead to the code. So far this is what you get as a user and for the remaining time I will talk about how this is developed. So the music architecture is like this. We have the writer document model and then the EPUB exporter works with that document model and writes out an EPUB file. Inside the EPUB export I tried hard to reinvent and I tried to reuse what building blocks we already have. The most interesting part is the EPUB generator library which is part of the document liberation project and it was not part of Libreface but now it's bundled with that and it was a good starting point. I had to extend it variously but at least as an initial step it was already working. We start with invoking the ODT export and we consume the ODF XML markup. This is nice because the EPUB JAN is working with the Librevenge API and that closely ties to the ODF format. So this means that we don't have to do much transferring manually. There is no explicit code to transfer the italic or boldness of characters. This is just working out of the box. We just transferred the character properties and so on. So we have the ODF export. I explained the Librevenge tax export that was the main part of the work to be able to use Librevenge based export filters inside Libreface but because the EPUB generator was the first one this building block was necessary for the next Librevenge based export filter it will be much easier. And at the very end Librepunk JAN just generates the various streams in this EPUB package but it has no own support for compressing zip files and so on and that's great because we don't really want to have the reliance of different zip compression code. So we get the callbacks and then the Libreface own code does the usual packaging just as it happens for OXML or ODF. So this is a long list of features that I had to add to EPUB JAN and this means that by the time of the 6.0 release also a Libreap JAN release was made which is basically the fallout of all the mentioned features. Then one concept I would like to explain is the media directory. The media directory is the directory that sits next to the document that it contains files which are not part of the writer document model. This means that it can contain an XMP file this metadata specification from Adobe to automatically override the metadata during export which is something you can specify manually on the user interface but this way you can convert thousands of documents automatically with some custom metadata override. Then I already mentioned this image popup use case where you have some multi megapixel photo and not only a small number of them but something large. Then there are benefits of keeping that outside of the document model in writer. Also the core images are sitting here. By default this is nothing complex if you have some foobar.odt then a directory next to the file called foobar is the default media directory and again you can customize this. For the fixed layout initially I was a bit scared it sounded we will have to reinvent lots of features that the pdf export already has and why do this application there is little benefit to the end user and so on but eventually we already have the support for exporting writer pages to metophiles. We already have an SVG export which can take a metafile which means that the fixed layout EPUB export result is really just a series of these SVG images and that because the fixed layout EPUB document. One problem with this was that the resulting document does not know much about characters and paragraphs anymore so how to provide some pretty navigation document or index for the file. For this I separated the responsible code for this from the pdf export which has a similar problem and now that building block can work without an actual pdf export but it can also work with an EPUB export and with that for each page we know which chapters are starting there. I did not skip testing in real life but here I will skip testing and I just wanted to say that for everything we do at Collabora somebody has to pay for that because it's work and in this case Core is sitting there known as a small company and he and in collaboration with the partner was sponsoring this work so thanks a lot for them. Under the rise thanks for listening. Any questions? Great, I use my time so thanks again for listening.