I am pleased to announce the release of Joed 0.1, the first alpha version of the document editor I am developing. The focus of this release was to lay down a clean and healthy foundation on top of which I can build the vision I have.

Which features have been implemented so far?

  • Edition and view mode
  • Sections, paragraphs, page header and footer
  • Open and save a document
  • Document classes

A document class specifies how a document has to be rendered by the backend (page format, appearance, etc) and defines the available styles for the user. Indeed, if the document is an article, it needs different styles and will be rendered differently as if it was a book or a CV.

How does it look like now?

Edition mode

Here we can see a document with a page header as well as several paragraphs and sections:

image

Although it is possible to edit the existing paragraphs and sections and save the changes, it is not yet possible to add, remove, copy or move any of them.

View mode

Once the user clicks on the “View mode” tab, the document gets translated into backend code, so that the backend can compile it and the results can be displayed in the viewer. There are actually 2 backends available: ConTeXt and Markdown, as well as 2 document classes that influence the results: “article” and “article.dark”.

Here are some screenshots of the possible combinations:

ConTeXt – “article”

image

Markdown – “article”

image

Markdown – “article.dark”

image

Let’s have a brief look under the hood

The initial plan was to make a ConTeXt backend only. I then discovered that it wasn’t hard to create a backend independent document editor which exports some variables that can be used by some external configuration files with embedded Lua code to translate the document into a code that can be compiled by the backend. This enables more flexibility and easier development.

To better explain the concepts, here is how the paragraph style is defined in configuration files for the ConTeXt backend:

styles:
   paragraph:
      type := text_block
      output := '{\\par ' .. _text_block_ .. '}'

Very few lines are needed to make a paragraph style available. By adding a “paragraph” entry, we create a new style. Then the “type” property instructs the document editor to render each paragraph as a text block in the user interface, and to export its content into a “_text_block_” variable. Finally, the “output” property instructs the document editor how to translate the paragraph content into backend code. As we can guess, a paragraph can be expressed like this: {\par <paragraph content> } in ConTeXt. In the future there will be more properties available such as formatting and spacing properties.

I decided to develop a Markdown backend as well as the planned ConTeXt backend. This backend uses pandoc to convert the generated Markdown code into HTML before it can be displayed in the viewer. By implementing 2 different backends at the same time, I expect that it would help me keep the design well-crafted by clearing any wrong assumptions that could cause an undesired dependence to a specific backend. This will guarantee, that a 3rd backend could be implemented with a smaller risk of bad surprises.

What is coming next?

With the first released version, we have a foretaste of how this document editor will look like, but it isn’t very usable at the moment. In order to give a better taste of my vision in the coming 0.2 version, usability has to be tackled first. Document editors such as MS Word enable operations like inserting, copying, pasting and deleting content to be very easy to do. An editor like the one I am developing enables document edition in a more structured view, but how could it handle the mentioned operations in a user-friendly way? The next version aims at providing a satisfactory response to this question.

Part of my vision was also an intuitive document editor where things are easy to find, because they are where the user could expect they are. The next version will also tackle this point, as I will implement some block properties (formatting, spacing, etc), which will be configurable in the property pane.

Dynamic constructs such as tables and lists would certainly be interesting to implement, but as the next version focuses on usability, they will probably wait for the 0.3 version. However, some limited improvements like multilevel sections (sub-section, sub-sub-sections, …), code blocks (to directly write backend code to mitigate the absence of a feature) and potentially images will likely be implemented for the 0.2 version as well.