Basics of Web Word Processor (1)

Necessities and Types of Web Word

First, let’s discover why web word is necessary, and the criteria to be classified into a web word, as well as its types.

Necessities of Web Word

One big advantage of a web word is to express content as you want, whatever the OS is, only if a browser is available. However, regarding document editing, restrictions exist that a particular OS or software, or document format is required in most cases. In particular, the window-based MS Office and Hancom Office are most commonly used in Korea; DOC and HWP are the frequently used document formats. From user’s perspective, such environment comes as nuisance as supportive OS may not be available, and editing is simply impossible if there’s not a computer with such software installed. Sometimes, it may cost you unnecessary prices to buy relevant software.

Classification Criteria

By the standard of native word processors, I believe a web word must have page representation and editing functions. This may just be a personal opinion, but I set such criteria because many native word processor users find the most foreign aspect of using a web word in the unavailability of page representations. Most documents (including exam papers) we have experienced while educated, or those frequently used in public institutions or companies tend to have page representations, since even their digital versions are originated from books. They have been written upon word processors which are equipped with page representations and editing functions.

Web Words Supporting Page Representation and Editing

While developing a web word, I have benchmarked those web words supporting page representation and editing, including Google Docs, Hancom Netffice which took over ThinkFree. They provide much more functions than expected but still not so easy to use.

  • Google Docs — The Google search says an engine called kix is used, but it’s not an open source yet.
  • Zoho Writer — Foreign-made software doesn’t feel familiar as it does not support Korean, or the entry part or the cursor is located beyond the boundary of a character.
  • ONLYOFFICE
  • Naver Office
  • Hancom Netffice — Only Chrome is supported at the moment.
  • POLARIS Web Editor — Applied mostly in public institutions and hard to find in private sectors.

Considerations for Implementation

  • Complexity of implementation of page representation, as well as the editing function in support of it
  • Control of cursors and complicated DOM manipulation
  • Difficulties in the support of multiple languages and a variety of fonts
  • Representing documents in similar forms to native word processors
  • Line spacing
  • Paragraph spacing
  • Difference in vertical alignment of lines and paragraphs (top, middle, and bottom) of the web word
  • Differences in font rendering
  • Difference of font representation between CSS (browser rendering engine) and particular documents

Implementations

Like I mentioned earlier, I believe the core criteria and the start of a web word is to have page representation and editing functions. To implement page representation after all the other implementations, like entering, deleting, inserting, and pasting content, as well as images and tables, many parts need to be newly implemented to fit for page representation.

contentEditable

Some Editor represents character entry and documents in Canvas, while SVG is used in ODT Editor of WebODF. TOAST UI Editor separates implementation of cursor entry from cursor rendering, although they are based on HTML. contentEditable is controversial but undoubtedly supports editing faster than any other.

Advantages of contentEditable

To name advantages of contentEditable:

  • Fast implementation is available for functions up to a certain level.
  • Browser’s entry system is applicable: particularly good for the support of Asian languages which require combination of letters for entries.
  • Browser functions such as cursor control, direction keys, Home/End, Pageup/PageDown, Del, and cursor rendering are available.
  • Copy and paste is also available.

Disadvantages of contentEditable

Disadvantages are so called due to its dependency on browser implementation:

  • Font representation and CSS box representation might be slightly different for each browser (e.g. for IE11, font 9 may oddly look larger than font 10; some font of a browser has narrower representation between characters.
  • Relevant bugs, when they occur, cannot be handled until the browser provides the patch (for IE11 or lower browsers, support has been suspended. Even with patches provided on bug reports, they are applied only to edges.)
  • For the div block tag, with the assignment of contentEditable attribute, comes the edge of Resize Handler, causing unnatural looks. The solution is to hide Resize Handler but it is not easy as it sounds, and no fixed solution is available (the tested browsers are IE11 and Firefox, and IE11 in particular often show up Resize Handler again, even after it is deleted after adding and deleting contentEditable attribute.)

Page Representations in HTML

Here, HTML is described as a representational tool of page. HTML, in general, refers to a document with vertical representation: document here doesn’t refer to a paper like A4-size print. Functions like page-break-before and page-break-after are very useful to implement printing and page division, but difficult to represent a page.

  • When a paragraph is between two pages, the paragraph can be divided into lines so as to be represented throughout the previous and next pages.
  • Entering/deleting characters can lead to page representation in real time.

Dividing a Paragraph between Two Pages

Page layout can be enabled in the following steps:

  1. Insert the total HTML content inside the nth Page Container tag (n starts with 1).
  2. Search through the block type-tag inside the nth page in the order, starting from the top and find the first tag which is the (bottom of bottom<block of page). Close, if there’s none.
  3. Divide the block into lines, as the found block tag must be represented throughout pages.
  4. Search through the divided lines in the order from the top and find the first line which is the (bottom of bottom<line of page).
  5. Divide the block into block-1 and block-2, with the found line at the center.
  6. Create n+1 page container tag.
  7. Relocate all the rest tags since block-2 to the n+1 page container tag.
  8. Repeat 2.

Dividing a Paragraph into Lines

  1. Cover each character of a paragraph (block tag) with span tags (since text nodes only cannot identify the coordinates of a character, covering with tags is required).
  2. Look through characters covered with tags and find the character which is the bottom of the nth character < top of the n+1th character).
  3. Process the n+1th character in the renewed line.
  4. Repeat 2. and divide the paragraph into all lines.
  5. Find the largest bottom of each line.
  6. Use the bottom of each line in 4. of [Dividing a Paragraph between Two Pages].
  7. Delete all inserted span tags and return to the original paragraph (block tag).
The example is a demo screen for page layout of POLARIS Web Editor: the article is edited into 7-page layout.

Events Requiring Page Layouts Again

Some editing performances require page layouts as described above, such as:

  • Entry and deletion (including paste) of content including characters (image, text box, or table)
  • Style change of content including characters (change of character size, font, paragraph/line spaces, indents, outdents, and etc.)
  • Editing of page format (change of width/length or size of page)
  • Insertion/deletion of page division marks

Performances

Not many web word products provide page representation and editing functions, and one of the reasons regards to performance. Page representation based on the principles in the above requires a huge number of layouts and DOM operations that a browser needs to calculate. In particular, it requires lots of DOM operations to cover each character with span tags while dividing a paragraph into lines. Plus, the layout result of a browser must be imported to use as coordinate of a character, which costs quite much. Considering that such process needs to be repeated for every typing, you can imagine how enormous the job is.

  1. Calculate again where the change occurred and tags after paragraph (block tag) only.
  2. Calculate up to the previous page of where the page division is inserted.

In the Next Article

In the next article, I will introduce how to implement simple page representation and editing by using actual codes: implementing page editing by using contentEditable, as well as the page layout process after change events of a document (e.g. insertion/deletion of characters) will all be shared.

Course of Direction

The emergence of new APIs like, WebGL, WebAssembly, or File/ DB of HTML5 indicates that a web is now considered as a platform where traditional works, functions and services can be processed. And the development is still ongoing. The transition from native word processors to web words is part of the process. Some environment, like Chromebook, even provides web words only through Google Docs, without having a native web word processor.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store