 So, my name is Mihai Vagman, I'm a software engineer at Qualpera and I'm going to talk today about LibRafis Online, the client developed. So LibRafis Online consists of two parts, the server side and the client, of course LibRafis. And on the client we have Leaflet and open source JavaScript library and JavaScript as the main language to code in. So this is how Leaflet usually looks like. Many of you might be familiar with OpenStreetNet and Leaflet is actually used by big companies and they've recently reached the 1.0 version of Leaflet. We're currently using some 0.7 version. So we had to make some changes in Leaflet. Mainly we've added web socket communication to send and receive commands from the server and also to get the ties from the server instead of having a new URL for the images. So we're also caching more. For example, when zooming, they used to remove the old layer of ties and no longer do that. And some newer versions of Leaflet also discarded ties once they got out of the viewing area. So these are the steps to load a document. So we needed a different coordinate system, a different from the one that is normally used for viewing the Earth, because the Earth is drowned and we needed a flat surface. Luckily, Leaflet already had this implemented mainly for maps in different games. And we used that. So the tile at the very top left is the tile with the coordinate 0.0. And the axis goes from left to right and the y axis is from top to bottom. And images are requested from the server based on the coordinates. So each tile of 256 pixels represents a single file of a specific coordinate. So the server sends binary images and those images are transformed in data arise with which normal images are constructed. So this is an example of a simple image, a red dot. And that's a code example of how to create it. And this is what the document looks like in the browser. All of those are images and that blue rectangle is actually an image. And you can see the actual HTML code. So we've tried to cache a lot as much as we could because this improved the user experience when scrolling and zooming. For example, we do prefetch tiles outside of the viewing area after a time of user inactivity because we do not want to burden the server with tiles that are not visible while the user might be editing. So after a few seconds of inactivity, we start to load tiles outside of the viewing area and increasing border. We also can prefetch tiles from other parts. For example, in Epress or Kalk, a page is just a slide and you can actually prefetch a thing around it because that's all of it there. So we prefetch other parts so the part changing is a bit smoother. So we've added a scroll API based on the already existing timing methods. We did this because every time we need scroll bars because that's the natural way to navigate a document. And custom scroll bars can be easily added to the existing implementation. We also cut the mouse time so you can actually scroll in the mouse and move the document around without moving things in the documents and without selecting anything. Selections are implemented as an SVG overlay, they are independent of the tiles so the tiles underneath do not require to be repainted. Actually, selection works really well because the message that is sent from the client to the server is quite small so you can send a lot of messages in a short time. So we're actually tracking the user movement. And we get a nice feedback. We also have selection handles for shrinking or enlarging the selections. Those are pretty handy on mobile devices and those from the browser, why not? So this is the typical scenario. We record keystrokes, we send them to the server. The server tells the client that some tiles are no longer valid. The client requests those new tiles and once they are re-rendered and they arrive on the client, they replace the old tiles. So it was a bit tricky to capture the keystrokes. So we actually have a hidden test area in which the user types and we capture the events. We had some compatibility issues because keyboard events were different across browsers. So some keys need to be treated differently. For example, the tab key would change focus in Chrome but in Mozilla would do nothing and so on. Also the workspace would cause the web page to go back. Images can be selected and moved and resized. This is how an image selection looks like. It's similar for shapes and other objects. Copying. So we need the keyboard event to actually access the user's keyboard and due to security reasons access to the user's keyboard is very restricted. So we cannot initiate ourselves a keyboard event. We must wait for the user to press conferencing or what is it. And we must modify the data inside that event so that the user gets what he had selected. And the pending plan must be handled synchronously because I assume due to security reasons as well it will somehow expire and the keyboard gets detached from the event. So we actually need to get the selection content on the client before the user presses conferencing. And we do that by quickly requesting the selection content after the user selects something. So about 150 seconds after no activity we get the selection content and it will be there when the event arrives. So there is ongoing work for a keyboard API. But I understand this is a working draft. And there are some hacks to actually have access to the user's keyboard. There is a zero copy library which is a hidden flash movie. And when the user clicks on a button or clicks on something in the context menu the data gets copied to his keyboard. But this also requires user interaction so it's still not perfect. And also flash is going to be deprecated pretty soon so it's not the way to go. And also there is a little support unfortunately for RTF formatting. So we now only can offer plain text or HTML formatting for the selection content. So we have methods of interact which the user can interact with the toolbar. Developers can very easily plug in their own toolbar and modify the existing one. So the document can actually be viewed without any toolbar. It's just a just an area in the browser where we can pan the document and edit and so on. So this is what the toolbar looks like in the ClutchIt toolbar. So we have the most common buttons like bold italics and so on. Telegraph alignment. We can select fonts, styles and font sizes. We also have buttons for zooming in and out and changing the page. This is what the font selection looks like. We also have a search bar. We can search backwards or forwards. And some features that I want to say that most of the toolbar buttons work through unicomments like bold and so on. But we also have some of our own methods like go to page or go to part enable editing. There's a button next to searching to the left which enables editing. When disabled the user can pan the document and interact with it like you would do with a map. And while in viewing mode the user can also enable selection for the short time if needed. It will select text with the mouse. We also have previews for presentation documents and those previews are updated. So when the slide is edited the previews will also get an update after one second. We do this not to load the server too much with repending the whole slide for a small preview. So regarding testing it can be made automatically. We use the mocha framework which is a JavaScript testing framework. Dflat was already using this so we've extended their viewing tests. And we can also replay an editing session to get the average loading time of the tiles, the maximum and the minimum loading times. This is a test output which can be run in the browser. And an alternative would be to use the phantom.js library which actually has a known WebKit implementation. But unfortunately they have some old WebSocket implementation that doesn't work with our server. But they promise to implement some other WebSockets and as soon as they do that we'll probably switch to that. And this will give us a more automated test so we no longer need to run into the browser. And the idea is that to let the browser, I mean to let Dflat decide which tiles to request from the server and to actually take into account the time to load the tiles. And without the browser we would have to manually request tiles and it is not exactly desired to do it this way because we want to emulate an actual editing session and an actual interaction with the document. So about performance, the average loading time is quite good. It's below 100 milliseconds which is actually very smooth. You can't see the lag. And we're still working on improving it. I know that binary images take longer to load in the browser and we might somehow overcome this problem by loading them in another way. This is yet to be tested and we hope to have an improvement in there. So I have two demos for you. This is how you can time the document. You can also scroll to the next page and back. This is the selection enabled in the viewing mode. You can also zoom in. Scroll to the next page if you select the first page and move it upwards. Sorry. If you want to take the beginning of the selection and then move upwards. And then scroll to the third page. Yes, I think so. You can move shapes around. You can resize them. Do the text. No shapes. Searching shapes also works. So this is how editing usually looks like. As you can see it works pretty well. You can see when you're typing and what you're typing with no delay. You can switch the selection handles and the cursor moves with the end selection handle. Searching. So we have my table with a lot of fonts and as you can see we have a feedback of the current font. Selection with shift and arrows also works. This is a nice spreadsheet because I'm going to have an updated preview of the slide. Text rectangles. Sorry. The text rectangles. How do you get them? Which ones? If you do a selection or a search then you do a selection locally. So you must know what the boxes are. We get that from the server. We get the position where the selection starts, where it ends. And it's actually a perp angle that we get from the server. Ok, so the cursor movement is around you to the server? Yes. Most of the things are around you to the server but very fast it works. So the search is done on the server or on the page? On the server. We don't have text on the client. We just have files. Ok, thank you very much.