 Hello again. I have a second talk, so this time about meta files which are an important part in the office for historical reasons. They are used throughout the office, unfortunately. And I want to talk a little bit about the problems we have with them and how we could solve these or at least escape in the long run, because we get more and more problems with the meta file format and it's not really good handable. So why is it necessary? Our internal meta file format and filters, they are designed long time ago. This is not bad by itself. It just means with the age of the office of 25 years something at least now. It means the definition can come from 16 bit times. For example, the polygon actions are limited to integer points and the point number to 65,000 and stuff like that. There are workarounds like Microsoft itself which is its own extension of their meta file format. A lot of extra data is put into the meta comment action. Meta comment action means normally it originally was thought to be just a comment and some text, but it is misused more or less with some title to identify what this meta comment action might be and binary data. This binary data normally is from some streaming. For example, there is a solution to get all of polygon, poly polygon data, fill style, line style, all streamed in high quality and double precision in such a file which is then put to a meta comment action and, for example, they are used embedded in slideshow and stuff like that. All big hacks. Even those big hacks are not that bad because Microsoft did pretty much the same which makes the format not better and on their side of the format they even got further than that with enhanced formats of meta files which they needed to do more stuff. They still try to be compatible to the original one and they extended even this mechanisms to put stuff into the comment actions and more of this, even more of this, inside the comment actions, this binary data may again have some comment actions and extensions and there are some mechanisms to also always keep the old stuff alive and when you know the comment action to spool over the old actions and not use them, of course, because they are replaced with the more information inside. It's pretty much the same in our internal meta file format and we are just not capable of handling more complex extended Microsoft formats. Only some actions of GDI plus are supported, for example. So there are often bugs coming in where, for example, there are complex bitmap actions with mapping and stuff like that and I fixed the bug from somewhere where a GDI bitmap with transparency came in and this action was just not supported but it was not too hard to support it because I once sorted out this GDI bitmap loading stuff and there was already a method at least to read a GBA bitmap in Microsoft format. So it was not too hard but it shows maybe one third of the actions are supported, something like this, I think even less and it has not aged well with Microsoft extending the formats because every time Microsoft brings a new format, it's just added to be detected by our filter and since Microsoft keeps its downward compatible itself, it usually works and not too bad because it's very, very basic data gets still imported. And even after years of bug fixing, there are still problems with the file format, you still find errors in it. And the high complexity also comes from being close to the win GDI for historical reasons, when the office was originally created, it more or less ported the original GDI stuff to also run on Linux more or less before it was extended and more intelligently brought forward and the result is stuff like this horrible gradients we have which may be created in just three days and does nothing else than calculating the rectangle and then going inside painting the ellipses and going inside by pixels. So the ellipse will end in a line and not be smoothly painted like you would expect from gradients. And we have multiple importers, exporters because other parts of the office and other implementers detected said they need more information of GDI plus or something and their work around spread over the office. Problems of the current meta file, our own internal stuff is it's simply not transformable and embeddable. So normally what you want to do with graphic stuff is you have your graphic description and you want to paint it with some other few transformation. With meta files you can in principle do it, but it never works because what is used maybe when you have ever looked at the graphic stack you know what a map mode is and map mode is more or less a few transformation and the map mode is just hard set. It's not really a stack. You can push and pop it but no one uses it. Every meta file at the beginning sets more or less a hard map mode. So you cannot embed it into another meta file. Theoretically there is a map mode which defines a relative map mode to the existing one but this again would need to know what existing one you have. So it just doesn't work. With primitives you can just take what you have and put it in other transformation and if you have an ellipse and you put it in a transform primitive you can paint it thousand times anywhere else in other dimensions and sizes and it's always the same object reused, much easier. Static actions and extensions using comment action. I already talked a little bit at the start. It's really not expandable. This is about theoretical because we have our own meta file format. We are free to define our own meta file actions but it is pretty useless because with the new meta file action you have to implement all the parts in the code where meta files are interpreted, created or used. You have to re-implement it anywhere, at any place and when you forget it somewhere you will get bugs and problems. There's no way to make it more simple. With primitives for example you can anytime define your own primitive and as long as it implements the decomposition you can get a simplified version of it and you have not to adapt a single user of the primitive chain. It just calls decompose and uses the simpler representation. That's a huge difference when you want to handle it. It's not really expandable at all. Turtles are just too high and unfortunately it's used everywhere and it's used as data exchange format. Meta file originally was just a recording of paint and someone found out when I record the paint I can replay it and do stuff with it but originally it was never thought as abstract geometry description with which you can do stuff. So geometry processing never thought for it. For example the current meta file has move scale and rotate methods which have to implement all of these single actions all which have to be covered and changed and new actions have to be created. That's what the meta file has to do when you want to move it a little bit and you still have conversion losses and it's used as data exchange format pretty often to get data over the UNO API to get graphical data over the UNO API. We have a lot of cases where the added views or simple objects are rendered into a meta file just to record this. This is all streamed. The meta file and the binary data is then put as a file stream over the UNO API and on the other side it is decoded again. So with primitives, primitive is a UNO API object you can just hand it over much easier. So compared with meta file importers which interprets the Microsoft format and put it into our own meta file format which of this course is pretty close to the Microsoft format. What does the SVG importer do instead? It's an abstract filter module much more modular as independent from the rest of the code as possible. It has a UNO API. The result is a sequence of primitives with which you can work further. So it's UNO API capable and the result can just be returned as a UNO value. The result is reusable as I said before. You can just put it into other graphic stacks by surrounding it by an own transformation or stuff like that. By the way besides the transformation change there's for example in the primitives something to change the colors or to force output to black and white and stuff like that you can just embed it in one of those and use that for rendering. And it has an abstract geometric description with high quality and even when the stuff which is available in primitives today does not cover what you need to import with your filter there's always a very very simple workaround. So you make a group primitive with a type of your own and you don't define a decompose and to default decompose of the group primitive is to hand back the children. So in your filter you put all your data you have imported in this group primitive. Every renderer or user of a sequence of primitives will ignore it because it will process the children but your place where you want to use your imported data can just detect this new primitive which you have created only for this purpose and use your data which you have put there. So this is a really good and backwards compatible mechanism which should be more used and in my former talk I showed some examples and bug fixes and speed improvements which use something similar like that. So may buffer contain preserve original that's also something the SVG filter does it works more or less the same like the bitmap import exporter. These also keeps original. So this guarantees for example you have in the edit view this nice command in the context menu save original bitmap or save bitmap. This saves the original bitmap whatever you may have done. So your original bitmap is always accessible and not lost and this is also working with SVG but not with metafiles because with metafiles it is imported in our own format and so original is not kept. So no access anymore not saved when you save your office file. So what we don't have for SVG is a generic SVG export filter because there is an SVG filter what I mean here is a generic SVG export filter for simple parts of graphics. We don't have that we have a big SVG export filter which iterates over all pages over all objects and makes a good job. So it's not too bad but it would be better if internally for single objects would have a low level SVG which can export single objects and if you would have this to save single objects as single SVG graphics. When we currently do that when you have a single object selected and export as SVG a whole page gets created and always a whole document gets created. So how to get there? First we would need to implement an import export filter for all the Microsoft formats which create a sequence of primitives and no more any of our internal metafiles. During development it's possible to bridge between these both formats because there are ways to get there and to get back so you can render the primitives into a metafile and there is a functionality to change the metafile back to primitives. Both are using very high quality and both use all those hacks. So this should be in some years the last place where those hacks are used. Migrate metafile primitives after development this will still be necessary because of the many places where metafiles are used. So migrate metafile usages to sequence of primitives over time and I hope we find some volunteers to help there to get more and more stuff on the sequence of primitives side. So sequence of primitives can completely replace the metafile stuff on the long term. So and there are possible abstractions. The filters will be similar. Unify basic framework, advance common tooling for them would be a possibility to make it easier to write such filters and all format filters could go that way. Even bitmap filters, bitmap import, export at the moment produce bitmap, bitmapX and graphic and all those structures we internally have many to many for graphic stuff and say could just return a simple sequence of primitives containing the wrong bitmap primitive. So it would be a unified unified internal format to create and get your data around. So direct embedding and rendering preparation data would be the result because what you get from the filters is directly what you put into the rendering process of the editors. Okay. That's it. Questions for it? So this is all future stuff. Not really started, a lot of thinking about it prepared to go but not yet going. And the primitive stuff which we have today does already some of these replacements but maybe ten percent. So lot to do. Questions? How was the time? Okay. Thank you.