TeamLab Document Editor on canvas: erasing the lines between desktop and online
In the previous post, we told you that one of the main goals of participating in CeBIT 2012 was announcing a new online document editor TeamLab . Today is more detailed about the editor (at the moment it is in the beta version), how they came to the idea of ​​its creation and how, in the end, they implemented it.
No matter what project you are talking about, you always have to work with documents and, of course, we all want the editing of files to proceed with maximum comfort.
As suppliers of online tools for teamwork (from project management to CRM ), at some point we were faced with the need for our own service for working with documents and began developing a module that soon became a fairly large-scale tool for working with documents, presentations and tables, integrated into the Teamlab system.
')
How to start
It is no secret that in the document management segment, primacy among online editors belongs to Google, Microsoft and ZOHO. Developing the first version of our document management module, we went the beaten path and used well-known methods: the files were converted to the html format on the server for further work in the browser, and the open source resources of the CKEditor editor were used for editing. To save the result of the work, we connected the reverse conversion - from html to the desired format.
As a result, our editor faced the same problems that are typical of existing online editors: from a meager set of tools to serious errors when saving, converting and displaying.
About problems - big and small
Like the developers of other online editors, we first decided to improve the work with the pages, namely, to make a pagination, because the first thing the user needs, even with elementary editing, is to estimate the size of the document, for example, to send it to print.
What is the problem of pagination? Existing online editors work with one html page, regardless of how much information is placed there - 1 page or 700. Accordingly, the larger this document will be, the larger this page will be. In other words, it appears to be a long roll that needs to be fully developed, that is, “draw” and “redraw” if changes are made. That is why among ourselves we call this problem “the papyrus effect” as a joke.
Only two of the existing editors, Zoho and Google Docs, actively develop their editors and also started with this - with the breakdown of pages. If the former have it, let's say, approximate, it is implemented more for visualization and is located where, according to approximate calculations, the page should end, then Google Docs has quite a real one, but this only aggravates the “papyrus effect”, because the document has not only to be redrawn when making changes, but also to recalculate the breakdown.
After analyzing all this, we decided to completely abandon the old methods.
Development from scratch
We solved the problem of pagination as it is done in desktop editors: we changed the architecture of the code in the part of drawing the document - the work goes only on the visible part of the file, the rest of the document is drawn only if it is accessed.
Going to solve the problem of pagination in this way, we also eliminated the problems:
- work speed (for example, when changing the typeface) with multi-page documents,
- zooming
- display non-printable characters,
- changes in document fields.
The graph shows the time it takes to open and zoom documents more than 100 pages from popular online editors.
Identical mapping task
At the same time, we were puzzled by the issue of high-quality text display in different browsers and during printing. Despite the fact that this is one problem for the user, it has two sides to the software - the measurement of fonts (obtaining font metrics) and the drawing of text in a document.
The fact is that current online editors use browser tools to measure font and draw text. However, the measurements made by the browser are not accurate and do not contain important attributes, for example, such as superscripts and descenders, and other metrics. Moreover, different browsers may have their own measuring tools, which leads to incorrect display of the same document in different browsers.
The same applies to text rendering methods. Existing editors use browser tools to draw text on the canvas provided by the OS.
That is why when developing our editor, we had to create both our own engine for obtaining font metrics and our own methods for drawing on the screen. As a result, we ourselves control the font dimension and send commands to our “renderer”.
The appearance of the new HTML5 technology, which includes the canvas element, which gives us access to the “canvas,” namely, pixels, helped us to solve the text rendering problem. Each element of the text is drawn up to a pixel and, accordingly, in no way depends either on the browser or on the OS.
In addition to the identity of the display in various browsers, we were able to achieve excellent results when printing a document, i.e. when saving a file in pdf. Storing all parameters as a meta file with a set of commands eliminates the need for any conversion, which always means inevitable losses.
Benefits
As a result, unlike all existing online editors, TeamLab Document Editor has the following technological advantages :
Well, and of course, a number of important advantages for users :
To try the beta version of the editor right now, visit the TeamLab Document Editor demo portal at http://html5.teamlab.com
No matter what project you are talking about, you always have to work with documents and, of course, we all want the editing of files to proceed with maximum comfort.
As suppliers of online tools for teamwork (from project management to CRM ), at some point we were faced with the need for our own service for working with documents and began developing a module that soon became a fairly large-scale tool for working with documents, presentations and tables, integrated into the Teamlab system.
')
How to start
It is no secret that in the document management segment, primacy among online editors belongs to Google, Microsoft and ZOHO. Developing the first version of our document management module, we went the beaten path and used well-known methods: the files were converted to the html format on the server for further work in the browser, and the open source resources of the CKEditor editor were used for editing. To save the result of the work, we connected the reverse conversion - from html to the desired format.
As a result, our editor faced the same problems that are typical of existing online editors: from a meager set of tools to serious errors when saving, converting and displaying.
About problems - big and small
Like the developers of other online editors, we first decided to improve the work with the pages, namely, to make a pagination, because the first thing the user needs, even with elementary editing, is to estimate the size of the document, for example, to send it to print.
What is the problem of pagination? Existing online editors work with one html page, regardless of how much information is placed there - 1 page or 700. Accordingly, the larger this document will be, the larger this page will be. In other words, it appears to be a long roll that needs to be fully developed, that is, “draw” and “redraw” if changes are made. That is why among ourselves we call this problem “the papyrus effect” as a joke.
Only two of the existing editors, Zoho and Google Docs, actively develop their editors and also started with this - with the breakdown of pages. If the former have it, let's say, approximate, it is implemented more for visualization and is located where, according to approximate calculations, the page should end, then Google Docs has quite a real one, but this only aggravates the “papyrus effect”, because the document has not only to be redrawn when making changes, but also to recalculate the breakdown.
After analyzing all this, we decided to completely abandon the old methods.
Development from scratch
We solved the problem of pagination as it is done in desktop editors: we changed the architecture of the code in the part of drawing the document - the work goes only on the visible part of the file, the rest of the document is drawn only if it is accessed.
Going to solve the problem of pagination in this way, we also eliminated the problems:
- work speed (for example, when changing the typeface) with multi-page documents,
- zooming
- display non-printable characters,
- changes in document fields.
The graph shows the time it takes to open and zoom documents more than 100 pages from popular online editors.
Identical mapping task
At the same time, we were puzzled by the issue of high-quality text display in different browsers and during printing. Despite the fact that this is one problem for the user, it has two sides to the software - the measurement of fonts (obtaining font metrics) and the drawing of text in a document.
The fact is that current online editors use browser tools to measure font and draw text. However, the measurements made by the browser are not accurate and do not contain important attributes, for example, such as superscripts and descenders, and other metrics. Moreover, different browsers may have their own measuring tools, which leads to incorrect display of the same document in different browsers.
The same applies to text rendering methods. Existing editors use browser tools to draw text on the canvas provided by the OS.
That is why when developing our editor, we had to create both our own engine for obtaining font metrics and our own methods for drawing on the screen. As a result, we ourselves control the font dimension and send commands to our “renderer”.
The appearance of the new HTML5 technology, which includes the canvas element, which gives us access to the “canvas,” namely, pixels, helped us to solve the text rendering problem. Each element of the text is drawn up to a pixel and, accordingly, in no way depends either on the browser or on the OS.
In addition to the identity of the display in various browsers, we were able to achieve excellent results when printing a document, i.e. when saving a file in pdf. Storing all parameters as a meta file with a set of commands eliminates the need for any conversion, which always means inevitable losses.
Benefits
As a result, unlike all existing online editors, TeamLab Document Editor has the following technological advantages :
- HTML5 is gaining more and more popularity, which guarantees a number of new improvements in the future;
- All technologies applied by us, except for rendering on canvas, could be applied in our previous editor, but using HTML5 they work much more efficiently;
- the use of canvas allows you to make your own drawing;
- thanks to the technologies used, the addition of new functionality will be absolutely trouble-free
Well, and of course, a number of important advantages for users :
- Identity of the text in the input and output: the processed file retains the same style, paragraphs, line and character spacing, etc. when viewed in any browser in any OS, as well as when importing and printing;
- wide range of options for working with tables, line spacing, multi-level numbering, text styles and headings
- the possibility of smooth processing of multi-page reports, business or financial documentation in strict accordance with all standards;
- no language barriers due to the maximum number of fonts, including hieroglyphs;
- support for all modern browsers, no need to use additional software.
To try the beta version of the editor right now, visit the TeamLab Document Editor demo portal at http://html5.teamlab.com
Source: https://habr.com/ru/post/141434/
All Articles