 I am Mike Kaganski from Kalabra, and my talk is some kind of recall of what I have done, fixed or broke in the last year in the area of interoperability. Mainly with other five or four months, but also with different platforms. Okay, I work, as I said, I work for Kalabra for the community, it is a consultancy company helping people to be productive with liver office in cases when they face interoperability issues by helping them and fixing the issues. I want to start with some slides talking about my changes in DOCX and DOC interoperability issues. First, I want to say that this is going to be just a recall of bugs and what I find interesting in those bugs, short recall. So the first bug was about user interface problem that opening some Word documents user couldn't set top position into the most right position. It was interesting because it only affected Microsoft formats while in ODF cases they were fine while the values should have been equal. So I forgot that Microsoft formats and liver office formats used different coordinate system, which was the problem here and it was fixed. Well, the next problem, it was even more interesting because it was the kids when some text in table cells, in open in writer, the text was wrapped, not completely the same as it was in Microsoft Word. And people sometimes are very concerned about such small things when the word is on the first line in one of the suit and on the next line on the other of the suit. Sometimes it is a matter of just some rounding problems when we do rounding this way and other suits does rounding that way. So I thought the issue but it turned out that this was the problem of not completely understanding how Word does its complex mathematics on border calculations and cells space where to write. It was an interesting problem to find out how to solve because actually the standard of OXML does not say much but it was needed but it was also solved. The other problem was just a case of when we didn't support, say, rotation information of images into dockets, which I implemented, which was simply a missing function. Well, and the problem of, that was funny. When we opened Adobe X or OGF documents in LibreOffice with frames in there and in those and took the frame, copy it into the report and paste it into another document. It was fine and worked okay. But when we did it in dog file, took the frame from dog file and pasted it into another document, say, OGF. It suddenly got a frame from nowhere. It turned out that we had very inconsistent code for that in dog and dockets filters. So the work was done to unify this pattern, patterns of code. So now we do it correctly. This was fixed in newly released 6.3. And so of course I must break something. It's not fair to only Google things. So these are my reactions that I introduced by previous fixes, which I heroically fixed by myself. So the frames that were previously correctly working started to have a frame. It is fixed. The second part is when I started to optimize XML writing, I did it wrong, of course. So the fix must be the issue. And the third issue is like the second. A follow-up from my optimization work when several consequent spaces collapsed into one. So if you suddenly see it, please call me. It's my fault. But it should be forbidden to digit many spaces. Yeah, yeah. What possibly it's a feature on the back? Yes, indeed, indeed. Okay, the second part is XML. It's by far the largest part. And first, I made some work to correctly export a column width into XLSX. It turned out that we didn't do it properly. And it resulted in strange things. When we opened ad hocX with some non-standard column width work, save and reload it, and the column width, some of them at least, changed their... Well, when I started to dig into the code, it turned out that we not only did it incorrectly, but also we did it redundantly, saving information for all the thousand columns while we don't need them. So now we do it both correctly and in a more compact way. And, well, the second problem is now fixed, actually. It's work in progress, which is rather driven by NOEL, pending... And while it's not yet fixed, but much progress has been done in this area, both in terms of finally including the work into the trunk and starting to really test it, but also with the fixing of many resulting bugs, many of them are crushers. This starts the part that haunted me for the most part of the year, the problems with popular tables. This is the typical problem that users see when they try to open an XSL6 file generated by a LibreOffice and open it in Excel. So users did complain that we saved or something wrong. And sometimes it is indeed wrong, but not always, by the way. And to say that it's not always the case, I started with this slide. In this slide, three strange problems arose with Excel being unable to... For instance, the last thing is Excel being unable to count characters in cells. It needs us to tell them the characters that you will encounter will be more than 255 characters. That's an insane number, and of course it needs explicit mention in the current year. Well, it will crush the system. So, well, of course, we now export this important information. The second problem is Excel being inconsistent with its own standard. So now, in a way, the standard allows any error message we define by application, but Excel files the whole file without strings that Excel expects. Well, we do the favor and export the very same error message that Excel might expect. And the first one is the strange handling of errors and normal strings as the same thing. Okay. You cheated, huh? You just cheated, Excel. I just what? Cheated. I said cheated. You cheated. You cheated. Well, we made it so that, as it was, there was no problem in that. But, well, it's not always, of course, data fault. We do bad things ourselves. We are good in that. So, the least two problems were about PivotTables, about data fields in PivotTables. The data fields that are not part of original data set, but something calculated by the PivotTable itself. So, it is actually one of the most important parts of the PivotTables. The fields need names. And the names are different in, sorry, by default in Calc and Excel. Initially, we didn't export Calc specific data field names into the file. And it was okay from the former point of view and from the Excel point of view. But suddenly, in Excel version 2016, they decided to stop accepting that. And so, we needed to back accordingly to keep being interoperable with Excel. I did it in two steps. First, I broke everything and then I changed it. So, now the names are stored into the file. And, well, that's a good thing. At least previously, we had the field name changing when we see in Calc is like data sum. And in Excel, the same field will name sum of data. Now, as we export our name, it will be consistent here in the Excel. It's a good thing. And the problems related to not, it is not a corner case, but something overlooked in our previous implementation of export filter, of XML's export filter. We didn't do a good job when our field was present both in rows and in data part of the pivot table. We fixed it. And the second is actually corner case. When that time-based field contained data that differed only in one segment and it was such a situation that rounding would create two same numbers that failed previously. Well, it was a corner case, but of course we needed to do a better job, which we do now. Next one. At this slide, there are two bugs related to formatting of pivot tables. Here we have some fundamental incompatibility of behavior between LibreOffice Coq and Excel. In Coq, first bug is about number format of fields. In Coq, the pivot table defines its own number formats for the results. It is based on the original data in the data set. It takes that information and applies the format to the pivot table. Excel again has a more flexible control of that. We didn't define the format at all when saved the old XML. We do store this format information, which is not as flexible as Excel in Coq, but still we now have reduced current results. So users see dates instead of some five-digit number. Also, the second one is about formatting, like coloring of rows and so on. Coq uses cell styles assigned to pivot table information. Excel uses a different concept and it uses some predefined styles. There is a large set of these predefined formats. In this case, we had an ugly hack, actually, when we simply took one of good-looking presets that Excel uses and started to apply it so that the resulting pivot table wouldn't look just white and white, but attractive, not displaying original formatting, because there is just a predefined set of formats. Let's work around a real solution, something more substantial in this case. This slide is a major problem that wasn't addressed previously in the export of pivot tables from Coq into XLSX. We didn't export group fields, so these fields were simpler than most of the export. Of course, we needed to implement it, and I stumbled five minutes ago. This is between the more dominant models of Coq and that of XLSX. While we implemented and already fixed some parts, you might see the number here, but I will be faster. The next part is about PBTX fixes. It is a very short part. The two problems were related to looping and the automatic start of presentation when we exported presentation to PBTX. Previously, we imported PBTX, and we automatically introduced some 10-second delay, and that prevented using LibreOffice Impress to make some automatic presentations such as the Kiosk one or something like that. That was fixed. We didn't import looping, which was present in PBTX. Now we import it. Assorted issues are mainly about operating system integration. It was a corner case when you download a file which hasn't extension, but has proper content type from the Internet, and the other wants to launch an application it wouldn't find LibreOffice pending those content types. I mean all XML content types. LibreOffice should have been registered for them. Now it is, but it does. Now LibreOffice also allows to read Microsoft log files. So LibreOffice users know who have logged the file using Microsoft Office. And one slide about SharePoint and that where you might see that we did some work on legacy, support of legacy SharePoint versions support that was needed for our customers. And fixed some related bugs that are also found while we need to work on them. And I want to thank our customers who make all this work possible. They pay for these fixes and thus allow all the community to benefit. So thank you very much. Could you go back to the slide please? No, open it back. I'm never, never, never wait. What is the loops? The loops. I mean that's our point. Allow you to make loops through the... Yes. And the press doesn't? And the press also does, but we ignored the information in the file. So we just didn't report this information. How we do. Great, thank you. Thank you very much.