 Hi, I'm Tomas from Colabora, and I will talk about the PDF and other graphic improvements. So I decided to change a little bit the topic here, first was PDF annotations, and I figured that there is not many improvements that are specific to annotations to have a complete talk. So I decided to add a bit of other graphic improvements that are also related to PDF in a way. So last year I had a talk that I extensively talked about PDF annotations, PDF searching, and so on, so I want to recap this year what I talked last year in a concise way, I hope. So the improvements to PDF that I did already last year, so this is PDF as a graphic object. So this is not just normal importing of PDFs in draw, this is like PDF, we have a PDF that is a graphic object. We can import it or load it for PDF as an image and then show it inside the document. So there is a special import that uses this and this opens the PDF in draw, and it opens the PDF in such a way that there is one graphic object per page. So if you have a draw page, each page has one graphic object and each page has different PDF pages. So it mimics like you are opening a PDF. This is quite convenient because we also have a special implementation inside PDF export where when we save a PDF as a graphic object, it also doesn't just write the rendered image to the PDF but also writes in the original PDF page stream into the new exported file so that the fidelity of the PDF is like original. Then what we can also do here is we can search inside these PDF graphic objects. This is working quite well how this is done because each PDF graphic object has also the original PDF graphics behind it. So the binary stream is stored inside the memory and we can open this binary stream with PDFium and use the PDFium search. And then we have also the limited support for PDF annotations. So let's continue. I already said this so we have PDF stream in the memory and we open the original stream in PDF and search. And then we have to also integrate this into LibreOffice search mechanism so that it works seamlessly. Like each PDF object, each PDF graphic object is contained inside. So next is about PDF annotations. So of course PDF files have annotations in and we want to preserve these annotations and potentially also we want to change them. PDFs support for many kinds of annotations like text, links and lines. You can draw squares, circles, polygons, polylines. You can highlight the text, underline text, squiggly text, track it out and so on and so on. So what is currently supported? So the basic one is just to have an annotation and this corresponds with what is already supported inside draw annotations. Of course there is a little bit difference here because inside PDF you can choose like custom colors for annotation and additional metadata that is not supported in draw so this had to be extended. And then other is what is not supported at all inside draw is that any kind of vector graphic annotations or like text highlighting annotations. So there is limited support for vector graphic annotations. They mostly work but I'm sure there are some, like for example lines have like endings and starts and endings on both sides which can form an arrow and this is currently not yet supported. And text highlight annotations are also like partially supported. For example, because these are just rectangles, what is a problem here is that we draw the highlight annotation over the text. And normally this should be under the text so that we can clearly see what the text is. But currently there is no way that we can do this here unless we draw all the whole PDF in our own. So what's not yet supported is like more complicated annotations like the annotations that are always visible here, part of the document. And export support was still not implemented which is like only the original draw annotations is supported but when we have like any vector graphic annotation or text highlight annotations that we can show but we cannot export it again. So this can be a problem. And this is now how it currently works like like this inline annotation. I saw this is not supported but as you can see all and you can also see here that this line does have the endings correctly. But others you can see that it looks like that it's all everything is in this example is supported. So now I want to go to another topic that after there is also work that I did after that is like this PDF, graphic objects, memory improvements. The problem is that if we want to actually use this PDF as graphic objects and use in draw each graphic object in each page, the problem that we have here is that the graphic objects how we store the original data. So as part of the GFX link and also part as vector graphic data, the problem here was that the original data was always duplicated. Another problem here is also that it's not just because also the export itself must be modified because there is more duplication. For example, each page has at least one graphic object. So if we have 15 pages, we have 15 graphic objects and there was no implementation that would prevent duplication of this PDF data. So this we always duplicated for each graphic object had its own original PDF inside. And of course there were like some PDFs with a hundred of pages that caused a problem with the memory. And severe with this cause severe swapping of graphic objects and of course sometimes also crashes. So what we were forced here to do is like to minimize this as much as possible. So ideally there should be only one PDF data, binary data in memory for all instances where we use it. So I introduced this binary data container class. Binary data container class is just a simple class that can be shared among different other classes. But what's important is that it holds the one holds and handles the one binary data stream and should prevent unnecessary copies. So I implemented this and put it inside the GFX link and vector graphic data. So now they always share one instance of binary data container and we don't necessarily have multiple copies of the same PDF data. Also I modified the import so that import doesn't just put copies of PDF data to each graphic but also again shares this binary data container. I also added the Uno interface X binary data container and wrap this binary data container. So we can also transport the binary data container through Uno and we don't need to convert this to sequence of bytes which will again just make a copy unnecessarily. And this again reduces the number of copies. Related to this is also swapping how we swap graphics. How swapping graphics generally works is that when we get a problem with the memory, we consume too much memory, we need to swap graphics in and what happens at this time that the graphic object goes and removes our binary bitmaps and vector graphic data. So that it releases the memory but also removes GFX link and GFX link contains the usually compressed or the original case of PDF binary data. And because both vector graphic data and GFX link data were destroyed, we also lost the binary data container and what happens at this time all the stream is then stored inside the temporary file on the disk. This is a problem because when we trigger a lot of swapping, this also triggers a lot of IO and it stores everything down. So if we just keep the GFX link intact, we can prevent this. So this is how I changed and changed the swapping algorithm and it works much better. Generally like this, if we have some image that is compressed, it usually doesn't take a lot of memory. So this is now working much better than it was working before. The original problem with this is again when we have loaded our PDF graphic objects in a drawer, there were some problems with this because it took a long time to open a PDF file because it constantly kept swapping in and swapping out. And this was not fast at all. So the last thing that I have is implemented like PDF rendering, DPI configuration which is also available now. So when we use PDF as a graphic object, the PDF page is rendered as a bitmap and it uses a certain DPI for this. The DPI is relatively low like 96 DPI so we can keep the bitmap small so we don't consume a lot of memory and rendering is higher. Now this can be changed so the configuration and currently this is only an environment variable PDF import resolution DPI which can be then changed to higher if you want a more better resolution rendered bitmap. And generally this is it. Thank you for watching and bye.