 But we currently store it in the undo step, store it to distance, and log file. So at least when somebody doesn't use the graph, they've got a record of the action. Yeah. Yeah, it's just tricky if it's... It's not, it's not certain. Okay, so we fix, like, about five places where graphics go missing. And it's got different reasons. But one case is that, like, everything goes in and out of document, and I think you'll find that it's all going to actually save what goes missing, so the log doesn't help there. And I think you need to identify it. There's one running... There's actually a disk. And, yeah, if you can find that out, then we could put something in, so it wouldn't happen again. So you don't have to stay long until you can actually be sure of what is happening out there. There's a reason to be quite diverse. It's just like sitting in trash, you know, just like the graphics go missing. Mic working. And the next presentation will be about inconsistencies. I recently fixed a master. I'm Miklos Rina, also working for Collabora. I guess a fairly large amount of you already know me. Just in case you don't know, I arrived as a Google Summer Code student to this community years ago. And since then, I mostly focus on writing. So, in 4.2, a fixed land deed which finally allows selecting the whole document text in case the document is starting with the table. And there was a bug report for that for quite some time. Back in the Upram Fissal work, in Brazil as well. And the reason for this is that in this particular case, the selection starts inside the table and it ends outside of it. And that's kind of an inconsistency. Either we have a table cursor, and then we select a number of cells like a part of a row, a full row, or part of a column, or a full column. So it's something rectangular that would be the table cursor. Or we have a normal cursor, but in that case it should be a subset of a cell or just a set of paragraphs. So it's nothing that would involve tables themselves. And so we had a request to finally remove this limitation. And it turns out that it wasn't that hard. So in the original bug report, some developers estimated that this would take, I don't know, half a year or two to fix or something like this. And it turns out that the neat hack that's possible is that you don't actually need to select the whole table. It's enough if you select the text inside the table. And that will already do what you want. In this particular case, the report or wanted to mark the whole document so he can adjust the font or something like this. Or just increase the font size or something like this. And for this, you don't really have to select the table. You only need to select the text inside the table. And it turns out that actually when we have something like this, then we also have a look at if it maybe works as a pattern solution for this. And they use a really similar trick. So they have a definition of what's a valid selection. That's not necessary because in the file you can store what was the current selection when the document was saved. And to be able to do that, you have to define what's a valid selection. And they have the same limitation. And still you can just control A and have the whole document selected. So finally, you can do the same in the writer. The last thing is that if you review lots of League of Packs, then you will use redlining a lot. I mean change tracking. So redlining is not the favorite area of writer developers, I guess. Sadly, it's completely independent from the undo, redo handling. On the other hand, from a user's point of view, they are really similar. In both cases, you have a set of operations, and you would like to record them, and possibly you would like to undo them, or just forget about how did you get to some state, and you are just interested about the current state. So it's similar, but certainly the code for these are replicated. So the current pain with the redlining was that in case you had a spelling error in a redline text, so somebody typed this in some new string, that string contained a spelling error, then when you right-click to reject the spelling error, because it's an error, the spa check pop-up menu comes up, and you can't reject the change. So the solution for this is just to combine the two pop-up menus in case you are inside a change tracked text and still have a spelling error, then you can do both changes, like completely reject that initial, or just correct the spelling problem. The next thing is that in writer, we have all the drawing shapes that you can have in card or in press or draw, and that includes cube shapes. And even most of the writer filters supports importing cube shapes from different file formats except RTF. So after you import cube shapes, actually importing the real shapes are not a huge problem because that was there before. So with a not so major amount of work, you could actually have something working. The interesting thing here is that actually the cube shape wasn't used here as the only solution for this. The creator of the document created a shape putting some complex content, and instead of just duplicating the content during printing or using columns to have the content duplicated, he or she used the cube shape to have that. So that's how it turned out that once again if the creator of the document would have a bit more practice about how to create the same document, then this wouldn't be a problem. But anyway, I guess that's much better than what was there before. So this is really kind of an inconsistency. Dot is the binary doc equivalent of, so it is a template version of binary doc. And we could import those dot files for, since it's probably the beginning, but you couldn't write them. And in the binary format there is a single bit for controlling, in case this is a normal document or a template, so it's not particularly hard. It's like, I don't know, it was something between 10 and 20 lines of code to implement the whole feature, so it wasn't complex, but nobody did it. And because of this, when you try to save your dot file you couldn't save it back to the binary format because writer detected that this is a filter type that only supported importing and not exporting. So it forced you into either exporting or saving as ODT or something. So you couldn't really, not only save, but you couldn't even edit dot files. And it turned out that the fix wasn't that complex than it would expect it. So this is the end of the 4.2 section. And so far all the inconsistencies that I was talking about is something I fixed or at least I was partly involved in that. But at the end of each section I would also like to point out some favorite feature, which is not mine, but it would be a shame to exclude. So in the 4.2 section my favorite inconsistency fix is borders around characters. Tamash is hiding somewhere. He's back at the stage. So he's the guy who actually finally implemented character borders. So you could have borders around table size, pages, paragraphs, but not characters. And this is especially problematic because this is possible even in HTML. So it loses formatting during HTML import. Also all the board formats supported this. So it was just a pain to lose all that formatting. And now this is a fully flashed feature. So there's user interface for it, but you would have a risk factor. So the next section is about the 4.3 fixes. And I guess this screenshot was already shown in some previous presentation, as maybe it was mentioned as a normal bug fix. What's really interesting here is that there was some group shape here that was more or less a mess. And it started to make sense after fixing all the particular problems. But the interesting bit about this is that in OXMR5, so this is the docX format for Writer, there are two compacting markups to describe shapes. And of course both of them have their own problems. The other one is the VMR and the newer one is the drawing amount. VMR is the one-to-one equivalent to the binary format used to describe shapes. So the good thing is that we can always cheat from the binary creator when something is wrong in the VMR or the other variable around. So it's just yet another markup, but the concept is exactly the same. On the other hand there is the drawing amount that's a newer thing. Even the first version that already supported OXMR didn't support drawing amount, so it's newer. The problem is that VMR is only part of this OX, transitional OXMR. So if you would like to go after OXMR straight, then you can't use that. And the problem with drawing amount inside Writer is that it's not part of the specification at all. So with some marks of specific extensions or something. And the reason for that is that the drawing amount can only describe the shape itself, but not the positioning of the shape. That's a task for the container application. So in case of Writer, for example, the vertical position could be relative to a paragraph or a page. And a paragraph or a page or column are concept-specific to Writer. So you can't squeeze down these settings into the drawing amount marker. But on the other hand, because initially Word didn't support drawing amount at all, they also left out the marker from the original Word processing amount. So it's not yet in Word processing amount. So it's already not in drawing amount. And then you had to invent some new markup. The funny thing is that this wasn't specified till they tried to implement their own standard and finding out that using the existing markup is not possible to describe this feature. So the end of the story is that a significant improvement to the OXMR shape filter for Writer documents was when we switched to reading drawing amount markup and only reading the VMR for a bug in case that that's the only version there. And the reason for this significant improvement is that drawing amount was already used for quite some time for chaotic human and depressed ones. I guess in press is the main driver here. And people just hooked the existing much improved drawing amount import into Writer and with that much improved and result appears on the screen. For example, this includes adjustment on shapes. So like you have a triangle and it's not a symmetric one but has a custom geometry like shifting one corner in the right or left direction, for example. That's a safe shape adjustment. And the VMR importer still doesn't handle it properly but for the drawing amount case it was already working. So just by switching to the drawing amount one and hooking Writer up with the drawing amount filter introduced all these improvements. The next one is that you could already have Comments in Writer for quite some time. Then a few years ago I implemented support for attaching Comments to tax strategies so not just a single position. And then this got revived to also support nesting these Comments. This is not something I ever served about and nobody complained about this for quite some time. So it wasn't a pending known issue but it turned out that we failed quite badly if you tried to start one command and start another and then you end first and then end the other. And what's probably interesting here is that we not only... This got fixed in core but not only that got fixed also I want you, the major Writer filters and made sure that both the import and the export of that is working with these nesting Comments. There is still one remaining detail in the binary docking portor in case we have some non-trivial content in the Comments that may still cause problems. And the idea there is that these written tax strategies are working properly for bookmarks so basically it would be a matter of debugging how bookmarks can even contain a whole table or something like this and do the same arrange mapping for Comments and then we would be really 100% perfect. So the next thing is relative size tax frames. The interesting feature is that it's possible to have 100% width for a tax frame but exactly what 100 means isn't really specified. And it turned out that the specification and the Writer implementation luckily they are in sync they mentioned that the current paragraph area is the 100%. So in case you are inside the table then 100 means the width of the table. But in case you have columns then 100% will be the width of the column itself or if you just have planters then it will be the paragraph frame so it will be the page size excluding the margins so it can mean different things. And this is all quite implicit if you would like to have something fixed like something into some relative size of something fixed then one possibility that was requested is to be able to have the size relative as part of a page. So now there is one more combo box on this tax frame properties dialog and you can choose if the relative size should be relative to the paragraph area or the entire page. And it's a combo box because more options could be also passable there but for now these two are supporting. One more inconsistency on import with IPCOL it gives some feedback to the user where we are with the import process but this was missing for Docax and it turns out that the document can contain the number of paragraphs as a metadata. So we could read that and before doing the real import except that we didn't write that metadata so the task was fixing for the metadata exporter to contain the number of paragraphs and once it was done or it was produced by Word or some other software then implement the OS of the progress bar. So this is now working. If you would like to test this feature and you would need some larger document with not just pictures so that the document is trivially large but lots of contents then for example the Holy Bible is a really good test document for stressing the progress bar implementation so I can recommend that. I can recommend that anyway but for progress bar import testing it's also makes sense. Another thing is support for Oaxamal is a constant topic but strict Oaxamal is a newer one. It's something that the newest Microsoft Office supports to some extent and we completely refuse to open those documents because the Oaxamal namespaces are completely different and Marcus did quite some fixing regarding that for Cog and Impress where are you Marcus? Where are you hiding? He's not here. So he escaped but the major part of the work was done by him and I did the docs part of that. So during import now we support the ACMA version the Oaxamal transitional and the Oaxamaster and not counting over the various Microsoft extensions which are also implemented in Word so we are required to access support. On the export side strict is not supported yet it could be implemented but it would be some reasonable amount of work and as long as we don't really have a use case just to have it it's not that important and dealing with other more relaxed specific issues. One more inconsistency the Oaxamal filter is about pattern fields not sure if you can see this but this is not a solid color it's kind of a pattern lots of vertical lines and there are quite some predefined patterns in the Oaxamal standard and of course we have our internal model how do we represent these patterns so on import we try to do some kind of mapping to our document model so that the result will look similar to the original reference output and it turns out that of course this is not a perfect mapping but as long as the output is similar enough then we can be happy except that in case on the export side we don't have the exact same rules for mapping so when you export back then the same predefined pattern won't get returned to the document so it was a matter of finding exactly where the importer has these rules for this particular predefined pattern and making the exporter doing exactly the reverse of the import one and then the predefined pattern won't get lost and my favorite in this section is the long writer paragraphs this was a limitation of the OS string plans and in the binary doc filter I guess we still have this kind of Aurevoir code trying to split up paragraphs into smaller chunks so that writer can handle it in practice I guess this is mostly interesting in case you are copy pasting some content from some web page where line break is used for each new paragraph and not a real paragraph marker and for these paragraphs we are also just importing new lines and not new paragraphs in writer so in this way it's easy to wrap it with such long paragraphs and finally this limitation is gone so the next section is about the not yet released version and I spent quite some time on adding writer-specific text boxes to shapes that means that you can have a shape with a custom geometry like rounded edges or it can be a triangle or anything like that and regarding the text of the shape up to you now you could only use this Adita engine-based text content which doesn't support all the writer-specific features like tables or writer fields or embedded objects like charts or anything more complex so this was on import type you had to choose if you would like to get your geometry and a simple content or complex content but then you use the custom geometry and now it's possible to right-click on a shape or in a writer add the text box and text box is exactly the same as the text of the shape except that the text box has the document model of the normal writer content so you can have both complex content and custom geometry at the same time I still have a few more minutes so I would like to mention a few theater fixes I have done recently we do quite some of these regularly so it's possible that when it's released time we already forgot what the fix was there was no blog entry about that and that but on the other hand these are usually variable so at least now I try to remember what I was fixing in the past few weeks and mention what's possibly interesting so in writer for writer pictures you can have a custom wrap polygon for a picture so this is the whole picture frame in writer and still if you have some stripped down twitter logo then you can have a custom polygon and the wrapping will be performed based on this and not based on the full picture frame and this was imported from the cracks but it wasn't exported and I guess the number one reason was that it's on the import side so the wrap polygon description depends on the drawing of our marker so as long as we didn't fix this VML or this drawing of our frame it wasn't possible to easily export this but as I mentioned that was done quite some time ago so it was possible to finally implement this now if you save back our custom wrap polygon to doghack that's preserved properly and another long requested feature was about the RTF filter in case you had some anchor pictures like not anchored as a character but anchored to paragraph to character to page something like that then during saving all the pictures became in line and the reason for that is that the RTF standard doesn't support this and later from the RTF point of view you can have a picture that's always in line or you can have a shape like a triangle with a blue background color and that can be anchored properly but you can't have both at the same time and the hack that was implemented in Varn is that you can describe such a picture as a shape having a bitmap background and then you can have both at the same time and this hack wasn't implemented in our RTF filter but almost all this is now fixed I'm going backwards the last thing is that or maybe it's not the last anyway I guess it's quite rare that I touch Impress code but it turned out that it was a line in our patch to also import OXML metadata from PPTX and for Kamakand and Writer we did that for quite some time but for Impress all these created and modified dates and here I removed the names would be also here was full of zeros and now this is properly implemented and the functionality was really just the R but a missing method code prevented this from actually working and the last filter fix I would like to mention here is about the Writer HTML export people like to use LibreOffice as a conversion machine and part of that is when random Writer documents are saved as HTML and then random search engines can easily search the content the problem is that when you have some empty document inside the document that's typically written out as a picture now if you already optimized the usage of LibreOffice as a conversion engine then if you are really just interested in the textual output then probably you already enable the option to completely skip images that's why the embedded objects are completely lost but actually in case it's an embedded document or an embedded spreadsheet then we have an idea how to represent the embedded object as HTML because we have an HTML export so what we currently do is that if you skip images then we write the HTML markup for the embedded object and now you can select also the part of the the embedded object so in this case this is a table and this is some text around that and this is a car object actually so you can do this partial selection you can search in it and but not and I guess I'm out of my time so thanks for listening and in case you have any questions then I can try to answer or ok so don't ask the questions thank you for listening