 Hello, everyone. I'm Gabor Klamen, still working for Hungarian National Info Communication Services Corporation, still on the Hungarian Ministry's Migration to Libre Office, and I would like to talk about a little bit of interoperability today, because we decided to go with OXML as tool of interoperability, and there is another source of problems that we have not tried to tackle as a project yet. So, if we try to edit existing OXML files in Libre Office or create new ones, we face the fact that Libre Office is pretty much built around the ODF standard and the feature set defined by the ODF standard, or it is the other way around, I'm not sure. Still, some folks like us try to edit other formats with Libre Office. And we are facing during this a lot of filter-level interoperability bugs that are with saving and opening features that are already existing in both products and both formats. I'm not going to talk about this. Stay for the next talk. Last we will talk about this topic, hopefully. And on top of all of this, Libre Office has some features that are simply not present in Microsoft Office or its OXML format, and we would like to still do something about this situation. So, we are giving Libre Office to users, and users are trying to do their best with the tool given. After a little bit of saving and reopening some files, they still find that their format things or settings are simply gone. And not because we are using some existing features that are present in both software, but because we are using something that is very Libre Office specific. So, it is actually impossible to write those out to OXML because that standard doesn't define anything for that situation. So, that's the problem. Not a huge problem, so to say. Existing features are much larger headache, but still. So, I would like to propose a solution and some examples later. But when we are trying to edit OXML, we should a little bit tailor the user interface to the settings and features of that standard. How? We would like to introduce a new configuration key that system administrators could turn on and also users could turn off. And in that case, user interface elements that are known to be problematic, those would be simply just hidden. And not visible for these users and they could not simply just shoot themselves in the foot. The good news about this is that there are maybe a few dozen situations like this. I have prepared for with three examples. So, one is bug 10132. Subtitle in charts is not preserved in XSX format because simply that is ODF specific. What can we do about this? I think we should just hide the subtitle box in that dialogue. And boom, no way to shoot yourself in the foot. I actually prepared a demo for this. So, hopefully I can show this one. So in LibreOffice 6, you can create chart subtitles like this in ODF. It works very fine until you are not trying to save this into XSX, which we are trying. So, here, I think, it's really hard to see. Moment, please. So, it's Hungarian, but title subtitle and it's on the chart. Very good. What about changing LibreOffice to do instead? 6.3, my current version. Like this. No subtitle box, no way to shoot yourself in the foot. Very simple and I think it should be pretty straightforward to use this approach. So, back to the presentation. The next example, pie and donut charts appear mirrored when compared to Microsoft Office. So, it means that we are, by default, laying out pie chart slices counterclockwise and MS Office lays out them clockwise order. When we try to save this in OXML, there is no option for this to save. So, when people insert pie chart, save it, reopen it and they see it's mirrored. What the hell, did I do something wrong? No, they did not. But still a little bit of source for confusion. But what if we would just change this default rotation setting and people would see the same as with OXML format? OK. Next one. There is no bug about this, but I think we could reduce a little bit of confusion here. So, in sorts we have cell validation as feature and it has a list type. We can just enter items in a list in the dialog window and they appear as validation options. Well, Excel doesn't have this feature, not at all. This type of list doesn't exist there. We can export this to Excel, but with some limitations on the length. But what's worse, Excel calls something list as well, but the list they call is what we call cell range. So, user confusion is absolutely guaranteed because the same thing has different names. But what would happen if we would just hide the list type that has different meaning and different behavior as well? Maybe even we could rename this cell range depending on this configuration key to list. So, users with mixed office environment would be less confused. What's my long-term goal with this? We should try to better fit Libre office in mixed office environments. Our goal is not to completely eradicate Microsoft Office from ministry workstations and all kinds of state-run workstations, but to coexist. And I think this would be a way to help that. And also, I think it could help Libre office become a free OXML editor, which we don't want to be yet. But I think that would be our goal, at least in the NIST project, that simply really hybrid works. So, our users' most common complaint is that Libre office is unreliable. They do something, doesn't go through, doesn't round trip. So, one part of that is because missing features and filter bugs. One way of that could be features that are present in OXML, no, present in ODF, but not in OXML. So, this is just about hiding that part of the footgun. So, that would be it. Thanks for your attention. And I would like to ask your opinions about this, because most of this is just ideal. Nothing is submitted yet to the codebase. So, I would like to ask if this makes any sense to you. Replace ODF for OXML. And leave the ODF part, and a bit like, if you can be enjoying it. But I think, I still think, ODF is better data source. Okay, that's your opinion. So, why not try and go to the ground? Because they said in the preparation meetings for this project, they said it's either OXML or no project. That's why. Okay, next, please. Yes, that will be possible, I think, to warn people. But then you are wasting their work time, because you telling them after they spent a day working on a document that this is not going to work. So, that's my problem. How are you responding to this? Exactly, exactly. Yes? Okay, that's a very difficult problem. And we would need to put a lot of development efforts into making LibreOffice better suited for OXML creation. So far, we have three developers, but we plan to expand our developer base by a lot. So, this is sort of a work in progress. And I would like to see that our developers solve this problem. Because users are actually suffering from it. So, that's one of those things that we are planning to solve in the next two years. Kor? What I think makes sense is changing the default rotation of a pie chart. I'm afraid if you start working in the direction of more support for OXML by default, that you end up somewhere in between that OXML just won't work, because LibreOffice is different, and ODF doesn't work either. So, I'm not sure if I'm convinced yet. This would be configurable for so much of the user base with ODF would not be affected. It would be turned off by default. So, we would just improve OXML, because that's what's expected from us. Cisco? Yes. I'm not sure I can follow, because if there is an existing ODF with this setting, that would be lost when saving to XLSX anyway. So, it's just a way to prevent creation of non-working features. So, that's the goal. And also, already existing ODF files are not very widespread in the user base of ours. So, that's another thing. More questions? We have not really faced this problem, because most of our user base is on Office 2010, and that is not creating such yet. So, that's a problem for the future, I think. Okay, any more questions? Do we have still time? No more questions. Okay, thanks for your attention.