 My name is Juan Alvaro and I work with the Ganon-Canada and the last company I turn this as a software developer. I started to work on the fixing child bugs around last August. I fix more than 50 omics on a child interoperability bugs and other child usability issues. For example, import of hatchery style and background code in charts. Import and export of assistive rotation and text break. Export of videos, data label properties and import of current data label separator. Export of error writes. Import and export of distinct data point labels. And fix several bugs that are related to axis and implemented complex axis labels in dots. And include import and export of secondary axis and complex charts. So, this is an older presentation. So the last fix is about the internal data tables. We are happy in this presentation. So let's take a look at what has evolved in this area. There are two bigger problems at the import of hatchery style. We couldn't import a hatch-style and separately the background code of hatch-style. Instructing an assistive hatch or creating a very few hatch which stores values in a proper container. Save the source of the first upload. Before this, the charges appear with a default horizontal realize. So instead of the correct style. Now almost all of the hatch-style from Microsoft Office are supported by the video office. And they have your correct list in both of the programs. Also, the background code is the same as the original code now. You can see on those pictures. So, the following slide shows the fix where the axis label is finished and back. The image in the video shows the original slide. The last one shows the background code. Everything is broken. You can cover it on the mic while it's broken. Sorry. So I will talk longer. It is enough. Thank you. The image in the video shows the original slide. The last one shows an export from the video office 6.5. And the right image shows a good export from the video office 6.2. The problem was solved by reflecting the angle. Its tax rotation is between 90 and 270 degree. And the recalculated tax rotation between 270 and 0 degree. It is because the original ground is broken. So the following slide shows the fix where the axis label and the text break. The problem was that the vertical axis label couldn't be broken into multiple lines. The picture level illustrates the issue. And the picture below shows how it looks like in LibreOffice 6.3 after the fix. The following slide shows also the axis label rotation back. When they are opening an OXML file in LibreOffice it is expected to have the style and appearance of the original file from Microsoft Office. Our longer style text and the label along the X axis were not broken automatically. The picture will illustrate the bug before the fix. And the picture below shows how it looks like in LibreOffice 6.2 after the fix. On this slide there is an export problem with individual data label properties and an import problem with data label separator. As you can see the single data label format didn't disappear and the document was saved as an OXML. Another problem emerged with the data label separator and an opening OXML argument that was created in Microsoft Word. The new line separator has turned into a study problem. To fix the individual data label the correct X label process had to be exported. This prevents forwarding from disappearing. To fix the data label separator we had to set the separator to a new line. Its axis separator is not present in the XML. On this slide you can see your bug from the export of error bars. After saving ODS or OXML file to OXML and reloading it the error bars disappeared. They were closed but they have become invisible. It was their lifestyle by set to know. Other properties were also disappeared. The solution was very simple because we just had to export the shape drops, freestyle, lifestyle, line by line, etc. of the error bars to OXML. It was completely missing from the chart export. On the next two slides I will show you two error bars that have been repaired for years. This one has been repaired for several years. Here on the left you can see the opening. You can see that the opening is attached to OXML file. Libro is duplicated back to the grid lines with their corresponding digits. There were several reasons for this bug, such as problem errors and number formatting errors. For example, 0.5 appeared as 1, etc. or the distance between the two tick marks. If the labels with the same value follow each other due to the incorrectly applied number formatting, then we don't duplicate the labels of labels on the axis. It is fixed. The display of these labels is better. In Libro it is better than in Microsoft Office. It is because they match their distance between the tick marks. If the distance is larger than some other value, then the same label appears twice. On this slide there is another older bug. The legend appeared without the labels when we opened Microsoft Office. The problem was that in Microsoft Office there are no admin data-series. However, data-series with default name and no name exported to OXML. Also, Libro is interactive or anything, but there are legends without any names. The best approach to fix this bug was to provide the method in child module that replays the absence of the name of series with a correct localized one. It also works in case of OBS or what. In the back I will talk about how serious data loss during export and import. For example, on these pictures you can see that the labels on the Z-axis show the wrong data after export. The picture on the left side shows the export from Libro Office 6.2 and the picture on the right side shows the export from Libro Office 6.3. To fix the data loss, we have to export the properties of Z-axis into a serious X-axis semantic. Let's see what has improved on the data points in Microsoft. There are three annoying problems. The first one happened in the green screen. The data point in Microsoft is set to none. But it's not an empty green screen called display the black screen. This is now fixed as you can see in the right picture. The second one happened in the purple screen. Data point symbols with undefined field color attribute were imported as invisible white symbols. It has been fixed by using the line colors on that. The third one happened in the blue screen where the data point symbol has an individual property. A property that is different from the data sequence property. These other properties weren't exported at all. The solution to this problem was to export the custom for individual data points Microsoft into an entity. On this slide you can see the export of the chart subtitle before and after the fix. The picture on the top shows charts with titles and subtitles. The picture on the bottom shows charts with only subtitles. The subtitle was added to the chart. It wasn't, say, 0.7 at all because 0.7 doesn't support subtitles in charts. The solution to this problem was to concretely subtitle the main title text if a vote exists. This is the same method that is used for custom export. There is a subtitle rule to avoid data loss. The solution is to export the subtitle shape instead of the title shape and keep its properties. On the next two slides I will show the improvements made to the secondary axis and the combined charts. A lot of that belongs to this area and these are not all done. On the picture in the middle you can see the original ODS file which looks fine. On the last image the original file was rounded in LibreOffice 6.2 and reopened with it. On the right picture the original file was rounded in LibreOffice 6.2 and reopened with Microsoft Office. By looking at the pictures on the side we can tell that there are many problems. For example, the primary and secondary axis are swap. The secondary y-axis is primary, the x-axis is main. The disappear and the data series are attached to the wrong y-axis. An opening of the combined charts in Microsoft Office after it was rounded in LibreOffice. It looks completely different from what it looked like after creation. Let's see how this looks like now in LibreOffice 6.3. The middle picture shows the original ODS file which looks fine. The left picture shows the original file which was rounded in LibreOffice 6.3 and reopened with it. On the right picture the original file was rounded in LibreOffice 6.3 and reopened in Microsoft Office. These images are a lot more similar to each other than they were before the fix. The secondary y-axis and primary axis are visible. The main reason is also visible. The data series are attached to the correct y-axis. Of course it took several touches and part fixes to achieve these results. On this slide you can see the result of four bigger fixes in the field of complex category axis labels. The first problem was that the x-category axis labels disappeared from the chart and the data disappeared from the inner data table. Now complex category labels are visible and the inner data table contains the correct text of the category columns. The fix wasn't a simple task. None of the multi-level string reference, the multi-level string cache, oink and lever count, X and Y tags were not imported or exported at all. Besides the oink's import part, the multi-levels of the category axis in the chart module had to be managed too. So let's take a look at the export part. The multi-level category was created in the right tag and saved as a prefix. The two or more categories were congratulated and saved as well. To counter this, the categories are now split according to the level. The last part of the solution was the view of the rotation of the different levels. The chart after the fix looked like the original from a natural fix. So about our future plans, currently LibreOffice only supports one type of combine charts, line and color combination. We are planning to go at two or more combine charts, if not in the mode of the event importing files. We are planning to work on the correct import of custom data labels, LibreOffice writer. To achieve this, we have to prevent data loss, first which currently happens in the import.txt file. In order to entirely start the data loss first of all, the first part of the unsupported.txt data labels or named as custom labels must be implemented in ODIF and then in .txt. And also we will continue to reduce the number of chart bugs, especially the import and export of OXL files. Thank you for your attention.