Creating an HTML5 Based Document Editor

No matter what kind of project you are involved with, at some point you will most likely end up working with electronic documents.
We were no different.
Being a business service provider, we soon realized how useful an internal document collaboration system could be.
Basically, that was a jump-start for the development process that grew into something bigger than just creating a tool for our personal needs. We ventured to make the first HTML5 based document editor.

For starters

The online document management segment boasts such giants as Google, Microsoft, Zoho etc., so at first we decided to keep to the beaten track and use time-tested methods for product development.
Long story short, files were converted to HTML format on our server to make working in a browser possible. The editing feature was enabled by the means of an open source CKEditor. The reverse conversion from HTML to the desired format was sprung into action allowing users to save their work.
The outcome was neither surprising nor pleasing, as the editor was facing absolutely the same problems as its rivals, from a poor toolset to serious display errors after saving, converting or printing the document.

Troubleshoot

One of the most basic needs a generic user has is the ability to evaluate the document size. Desktop editors exploit pagination for that matter, which is a tough challenge for online ones.The problem is that current online editors work with a single HTML page no matter how much information it contains.
In other words, if you take a 700-page document, the browser would still perceive it as one HTML page resembling a huge roll that has to be rerendered completely every time you make a change. We jokingly call it “papyrus effect”.
Only two currently developing editors have this feature. While Zoho’s pagination is best characterized as approximate, Google Docs platform performs more accurately, but that in turn aggravates the notorious “papyrus effect” caused by the necessity to rerender the file as well as reapply pagination over again every time you type in a new symbol, for instance.
One learns from one’s mistakes, so we decided to make proper pagination our primary objective. The first thing we had to do was to renounce old methods.

Development from scratch

Taking desktop editors as our benchmark for successful pagination issue resolution, we determined to use the same principles to get a worthy result.
We changed the code architecture in the document rendering section so now all operations are performed on the visible part of the document, while the rest of the document is rendered only when referred to. In that way, we resolved several problems at once, making it possible to:

• avoid low-speed operation with multipage documents (e.g. when changing type family)
• zoom in/out the document itself (not the browser window)
• display invisible characters
• change the size of the margins

Identical Display Challenge

Another thing we noticed while working with online editors was the problem of non-identical document display in various browsers and after printing. From a user’s point of view it is just one issue, but from the developer’s at least two: font measuring (acquisition of font metrics) and text rendering in the document.
Currently, online document editors use the browser for both rendering and measuring. However, browser measuring is never precise. Besides, it lacks important attributes like ascenders, descenders and other metrics.
Moreover, every browser can have its own measuring means which consequently leads to improper display of the same document in different browsers.
The same applies to the ways browsers render text. Current editors use browsers to render text on a “canvas” provided by the OS.
That’s why we had to come up with our own font metrics acquisition engine as well as our own rendering methods. As a result, we have font metrics under control so we are able to send requests to our renderer.
Without any doubt we have to give credit for the the new HTML5 technology (canvas element to be more exact) that grants access to the pixels of the content. Every single element is rendered accurately to a pixel and consequently is not dependent on a browser or an OS.
Apart from identical display in different browsers, we managed to get good results when printing the document (saving it to .pdf format). Storing file parameters in a meta-file with a command set allows us to avoid conversion that inevitably causes quality losses.

Prospects

Features we have become accustomed to on a desktop editor, such line spacing, an abundance of fonts and text styles, multilevel numeration, editing of tables or multipage reports are already penetrating the realm of online editing, no matter which browser you use, or where you’re trying to import your document from.
In the long run, HTML5 guarantees a variety of even more significant enchantments in this sphere.
Meanwhile, this is what we ended up with: