 We're going to talk a bit about chart 2 and the new 3D chart that we have been developing for the last year. Now we have a 3D chart in development for the last six months I think now. And before that we were doing some other OpenGL chart stuff. So 3D charts, they are OpenGL based. They are done in a 3D world. So instead of our drawing layer based charts we are not layouting everything more or less transforming it to screen coordinates. We more or less define everything in our 3D world and let OpenGL handle all the difficult work of matching it to screen coordinates. It's interactive, we have some animations in it. So you can take on a bar, we fly in, we show you the value of the bar. You can turn the chart around automatically and that's all animated with I think 100 or 200 frames and it just takes a second or two. So it's quite fast. Yeah, we do all the design in world model coordinates and then just give OpenGL a transformation matrix and it transforms it to our screen coordinates. So a screenshot of one of my test cases doing the same with our drawing layer based framework would mean that we were knowing that it would take three or four seconds if we get the same chart up to 40 or 50 frames per second. Yeah, the colors are not perfect and currently the bar size is still different in the demo. So let's see if the demo works. I poke the OpenGL 3.0 support on Monday when I merged to Mexico. Here we have just some random data at the moment. As you can see, we have apparently some rendering errors in here. I have them in my local build as well. I'm still trying to figure out what's going wrong. But let's see if the dimension works. You can let it turn around. Hopefully that still works. As you can see, that's working as well. You should be able to zoom in and zoom out and the rendering is really fast compared to what's going to be done in our drawing layer based stuff. Another thing that we developed for the same demo is property mapping. The idea behind it is that we want to have something like conditional formatting for charts. Conditional formatting is known from Kalk where they can change the formatting of a cell based on some condition. Now for a chart, it's a bit more complex because the range changes and the data is more flexible. So we need to use a different design and it's much more difficult to define which formatting can be changed. The solution that we have right now is that we can change the fill and border color of a chart to all the calculation for the color in a sheet. So you more or less give the color for your current data point and it takes it from the spreadsheet and applies it to your data point. It's implemented for some chart types like bar charts, bubble charts, column charts but not for all because charts that only use a line have not been supported yet. I will most likely extend it in the future and I have no idea yet how to implement it for different formatting. So there's a direct mapping color to value and back but for other formatting it's more complicated. So I have another demo and I have a normal chart with some values that you can't see the values for column one. Now we have defined here the color values that are defined to the color function and more or less what we do here is calculate based on the value. So it's just a continuous coloring normally and here based on the condition. So if the value is 3, so the last two data points it's colored green and otherwise it's colored blue. And if you train for example here now the value to 4 it updates the data point becoming green. So it's quite nice if you have big data and you want to format some part of your chart but chart data can change quickly and you don't want to manually format all your data. Some other chart development stuff that happened in the last year one of the bigger features even if it does not look like it is borders around data labels so these borders here they look quite innocent but believe me it takes several days or even weeks to implement it. Yeah, if you look at it you'd think half a day maybe if it is lazy but now I know that Core is doing a lot of work there. Then quite a lot of OXML improvements so Cloud1 and Synapseed did quite some amazing work there. Many OXML especially DocX, PPTX improvements they added quite a lot of tests so I make it mandatory for chart bug fixes that they come with the test otherwise I won't review them. We should do that for more modules. Many round clipping issues have been fixed there so you can import your DocX or PPTX show it in the process you lose some formatting but after export it's added again. And from Core high is a number of formats with internal data tables which we improved the support quite a bit and a lot of OXML import ratios have been fixed there. So for the near future I want to maybe work a bit more on the 3D chart framework add a few more 3D charts based on the open shell framework move existing 3D charts maybe to it they are really really slow we have a lot of bug reports complaining that with more than 30 or 40 points it's really unusable move some of the design work that we did there into drawing layer so that other parts of the code can reuse it and we have some window issues so open shell only windows to a window so we need a window for 3D open shell charts and we might get rid of that at some point if we can get the whole deep office open shell enabled so there are some OXML issues that we still have we need more important export fixes Pivot charts are still not supported there are big missing features there is a huge problem with OXML according to the spec and used by Microsoft Office 2010 and 2013 and the dialect used by Microsoft Office 2007 they use different default values so if you fix a bug report by changing the default value because you are Microsoft version just assume that the default value is different you suddenly break Microsoft Office 2007 import we have done that already a few times so I think that we need to look at it again and fix it properly by introducing two different import formats and we have some of the features that are round-tripped based on the cloud-on-synonset work and we might want to implement them in the call so that we have them also used as a little then my big enemy in chat is the internal data table it's more or less a store for numbers that's mainly used for write-on imports it can be used in cloud-on-synonset but there you have normally a cloud-on-synonset and my plan is to drop the internal data table and always embed a cloud-on-synonset document as data source so that we get automatically support for number formats for more complex stuff, more complex features without having to re-implement everything in the data table at the moment for example number format support is well it exists but it's totally broken you can't use number formats at their axis they are totally broken and fixing that is just or is nearly impossible Microsoft dropped the internal data table for 2007 for good reasons and some of the newer features can be round-tripped or can be round-tripped but not re-implemented indeed without dropping it and it would improve the user experience for many or bigger charts because handling big data sets in the internal data table is just impossible then time-based charting we have an experimental implementation it's quite rough the idea is nice but the implementation needs some love and quite some fixing so you can get it to crash quite easily it is not that user-friendly at the moment but yeah, I did not have that much time and there are some timer issues that still run after the chart is destroyed and therefore it is decided in memory corruption similar stuff but yeah, otherwise that would be all that I have planned for chart and would cover the next few years okay, thanks any questions? yes? we are talking about open-gear in general is it the robust data? my experience with open-gear and the certain graphics is that it introduces problems so doesn't it mean if you use open-gear that it will bring some time so I talked about it yesterday I think basically open-gear support is decent the problem is a big old Linux system for example our baseline is on the open-gear 1.4 the question is there how much do we care about systems that are 10 years old or even older and it still wants to run the newest version it's an open question I don't know the solution to it but something like open-gear 2.1 should be on most systems by now and stable enough for general usage so on Windows and Mac we don't have any problems there it's just our Linux baseline that's our biggest problem and if there is no accelerating graphics at all something in the system that doesn't have any accelerating graphics or no more than the old system so on Mac you always have open-gear support even hardware support on Windows you normally have as well so new systems don't come without open-gear Microsoft doesn't ship it but you have a GPU in your system and all of them support it even the newest version on Linux it's... MISA does support open-gear software rendering I haven't tried it yet and the older Linux distributions still ship old MISA versions that only support open-gear 1.4 but otherwise it's fine so you can render it on software on Linux but most of the users have decent open-gear support by now We were playing to the desktop shell but we didn't get to that like it was entirely the other way done this year Yeah, that's the other point so no one is moving to open-gear KDE will follow I think soon but it more or less requires open-gear to some degree so even on Linux you are not going to live but then use stuff without open-gear anymore I think the Raspberry Pi has better open-gear support than our baseline Any more questions? Okay, thanks