 Hello again, I have a second talk, so this time about metafiles 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 metafile format and it's not really good handable. So why is it necessary? Our internal metafile 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 extensions of their metafile 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 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 used, embedded in slideshow and stuff like that. So all big hacks and 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 metafiles which they needed to support 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 more information inside and it's pretty much the same in our internal metafile 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 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 it 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 metafile 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 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 say our work around spread over the office problems of the current metafile our in 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 metafiles you can in principle do it but it never works because what is used maybe when you have ever looked at the graphic step you 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 uses it and every metafile at the beginning sets more or less a hard map mode so you cannot embed it into another metafile 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 it's the same object we used much easier static actions and extensions using comment action I already talked a little bit it's a start it's really not expandable this is about theoretical because we have our own metafile format we are free to define our own metafile actions but it is pretty useless because with a new metafile action you have to implement all the parts in the code where metafiles 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's it's it just calls decompose and uses the simpler representation so that's a huge difference when you want to handle it so it's it's not really expandable at all it hurdles are just too high and unfortunately it's used everywhere and it's used as data exchange format metafile originally was just a recording of paint and someone found out oh when i record the paint i can replay it and do stuff with it but originally it was never thought abstract geometry description with with which you can do stuff so geometry processing never thought for it for example the current metafile has move scale and rotate methods which have to implement all of these single actions all which which have to be covered and changed and new actions have to be created that's that's what what's the metafile has to do when when you want to move it a little bit and you still have conversion losses and it's it's used as data is changed 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 simple objects are rendered into a metafile just to record this this is all streamed the metafile and 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 metafile importers which which interprets the microsoft format and and put it into our own metafile 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 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 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 with a type of your own and you you don't define a decompose and the 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 every renderer or user of a sequence of primitives will will ignore it because it will process the children but your place where you want to use your imported data can just detect a sys 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 I in my 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 originals that's also something the svg filter does it works more or less the same like the bitmap import exporter sees also keeps original so sys guarantees for example you you have in the edit view sys nice command in the context menu save original bitmap or a safe bitmap sys 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 meta files because with meta files it is imported in our own format and original is not kept so no access anymore not saved in when you save your office file so what 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 said 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 when it internally for single objects would have a low level svg which can export single objects and if we 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 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 meta files 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 meta file and there is a there's a functionality to change the meta file 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 my great meta file permit and no after development this will still be necessary yeah because of the many places where meta files are used so migrate meta file 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 primitive side so sequence of primitives can completely replace the meta file stuff in 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 normal at the moment produce bitmap bitmap x and graphic and all those structures we internally have many too many for graphic stuff and say could just return a simple sequence of primitive containing the wrong bitmap primitive so that would be a unified file unified internal format to create and get your data around so direct embedding in rendering preparation data would be the result because what you get from the filters is there directly what you put into the rendering process of the 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 is time okay thank you