 The influence we are going to see for the SVG Asport Theater was all about the exporting the background of a slide. The first topic is about being able to export a slide that owns a custom background. In fact, one of the features of Rabbi 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 JavaScript presentation showed always the master page background instead of the one used as custom background. I suppose you are familiar with the basic code SVG markup language. Anyway, I want to remind you the use element. This use element allows to reuse more than once an artwork, in this case a simple rectangle, allowing to change its geometry and style feature. We can define an object just once and use it many times. 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 for each slide or even generated dynamically such as a slide number, day, 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-objects referenced, there is a specific class named the master page view. What we are interested in this case is the first use element that references the master page background. In order to get a custom background spotted correctly, we need to identify this class in order to make it aware that a slide owns a custom background so that instead of referencing when it creates that use element, the master page 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 usability of the several text fields that made up the master page and even other kind of information. The metadata is supported as custom attributes, all with a prefixed tripolonami space. In the example below you can see for instance the master custom attribute and 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 a slide is using a custom background, we have introduced a new attribute named as custom background. The generating metadata method that exports 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 all these attributes and transforming them in properties of the distance of the metadata slide class itself is able to provide information to the master page view class so that it can know if a 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 to provide the ability to use a bitmap as a background. Now a spotting bitmap as a background was displayed as a workaround because the same bitmap was exported 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 the ground method of the SVG filter class. This method in order to export the background of a slide or a master page used to create a GDI meta file for the object that made up the background of the slide. This meta file then is passed to an instance of the SVG writer for converting its meta action in one or more SVG elements 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 meta file 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 meta entry part each bitmap. Once we have collected all this meta action related to bitmaps we can export the image element that represents the bitmaps. We have implemented a specific method named the import background bitmaps. This method iterates over all the bitmaps action present inside the map where the populated area and for each entry in the map it creates an image element. The image element then is referenced by one or more used elements at the place where the custom background for the slide is defined or more than once even 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 at the background. As you can see the used elements exported are more than once and they are referenced to the same bitmap. This occurs inside the write BMP method of the SVG Action Writer class which usually is the default handle 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 we export instead of the image element a used element with a transmit attribute in order to set up the bitmap to the appropriate position size and the HRF attribute set to an ID that contains the just computed checksum of the bitmap. That is the way we get bitmap used 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 it still presents some problems for the tile background case. The problem is that when the used elements exported are a large number, it's expensive for the browser rendering them. So, if a tile background has 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 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 field 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 a tiled background. And now there is some details how that occurs. We modified further the create object from background method that now not only called the bitmap meta action as in the previous case but also looks if we are the background type is a tiled background. In that case, it modifies 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. 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 export we substitute the meta action related to tiles by this comment action the ID passed as a parameter 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 a spot in 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 as a counter 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 to define 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 the weave and date the content of the pattern is a used element which is referring to the bitmap represented the tile which has exactly the checksum we have collected at the previous stage and exactly the checksum of the first bitmap of the bitmap actually represented the first tile once we have sported this pattern rectangle element finally we are able to use it for defining the background of the slide in the write actions method when a comment method action is it we check if it starts by the slide background tag and in that case we create a used element referring to the element having the ID passed as a parameter inside the comment as I told this ID is the ID of the rectangle filled with the pattern and since we have replaced all the meta action related to tiles with this meta action comment the used element is exported 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 elements exported each used element was referring to an image element that is a two bitmap we have a single used element referring to the rectangle and that is the way we have solved the performance issues with a tile background so these are some small improvement for SFG filter that anyway can be appreciated to create a presentation that's all from me, I thank you for listening