s data structure and it still didn't help and then myself and Lubosh worked on the string pool together and we improved it and it was great for a while and then this year I locked it again and the shared string pool came up again in a in a profile of a problem document and I stuffed in the lockless data structure and this time it made a difference so the answer is lockless is genuinely not the answer except when it is because you tried everything else so this particular time it didn't make a difference and we used a quite nice little library called libcoucou which is a concurrent hash map and that improved things nicely the other option is multithreading so we have multithreaded a few things we multithreaded the calc load and we multithread the loading of an unzipping of zip files in the background and this is great to speed things up but multithreading keeps bringing in regressions it's just really easy for the initial work to be fine and then later on it turns out that in certain scenarios you're accidentally touching some code which is not using a mutics or you're touching some code which is not using atomic reference counting and things fall apart so we use multithreading where we can but we acknowledge that it is a problem in the code-based side of LibreOffice where it is very hard to cordon off things and be sure that you've gotten all the edge cases there we've had to debug several not many personally but other people that had to debug lots of multithreaded related issues and consequently so we treat this with great care because it doesn't it doesn't always provide the magical land and also when you're dealing with multithreading you often find that you multithreaded and it's just as slow as it was before and that's because you find yourself hitting shared locks or you find yourself having to put mutics around pieces of code to protect them because they've been called from all the threads simultaneously and then as soon as you've done that you discover that all of your threads are now ganging up on that one mutics and then you've got no benefit so multithreading is nice but then you have to do a whole bunch of follow on work that's follow on work recently where I had to take mutics as out of pieces of code and convert that code to immutability so the code was initialized once the data structure was initialized once before the threads were created and then the data structure didn't change after that so that the threads could all hit it simultaneously without needing to take locks and that worked out very well and that is actually the end of my talk let's see how we're doing well the children are expected so any questions? well right now we don't have any in the chat but I will ask the author of those great drawings those are a benefit of my children I asked my children to draw some pictures for me and they very kindly colored them in wonderful okay great that's me I'll hang around in the chat if anyone wants to ask questions or anything absolutely the stage is yours for the next 5 or so minutes we have a question from Quickie what change resulted in the biggest performance gain? sure I think we got some really great improvements in the redlining code either the redlining code, I forget either the redlining code or the notes code in writer where we accidentally had an 0 in 3 algorithm where there was a loop inside another loop inside another loop where it was iterating over the same thing again and again and that took a little while to sort out because it was crossing over between two different sets of code and we had to pass iterators up and down between stuff and that produced some really nice gains that was like wow first time I ran it and worked I was like surely I did something wrong it can't possibly be that fast and that was really great but most of the time the wins are pretty small often I'll have tiny gains you can add up over time if you kind of have four or five small simple gains you'll end up with a decent size gain because suddenly you've kind of crossed a magical boundary and now you're fitting inside the CPU's main cache and it magically gets a whole bunch faster I see there's a question from Kendi sure let's fire up okay let's fire up I am the question from Kendi is about the tools you're using or even screen share how you use them sure so let's see if I can get this to screen share that one you should be seeing Intel vtune analyzer now vtune profiler yes this is a free tool from Intel it's really nice only runs on used to only run on windows I believe it now runs on likes but I've never tried it there because I use different tools on likes so this is called Intel vtune profiler it's part of the Intel vtune suite it has its limitations but it's pretty nice so for example I've got a configuring analysis now okay okay this CPU is a little bit old and doesn't want to do that so let's switch to user base sampling it's a sampling profiler and it comes with all the limitations of sampling profilers if you're trying to find extremely small performance problems then this is not the right tool for it because it has limitations because it does sampling as opposed to something like valgrind which is an emulator which can collect much finer grain stuff but I haven't found an equivalent for valgrind on windows so when I need to do extremely fine grain stuff then I'll switch to your linux and do a valgrind run there so for example here I have configured it with my applications pointing to my application I've passed in some parameters so it will load a file I am switching on some user defined variables here so that for example it only profiles I've using the exit post startup and disable recovery so that it won't get it won't try and profile the recovery process and it will only profile the opening process so then we run it and it will fire up it's now running then which may not may or may not work okay it's not very happy with my Vulkan driver right now okay so now it's managed to pull a profile and it's now post processing the data that came out of there and you end up with a relatively nice summary here this is if you look at this histogram at the bottom here you can see that LibreOffice is making extremely little use of of the of the CPU and in fact we're only using one call and we're not even doing a wonderful job of using one call so but that is in part just because of the nature of our application our application LibreOffice is not amenable to very good usage of the CPU because we are we have very complex data structures and that requires bouncing around a lot in memory and so you cannot really ever get to the point where you make extremely good use of the CPU except for a couple of narrow use cases in CALC where we managed to show some decent usage of the CPU now this profiler typically will work in the bottom up view it shows you the points that are the threads at the bottom here you can see the different threads that are active and as you can see there's very few of them and these are the things that are that occupy the most CPU time here and this is the bottom up view so it starts at the bottom part of the stack the last part of the stack bottom or top depending on which way you think stacks grow and you can drill down into it where those pieces lead to who's calling those pieces and what what was calling you can also do the same thing from top down tree so you can look at it the other way depending which way is most comfortable to you right now and you can drill down and see where the time is being spent and here we can see for example 18% of the time was spent inside the splash screen code that's because I don't think it actually loaded the document this time and then you can see it's spending time in BCL event lessons there and you can double click on stuff and it will actually open the source code for you which is really nice you can't edit it or anything like that but at least you can you can look at the code and then go backwards and forwards between the code and and the stuff and you can inside each one profiler you can pull up a section of it and tell it to filter in on that piece of the timeline so you can narrow you can drill down into pieces of the timeline and see which pieces were what was happening at certain points in time and similarly you can make it drill into the different parts of the thread you can make it drill into different pieces of the thread now this whole application is quite similar to KDAB hotspot which is a Unix program written by the great KDAB team and that does a really nice job as well I can't show it to you unfortunately because my Linux machine is at the other end of the remote desktop connection that doesn't work very well with screen sharing but it is quite similar to this and if you're only on Linux then KDAB hotspot is a go-to tool and is very similar you run a perf trace which also is a sampling trace and then you feed the perf trace into hotspot and in fact I believe I gave a talk about that last time at Elmeria and that works pretty well it has flame graphs as well which is really nice which this doesn't have okay great that's me thanks excellent thank you for this really honestly enjoyable talk I'm glad to see that their performance improvements coming to Lever Office alright so next up we have Lohamer sorry if I tried my best and Christian Lohamer sorry he goes by Klopp and his is a pre-recorded so if you sit back well I'll start it right on the dot so I'll give people a few minutes to congregate in here yes it's pre-recorded and there are two versions one has the audio boosted but otherwise it should be identical yes I was going to use the audio boosted one I assumed that was the preferred one but perhaps I should have checked no that should be the one unless someone gets heavy distortion then we should switch over alright now officially we've got Christian up and he is speaking about the crash reporter service in Lever Office hello and welcome to my talk about the crash reporting service used in Lever Office it is a pretty short talk it's I try to stay pretty much on the top level side of things and the talk is structured like you see here just short introduction as always then from the most high level to a little bit more detail about how QA can help with the whole process and showing some limitations and problems that the current setup has and then it's already time for credits and things of prior work and question time so let's dive in with who I am I'm Christian Lohmeier I'm mostly known by my NIC that I use everywhere which is cloth I work as a release engineer and infrastructure administrator for the document foundation and have been with the project since it's creation and before that I was active in the open office org project so I have been around long time and always on the infrastructure side or build bot side of things I hang out on IRC also with the NIC cloth and you see my email here cloth at document foundation org is another way to contact me so to the actual topic of the talk the LibreOffice crash reporting service and on the high level it's just the first question that comes up is why use a crash reporting service we have a framework of so many automated tests already for example we are using a Garrett for the review process of patches and each patch that is submitted to our Garrett system is tested on all platforms and basically all are built in checks run on each test by running the build time tests in addition to those tests we have we are using different static analysis tools like for example the one provided by Coverti and others like for example the fuzzing tools by Google and those already catch many problems we have in our code without actually hitting the end user and we have also a pretty extensive set of documents that we run our import and export and re-import basically round trip tests on that should cover most of the problems with our import and export filters and crashes but of course even with all the systems in place we cannot prevent bugs from happening and especially cannot cover all hardware combinations and certainly don't have the workflow of each user covered for example different order of operations can lead to different results and that's why it's important to have an additional source of information especially for a disruptive bug like a crash that could potentially lead to data loss so that's also the way what we are using to build our crash reporting service is basically Google Big Pad everything hinges around the Google Big Pad project and this is the component that creates the mid-dump when LibreOffice crashes and is also used to basically unwind that information back at the server level and the benefit of using a tool like Breakpad is that it allows for decoupling the debug information from the application that you ship so and of course we also need a server to collect the reports and for that we have a small jungle web application that collects the reports that are coming in and also is used to basically map the stripped down information that is created on the client side on the end user side against the full set of debugging symbols we keep on the server so that we have working backtraces and basically point us to the actual source code after everything is processed and we also have some integration between the crash reporting site and our bugzilla so both systems can cross-link to each other and have pointers to each other for further information to provide steps to reproduce to hopefully attach sample documents if those are near a cesare and yeah this is a big help in the process as I go to in our later stage in this talk so if going a little bit further into detail what is involved in going a little bit more in detail on the let's dive in what is actually involved in providing a build so it can be used as a tool for collecting crash reports so of course the first step is to create a build that has the debugging information in the first place so if you don't have debugging symbols even if you have a mini dump it's more or less useless because human brains cannot work with pointers and there needs to be a way to unmangle this and track it back to actual code functions and files and lines in those files to be useful so after the build is done with the debug symbols breakpads dump symbols tools extracts them and basically converts them into a format that is common across the platforms and is uploaded to the server and allows the server to unwind the symbols back to their human readable form basically and the debugging symbols are stripped from the Libre office that is shipped to the end user so it can be a relatively lean and doesn't have to be bloated just because of the debugging symbols of course Libre Office is still a rather large package but if it were shipped with debugging symbols it would be multiple gigabytes in size and of course once Libre Office crashes the breakpad tool creates a basically a snapshot if you want of the state that is run currently and we don't want anything that could interrupt the current creation of this state so that's why we don't try to do anything but just to create this mini dump so the interaction with the user whether to report the crash or not is all deferred to the next launch in order to just not mess with the the state of Libre Office after it crashed and so the prompt that the user gets looks like this basically a simple confirmation dialogue that for each crash ask basically whether you really want to send this information and you can disable the reporting globally in the options then it will never ask and will never send a report but if you have enabled the crash reporting in the options you will still have the option to not send any report on each occasion and the dialogue also has the option to not Libre Office in save mode in case it's a problem that is not tied to any actions but happens every time you launch Libre Office so it's another feature that we have in here and so the user then agrees to send the report and Libre Office sends the relatively small mini dump file it was created to the server and the server encodes cheats a little bit by not processing it specifically but just assigning a unique ID to the crash report and reports that back to Libre Office and the user can use that link to go to the crash report site and from there it has the option to create a bug report providing more information about the crash itself and hopefully all reporters actually do this because this having steps to reproduce a problem is basically the the most important thing that helps QA in processing and judging the importance of such a crash and if you're using the functionality to create a bug report we make sure to automatically include the necessary information so that both the crash report inside can add a link to the bug server ticket as well as having a link from the bug seller to the crash report and with that information hopefully QA has enough information or at least is able to ask the reporter the person having the problem for more information to further track down the problem and the dialogue with the response basically looks like this is very simple it's just the link with the unique ID that the user can visit and of course hopefully they do and provide more details and I said I'm going to go back to what is actually included in the minitab I glanced over it and said it's a snapshot of the state and yeah it includes the files that were loaded, the libraries and executes it contains the files that were loaded, the libraries and the executables and it all contains all the threads and the state of the processor registers and the stack memory at the point of the crash and then some additional meter information like the processor used to run the system the operating system and version and specifically for LibreOffice we also of course include the version of LibreOffice itself and we are also interested in whether OpenGL was enabled or not and what the driver for the graphic card was and what version it was so we include this as additional information in the minidump so next we have the problem of users report the crashes and what's next and this is basically where QA team comes into into play and completely over simplified QA's role is to monitor the crash reporting side and have an eye on clusters of reports that are new that indicate there was a regression introduced in the latest version and then going the next step further create test cases or at least reproducible steps by step by step instructions to make a tracking down the source of the problem easier and of course to also be able to verify a fixer in the later stages of the process and this is a easier said than done of course but yeah and this is easier said than done of course but hopefully the information given in the stack trace regarding the code that was affected as well as hopefully having a bug report with some background information about what to trigger the crash will make this a little easier and still of course if there is no corresponding bug report or even if the source code information isn't enough to help track down the problem or doesn't give you an idea and instead of trying to read hundreds of thousands of lines of code you just want to do the practical brute force approach you can use by bisecting and bisecting is short for binary bisecting and this just means that we have a git repository with binary builds of LibreOffice for all active branches and you can use the git bisect command to very quickly track down a change that caused a change in behavior basically and without having to compile a whole version of LibreOffice between each step and the benefit of is that you can track down a problem without any knowledge about the code itself you just need a way to reproduce the problem and then anyone with a little disk space to host the repository can basically test one revision after the other and it always checks half of the remaining commits and always of that half the other half so it narrows down pretty quickly even if the number of commits that you start with is very large the number of steps are probably 10, 12 or 15 at most in any case and then you have either a single commit or a few commits that are affected and causing the problem and with that information of course you can have a look at who was doing this commit so what were they trying to fix most often than not they have an old bug report assigned to it with the intent to fix this bug and of course having that information makes it easier to judge what other actions might have caused the regression from the regression to happen and yeah after you have tracked down the problem using a Bibersack repository even if not knowing what the problem is itself you have someone who committed code touching the area and this of course is a hint who to poke basically who to nag about the problem or who to ask for more insight and this helps great ways to to further proceed in getting a fix done for this particular problem and QA while not necessarily doing the actual fix is pretty good at providing these cases to prevent the regression from happening again of course this depends on the type of problem but if it's a problem with a file format for example it's easy to just add a sample file to the code and check that the problem doesn't occur anymore and next on some problems or limitations with our current deployment basically and it's hard to say whether it's really a problem but of course people don't update to the current version at least not as frequent as we would like them to do and thus we have lots of reports coming in that are from people using old versions of Lira Office with problems reporting that were already fixed in current versions so this of course kind of skews the overview towards old crashes because the user base of new versions is relatively low or starts growing as time goes on and the old versions are the ones with the problems that are not yet fixed so just looking at the raw numbers doesn't give you an indication what is really happening with the current version and the Lira Office crash reporting website has some filtering options at least the starting page allows you to have a quick overview of how many reports were committed for each version that is of interest basically the final release versions and then has an overview of those versions of the reports assigned to that version but if you go deeper then you have all reports from all versions so the filtering capabilities of the Django web app could need some love to make it more usable to be able to exclude versions from the listings for example or just focus on one single version to check that it was fixed in an RC for example and not just the main code line version for example and so far we also didn't remove any old reports from the crash reporting database or of course it grew quite large over the years and I don't have any immediate plans to clear out the old entries at some point I probably have to do it to keep the size manageable and to keep the database query times on a reasonable level and another limitation is that it's only available for Windows and Linux but of course Mac users are relatively user-based compared to Windows as well as Linux users compared to Windows users so I don't think it matters too much to not have macOS in there and Windows crashes and Linux crashes alone are enough to deal with basically there is no lack of reports coming in but another limitation is of course that it only works when you have the corresponding debug information on the server side and this then in turn means that it's only available for builds that are done by TTF, by me basically and only for the alpha, beta, RC candidates basically but none of the Tinder boxes or daily builds have this integration and don't have the crash reporting enabled and this is basically the technical side of the limitations of problems and of course there is the other aspect that I already touched upon that not all users go through the process of filing new information especially if they don't have a Buxilla account already if this is a big hurdle for them so they either don't even visit the site to file a bug report or they stop there and don't proceed further and also those who do actually file a report it's not clear whether they can provide enough information to have steps to reproduce the problem so still a lot of the burden is on QA volunteers to basically track it down, try to find a way to reproduce it, try to find a developer who can have a look at what's wrong and yeah it's just as it goes with all problems people either complain loudly about it or they stay silent and complain about it with their neighbors but not to report it and there's no real easy solution to fix all this because either you make it so easy that every spam bot can abuse your system or you have some login system in place that scares people away so yeah it's always a balance you have to take and we have enough reports coming in that I think are now reasonable to act upon even if not everyone can add a comment and of course having a comment system that allows everyone to comment also gets into the data regulation problems because then you have no control about what is filed and how people would access this information and how it's shared so having a system that has its own management lipoxilla makes it a little easier and this basically is it already for the pre-recorded portion of the talk I'll have enough time for questions I think but of course I don't want to leave without giving thanks and credits by credit is due and most from it is Marcos Mohert Moge he basically did create the system for LibreOffice 5.2 I think it was 2016 so quite a couple years back he did the bulk of the integration and wrote the Django and taking some inspiration from Socorro the tool that Moge was using for their back reporting and also Nobbya Thibault had a lot of work done in the infraside of things he was basically setting up Garrett and other double rail related stuff back in the day and then there was also Ricardo Marguercetti and I sorry I probably butchered the name Albuquerque Estimier contributing to the server side of things back in the day and of course all wouldn't be possible without having the breakpad utility available so have a link to our main repository and of course links to our Cresher parting side and our Vaxilla and basically now I'm ready to take questions and switch over to some live mode and maybe can do some live demos if necessary and of course thanks to all the sponsors making this conference possible thanks I'm going to wait just a few seconds so that any one with buffered videos can finish up I saw a question on the room regarding backtraces not being resolved against the symbols and this was a problem with the symbol extraction step so the dump sims process did frequently sec fault when processing the symbols for Windows 64 bit and our tooling didn't bother to check for any error during this processing and this has meanwhile been fixed and it should resolve the symbols again so it was a problem that the debugging information on the server to unwind the symbols wasn't complete and yeah but for current versions it should be all in the good and of course the old original reports are not resolved but even reports for old versions should now be resolved again since I also updated or re-uploaded the debugging information for old versions and yeah to add on that the problem still happens so the dump sims to still sec faults frequently while processing the symbols but it's just retried until it does succeed for this given DLL or XFL and proceed to the next one so running it multiple times until it succeeds so I didn't really bother finding out why it crashes or how the crash can prevent it as long as the result of a successful run gives the same result all the time so I'm confident that the data is correct if it works and only have to re-run it when the process sec falls and maybe just to show the crash reporting side as it is now basically on the landing page you're seeing the the number of crashes submitted per versions and so the different colored lines represent a single version of LibreOffice and you see that around 400 to 600 reports are coming in per version and of course you see the slow rising lines at the bottom that is the new releases that slowly gather a user base and still most of the reports are from old versions if you're actually using it I'm not sure whether you can see the mouse however in the screen share there you should get a breakdown of the versions and the number of submitted crashes at that specific date and if you go to the version select on you can select for example the 7162 basically the 716 final release and yeah it's a little bit slow for me right now the demo effect okay now that you see a listing of the crash reports and the signatures for that specific version so for example here you see a Skiya related one that is happening or was reported 74 times for windows in the last 7 days so the time frame can be chosen at the top and if you click on that you would get to the number of individual submissions and you can click on one to get basically the stack trace you see the function signature and the source code file where it happens and also the cross-linking to the bugzilla and clicking on that gives you the bugle port history basically and it turns out it was an optimization that uses a processor features the AVX instructions despite not checking for actually support on the hardware and it was fixed pretty quickly then and it's fixed for a 717 and for a 722 branches and just showing at the top the information that the crash reporting site would add so this bug was fired from crash report and there you have the idea of the crash and this can be used to go back to the crash reporting site to see it and yeah this is basically for the collect we have the version of LibreOffice the idea that is used to uniquely identify the crash the processor architecture the operating system and the operating system version yeah this is basically all this and I think I'm also out of time now if there are any questions I need to have a second look we don't think so so yeah then I guess I'll leave the stage and give the next presenter some time to set up I think it's not a pre-recorded one so yeah thanks for listening thank you Klauff yes indeed we have next up Marco Cicchetti and some improvements for the SVG export filter Marco are you around yes so yeah excellent your mic is a little bit low but otherwise sounds good okay I try to share my screen so I suppose now you can see it you can see the editor but not the presentation if that's what you're going for so now you can see it yes everything's great thank you so the improvements we are going to see for the SVG export filter was all about the exporting the background of the slide the first topics about be able to export a slide that owns a custom background in fact one of the features of it by Impress is the ability to set a custom background for a slide instead of using the background of the master page linked to the slide this feature was not working since the last presentation shown always the master page background instead the one used as custom background I suppose you are familiar with the basic code the SVG markup language anyway I want to remind you the use element this use element allows to reuse more than once an artwork simple rectangle allowing to change its geometry and style feature so we can define an object just once and use it many times and that the use element is exactly what is used for getting a single master page rendered in each slide anyway the master page is not referenced directly by the use element because a master page has some content that is customized by each slide or even generated dynamically such as slide number date, time or a slide that owns a custom footer when a slide needs to be rendered the JavaScript presentation creates a group of use elements referencing sub-object of the master page instead of the whole master page in order to create this group of sub-object references that is a specific class named the master page view what we are interested in this case is the first use element reference the master page background in order to get a custom background supported correctly we need to quantify this class in order to make it aware that slide owns a custom background so that instead of referencing when it creates that use element the background the master page it references the custom background the master page view class for creating this structure needs some metadata information about the slide this metadata information is represented by the slide number and the visibility of the several text fields that made up the the master page and even other kind of information the metadata is supported as custom attributes all we were prefixed that in the example below you can see for instance the master custom attribute that specify what is the ID with which the master page related to this slide is supported in order to make the master page view aware that the slide is using a custom background we have introduced a new attribute named as custom the ground the generating metadata method that export this group of metadata information checks if the field style property for a background slide is different from field style none and in that case up and to the group element a new attribute that you can see in the example below in red in this way the metadata the metadata slide class that is responsible for parsing in the JavaScript presentation in all these attributes and transforming them in properties of the the instance of the metadata class itself is able to provide information to the master page view class so that it can know if the slide is using a custom background and then referencing the ID of the custom background instead of the ID of the master page background in the user element we have seen in the previous structure so getting a custom background working the second step is provide the ability to use a bitmap as background now a spotting bitmap as background was used as a work round because the same bitmap was spotted many times that occurred only when the same bitmap was used as a custom background for several slides but also when a bitmap was used as a tile in that case the same bitmap was exported as many times as was the number of tiles obviously that lead to an exported SVG document very huge and the slide rendering in the browser was horrible in order to solve this problem we have modified the create object from background method of the SVG filter class this method in order to export the background of a slide of a master page used to create a GDI metafile for the object that made up the background of the slide this metafile then is passed to an instance of the SVG writer for converting its meta action in one or more SVG element so that the background gets exported we have added a new task to this method the method iterate on the meta action present in the metafile and call it all meta action related to bitmaps and use it for creating a map a map whose key is the checksum of the bitmap embedded in the meta action the checksum is dependent from the bitmap position so we have a single metahantry part each bitmap once we have collected all this meta action related to bitmaps we can export image element that represent the bitmaps we have implemented a specific method named import background bitmaps this method iterates over all the bitmap action present inside the map we have populated here and for each entry in the map it creates an image element the image element then is referenced for is referenced by one or more used elements at the place where the custom background for a slide is defined or more than once for the same slide in the case the image is a tile in this fragment you can see a slide whose background is a tile of the background and as you can see the used element is exported are more than once and the reference to the same bitmap the this occurs inside the write BMP method of the SVG action writer class which usually is the default for bitmap meta actions the bitmap is passed to this method and then is exported as an image element we have modified it to compute the checksum of the past bitmap and in case this checksum is present inside the map exported instead of the image element a used element we have a trasmatribute in order to set up the bitmap to the appropriate position size and the href attribute set to an ID that contains the just computed checksum of the bitmap that is the way we get bitmap used for for custom slide background or for tile background exported only once and then rendered correctly by the javascript presentation gene no modification to the javascript presentation gene has been necessary this solution was a big improvement but this did present some problem for the tile background case the problem is that when when they use elements are a large number it's expensive for the browser rendering them so if it has a background as a large amount of tiles as it occurs for background of type pattern or edges we end up having many tiles because these tiles are very small the result is that the browser can need one or two minutes for rendering a slide in order to solve this problem we have used the SVG pattern element the pattern element allows to define some some object some artwork that then is used as a tile for filling some shape in this case you can see a simple example where a pattern is made up by two lines one red, one green and is used for filling a rectangle note that the fill attribute is a reference to the pattern by specifying the pattern ID the other attribute of the pattern such as we made are obviously the size of the tile that is going to be used for filling and the x and epsilon attribute are instead the offset of the tile with respect to the top left of the bounding box of the shape that is going to be filled this pattern element is exactly what we needed for rendering for exporting correctly in the tile of the background and now there is some details how that works we modified further the create object from background method that now not only call the bitmap meta action as in the previous case but also looks if we are the background type is a tile of the background in that case it modify the GDI metafile created from the objects that made up the background by replacing any bitmap meta action related to tiles by a single comment action this comment action has a special starting tag that as you can see is lying on the score background and then a parameter this parameter is an ID exactly the ID of the rectangle you have seen here that is the idea is the following we define a pattern whose content is the bitmap and then we define a rectangle with the size of the slide which is filled using that pattern so when we substitute the meta action related to tiles by this comment action the ID passed as a parameter to inside this comment is the ID of the rectangle filled by the pattern represented by a bitmap in order to create to be able to create the the pattern and the rectangle element we need to call it some data this data is represented by the structure you can see at the bottom of this slide and the bitmap checksum that is the bitmap that is used therefore as a content of the pattern the position that is the offset of the tile the size of the tile and then the size of the slide that is used for defining the size of the rectangle all this information is collected in a map whose key is the ID of the slide which has a tile in the background at the second stage we are sporting all the pattern erect element as you can see in the example below by iterating over this map and we use the information that we have collected for set up correctly the pattern attribute and the rectangle attribute that is in the end we mandate the content of the pattern is a used element which is referring to the bitmap represented the tile which as exactly the checksum we have collected at the previous stage and exactly the checksum of the first bitmap of the bitmap represented the first tile once we have sported the this pattern rectangle element finally we are able to use it for defining the background of the slide in the right actions method when a comment met action is it we check if it starts by the slide the background tag and in that case we create a used element referring to the element having the ID passed as parameter inside the comment as I told this ID is the ID of the rectangle filled with the pattern and since we have replaced the the meta action related to tiles with this meta action comment the used element is a sport exactly where all that meta action bitmap representing tiles will be exported that is exactly where will be exported the background of the slide and you can see now that where we have several used element exported each used element was referring to an image element that is to a bitmap we have a single used element referring to the rectangle and that is the way we have solved the performance issues with a toilet background so these are some small improvement for SVG theater that can be appreciated to create a presentation that's all for me I thank you for listening and if there is any question well thank you Marco for the speech any questions please put them in the bridge chat okay I think there is no question thanks again for listening of course and is that to say you're leaving the room we can close the session or we can continue the next five minutes because that's how much we have how much time we have alright excellent I'll meet back in five or six minutes to introduce the next speaker alright we're back next up is Tomas Vine girl Tomas are you around I am excellent can you record that yes and I've got it queued up here great hi I'm Tomas Vine girl I'm from Kulabara and I will present you improved documents searching the LibreOffice so first I would like to clarify what is meant by searching improved searching we can search for documents in different ways first is like searching internally and searching externally so searching internally like inside LibreOffice when we are just traversing the internal document model and search for some some string but there is also another possibility here is searching externally this is with searching externally what I mean is generally that we input the documents into a search database and using the search database then we can search multiple documents for phrases and this is generally what is this improved search for with LibreOffice meant in the title so generally when we search externally like with the database we have to transform the documents into text and feed it into a search engine which then searches inside this transfer text search result the problem here is that we don't have a really good we don't get a really good context of this searches when there is one result found so we get okay we have in this document we found this search result but we don't really know where exactly this search result what is the context around the search result so this is what we want to improve here so we can search for phrases in multiple documents as I said and for this there exists already multiple search platforms search databases the most the one we used and most like it's very popular is Apache Solar which also uses documents Apache Tika to transform the document into text like Apache Tika is a library like Java library that can open the document and transform it into HTML or just plain text another one which is also very popular is Elastic Search but I don't know much about it mainly I export Apache Solar what is the general idea the idea here is to use LibreOffice and collaborate online to add this context of the search results and we had the idea to for a search result we would render an image where this search result was found inside the document so this is now the solution description what needs to be done to get this idea realized we need to somehow create the search data and put it into a search and indexing platform like into the search database and we have to import it inside the search data platform itself and then we have to search on the search platform and get some result and after that we have to render the image of the location of the search result so generally first three steps are already implemented elsewhere but the last one I don't know if there is some solution to also render the location inside the document and show the search result to the user so now the first step with LibreOffice we can create the search result data and we how we implemented this is to implement it as a new export format so this means that you can export export as or save as and it will save the current document into a search indexing data format XML the good about this approach is that we can implement this as export format is that it provides a lot of things out of the box so without just implementing it as export format we can just already use it on the command light with this SOffice convert to switch as it says here additionally it also we can use just LibreOfficeKit API save as function to just create this search data document this Eliquid LibreOfficeKit API is already used by collaboration online which provides rest service convert to so we can already reuse that don't need to implement it ok so next I would like to search to talk about the data format the data format of the search data indexing data is just a flat XML file the idea here is why is this flat like it doesn't have a lot of nested elements is just to be very very simple so we can easily transform it to a vendor specific format like the one used in solar for example on the top now we can see one example of this search data format it has like root element indexing always and then it has child elements either paragraph or object where paragraph is just one paragraph inside word inside writer and object also not just writer any shape that has some text is also exported as a paragraph another element is also object which can be shape or image or phone work this one is mainly so that provide additional metadata for the object so we can also search inside the metadata not just paragraphs and the paragraph has attributes main most important attributes are index and notetype and addition to this also object name with this we can then identify for which paragraph we are searching for inside the object document model inside liberal office for objects the important attributes are object type and name name is always uniquely identified so we can always identify inside the document each object just with the name then we also export other attributes these are like additional metadata as already said old text and description of the object so how this is implemented is that we have an indexing export and indexing not handler classes indexing export class just root class for search data indexing export which then delegates everything to the indexing not handler and indexing not handler is just a subclass of model traverser what a traverser is is just this class visitor that visits all the elements inside the document model and then delegates this to what to do with these elements to the handler and index not handler then just writes this inside into a XML file with structure that I already explained before model traverser is derived from accessibility check accessibility check functionality which also needs to traverse the document model but currently because it's not like it's just a copy accessibility check is not yet using the model traverser but the idea is that both will reuse this class and maybe some other other uses can be found for this for example there is one uses to search our colors documents colors that the document uses could also use this model traverser but this is something that we can we will implement later so the next step is then to render image for a search result so we now from the we now preform the search and we get a search result the search result now has to have all these metadata additional metadata index node type that is important for the identify which paragraph or which object goes inside the document model and with this information then we can we can render the result so this process is divided into two parts first part is that we need to get the rectangle the location where the document the search result data in the document is located so for this we have a search result locator class that is used for this and the search result locator can then use the XML or JSON search result data as the format it also uses a special structure which is used inside tests when we then get this rectangle from the search result locator we can then just render the the render the image with paint tile API that is already implemented inside LibreOfficeKit so next is then to implement render image service inside colabora online so we can use this as service on the web and for this created an array service render search result which is very similar service that already exists converts to which already mentioned previously that is used to create search data for indexing so what is needed for this search rest service is that we need to provide document and we need to provide the search result then we send this, execute the service, send this both to the colabora online server and we get back the rendered image of the search result location which I now explained what was done on LibreOffice and colabora online but how everything is now fitting together this is including the database including the colabora online server including all the pieces so that the user can search and for this I created a proof of concept web application which this looks like this I will demo it later so maybe first I will explain what this proof of concept application does so it's just a simple web application that demonstrates how everything should work together this is then using Apache Solar as the search platform the HTTP server is just Python simple HTTP server which is then using Python for server side processing also for sending for sending rest executing rest services on colabora online and solar and it uses html and javascript for the client side and the framework that uses is AngularJS this is just something of us previously familiar with and it's very strong with data binding and rest services and bootstrap for the UI so it's easier to build how the application looks so the last thing is of course what we need is colabora online server so that we can render the image for the search result and also to document itself so that application has like three major processes that it performs so first one is the reindexing process this is just needs to fill the solar database with search data from the documents maybe what I forgot to mention is that web application has is taking care of one folder in arbitrary folder where all the documents are stored and all these documents are then taken in account and printed as are available for opening and reindexing and searching so the trick is here that we need to reindex every time that document changes so how it is implemented currently we always delete all indexes and reindex everything but ideally this should happen only when a document changes then we need to reindex and we need to only update the indexes not just remove all indexes and add all indexes we just need to remove all indexes for a document and add new indexes new indexes for the change document of course if the document is deleted we need to remove the indexes from the database so for each document how we do reindex is for each document in this document folder we request the to with the XML search data from the colabora online server using this convert to service once we get this XML file back we can then transform it to the solar format so it has a little bit different format for entering all the search data into the database so it has a notion of mainly documents and fields document is not like LibreOffice document but document generally corresponds to a paragraph or object and fields are then additional metadata we also add special field special field file name to identify which document which document it handles and special field content which is then the paragraph text and then we can submit this search data to solar using HTTP post service so search process solar has a very extended querying API and we just don't need everything here but we can use of course all these querying API if needed so how we search with solar is we just send a simple GET HTTP request to the solar server and as a response we get a JSON document with the results or with no results depending if the database found something or not there are other formats are supported like XML but if we are dealing with a web application JSON is the simplest way to do it we don't need to parse it like for example XML yes web app only searches the paragraph text currently so only content field is important and this is the only field that we search in but we could also search in other fields so for example to limit only for certain type of objects certain type of paragraphs or something like this or just additional just for example if you want to search just one document we can search only in the file name field when we get the results back from we need to transform the search result again for something that the LibreOffice can render the image currently LibreOffice supports either JSON as I said or XML and the search result needs to be compatible with that also we can reuse this JSON inside the web application itself to show the search results generally it's just an array of objects which has key and value pairs for the metadata then we have of course then we have to show the results on the web application now last is rendering the image now after we show these results on the web application we can then request rendering of the image for each search results this is done asynchronously so we can show the results first and then a rendered image for and update the search results when the images get rendered so we use a rendered search result service we send search results and we send search results in the document to the colabora office colabora online server and then we get back the image in just pure binary PNG image and with that we can transform the image to base 64 string this is generally easier to deal with this on the web application so the demo this is the web app here we have a list of documents and as first thing we need to reindex all the documents so this here shows the status of what is going on and the colon says reindexing and now it's finished reindexing, now we can search we can simply search for let's say LibreOffice search and now found in about LibreOffice document we found a couple of search results and this is now rendering where the search results are found in which paragraphs these are now images inside the document and now we can search for something more general for example we can say web and now there are multiple results of a web that are in multiple documents here we see that this result is font work and it found a result this web inside font work text if you go down you can see like this is image and it found the result inside the caption of an image the similar like image is also a shape in font result in the caption of a shape the following two ones are shapes and rectangles and in font the result inside the shape text and so on we have next a couple of paragraphs in other in other document so if we are interested how this document looks like we can just click here and open the document inside Colab around line and this is the document we see that we have here we have here the image we have here shape there is also table which is also shown as a result and another shape and this is the font work that that we show previously can then I'll go back maybe search for lorem and we have like this lorem documented lorem is found in a lot of places a lot of generally just paragraphs and and here we search finished and found nine results and generally if we go now inside here and change the document we always have to reindex the document or the search result won't be found all the changes in the documents won't be found in the search result so this is all for me demo and thanks for watching and bye-bye all right so thank you for the talk now we are out of time and we don't have enough for live questions but by all means go ahead and answer the questions in the chat in LiboCon room one now for the final bit we have well I guess first and my talk is pre-recorded I suppose it should start now hello everyone I am Mike Ogansky software engineer working for Collabora hello everyone I am Mike Ogansky software engineer working for Collabora productivity mostly working on its core part this talk is about the feature is new in LibreOffice 7.2 multi-column support in textboxes shapes and other graphical objects this is the first time when I pre-record a talk for a conference so please excuse if I do something incorrect or funny first of all I want to tell that I am glad to be part of the great team of professionals which Collabora productivity is it is a unique position making commercial customers happy and at the same time bringing the improvements resulting from that to benefit everyone in the open-source project the feature that we have implemented is the perfect example of this mutual benefit that commercial customers and other users get because of Collabora commitment to invest its expertise and do all the development is in open-source and I am proud that I am part of it let's proceed to the multi-column support in LibreOffice and first of all let's discuss what was supported prior to LibreOffice 7.2 if you with Writer you possibly know that multiple column is itself not a new feature in LibreOffice it was available long before in Writer it already had it in the very first release of openoffice.org and I suppose it was available before that Writer's columns columns are really very powerful useful configurable far beyond what is available in our competitors in Writer's pages in Writer's sections in Writer's frames you may use columns and set them very finely not in graphical objects like text boxes, shapes all that uses edit engine the component that does not rely on Writer's layout machinery here you see text document with a section that uses two columns also you see dialogue to configure the columns and you may see how rich the configuration is where you can set up distribution of the text or the form of the separator line something that is absent in our competitors it was already present in Writer before the 7.2 release but other models calc impress draw didn't have this multi-column support because they didn't use Writer's layout machinery as was already stated they all rely on edit engine to do that and since we discuss here the development that brought this capability into these models the question is did they actually need this support or maybe it was okay without it let's see I want to focus on impress as the model that benefits most when any new feature appears that provides new layout capabilities when authors create slides they might want to put their text into columns and they would expect naturally that the text would flow freely from one column into the other to the next at the same time they want the good stuff that they already have with the boxes in the impress for instance allowing them to automatically scale the text to feed the size of the box but that wasn't able directly user would need to create for instance two text boxes or a table with two columns and then you would need to type text move it from one element to the other from one cell to the other to distribute them you would need to make sure the same properties to the two elements so that the text looks consistent when you edit the text you naturally need to do this all again because for instance scaling might need adjustments all that would need to be done manually the other aspect requiring the new feature was interoperability with other suits that already provide multi-column support in presentations when LibreOffice users get documents created in those suits they naturally want to see them as they were intended to be but that wasn't possible before 7.2 indeed we tried to work around the missing feature and tried for instance to import multi-column texts into tables trying to figure how to distribute the text over the different cells but that couldn't be done perfectly and often the text ended up being distributed in a different way not as it was intended to be here is the screenshot of Microsoft PowerPoint with a slide with two column layout and a configuration dialogue so naturally we needed to provide ways to import and export the data to allow our users to interoperate with the users using other office suits so now we see that the need is real let's proceed to the change itself when you start working on a new big feature you need quite some effort the feature takes much time it requires developers to work for weeks and even months and indeed that means that you may be sure that the feature will be completed at some stage when someone supports the development and makes it possible for developers to focus on their task when a commercial company gets a support contract and they listen to their employees they create support tickets to resolve problems that their employees have the company does just that it makes the difficult development possible which otherwise could be totally impossible for volunteer it could be just too huge for a volunteer who needs to eat in the first place and we glad to have Suse our valued customer who keep helping the whole community to improve liberal office over the years they are the ones who made this development possible when implementing the new feature you need to check if it would bring changes possibly incompatible changes to the file format that is used in the office suit and we studied ODF if it has a required support or if we need to extend it to the new feature it turned out that ODF already has all the required support for it it already defined that graphical objects may have columns element in it so that was a nice surprise for me and I want to thank all the wise people working in the ODF technical committee in OASIS thank you then we proceeded to analyze the scope of the task if we needed to implement all the rich feature set implemented in writer in the columns in graphical objects and after discussing the possibilities we decided to not implement everything that writer has and focus and limit the task to the simple same with columns without separators there were two reasons for this decision first keeping things simple allowed us to provide the new feature faster and second possibly the most important was that having two complex feature set implemented from the start would create another compatibility problem this time in the opposite direction the users would be unable to save these features into external file formats which would make them which would make it difficult for them to share their documents with the users of other office suits so we decided to limit our task and additionally it was unclear if this set of features was actually demanded so that would justify the development the next nice part of the task was to implement the document model for the feature and to make sure that it gets stored to and imported from the file formats the two file formats is our native ODF and the second the OXML that Microsoft Office uses I really enjoyed how well engineered our existing code was when I worked on this feature the code that already handled this task for writer was so well engineered that it was very easy to reuse it it needed very few changes very few modifications to make it work for broader set of objects we made some refactoring to move it to make it reachable edit engine and it worked I always enjoy working with a code that is so well engineered because it makes the task easier it allows to do more good stuff in less time and I'm very very glad to be able to work together with brilliant engineers like Miklos who is always ready to share their expertise and point to ways to avoid inventing a wheel it's him who pointed me to this well written code thank you one thing that required a completely new development from our site was this layout itself we needed to make quite a few changes and most demanding part was the new iterative algorithm to distribute lines of text over several columns when you implement an iterative layout algorithm one of the biggest problem is to make sure that this algorithm ends at some point that it never hangs and since we changed an algorithm that was previously linear into iterative we needed to make sure that it can't freeze so I'm glad that we were able to do that I'm sure that our algorithm never hangs it works reliably and that's what I'm proud with in the end there were a number of commits implementing the feature in steps there were an initial set of merged patches then there were some more patches that fixed some omissions bugs and now the change is ready for everyone to enjoy the end result in LibreOffice 7.2 you may see that the boxes in Impress as visible on this slide as well as in all other models got the power to distribute your text over the columns just as you would expect the configuration of this feature is very simple it is hosted in the text properties dialog where other text properties were already hosted also it is available on the sidebar and you may see the comparison of the dialogs used in Microsoft Office and in LibreOffice 7.2 you may see the parity of features in the two office suits so what's left to do there are a number of issues filed against this new feature in Baxila it is natural it is a new feature it is a big feature and some problems are still in the first steps and especially so when the feature was just published to the wide testing but one of the most important issues there is in my opinion bug140022 which is about still unresolved compatibility problem between Microsoft Office and our new implementation in LibreOffice to resolve we need some missing bits in initialization of edit engine and recently Noelle Grandin has made some nice changes toward this thank you very much for that yet more work is needed on this problem as well as on other still unresolved problems with the new feature yet I am glad the feature is functional and is ready for you to test please do that this is basically the end of my report about working on this new feature that is landed in LibreOffice 7.2 the feature that brought to you thanks to Collabora that magically makes commercial support to benefit the community the task was really a great pleasure thank you for your attention that allowed me to feel all that pleasure again as if I working on it the second time now it's time for questions and I am sure that I am ready there in the room waiting for them to answer thank you very much thanks I am always glad when there is no questions it means that I made a perfect job describing everything and thanks to all the community and to TDF it is a pleasure of course it would be great to meet in person but this conference makes feel closer to each one


The career path for the Interior Communications Electrician or IC Rating Career has changed. The new Navadman includes the rank of Master Chief, which was previously designated as electrician's mate, and IC Sailors E3 and below are re-designated from firemen to seaman. To have an IC Master Chief, I think that it would be better for us, actually, because the advancement percentage has been really, really low for our ICC, and perhaps it would open the rate up a little bit. These changes shift IC's mission focus from engineering to combat systems and will take effect May 2014. The first IC Master Chiefs will be chosen from Selection Board Eligible IC Senior Chiefs in Fiscal Year 2015. From the Defense Media Activity, I'm Petty Officer Ian Cotter.