Compulsive font browsing: FontExplorerX

The best font browser I met at this time: Linotype FontExplorerX. I'm playing with the Mac version and it rocks! Top features:

• Can visualize non-installed fonts.
• Many font formats supported.
• Displays a whole font family at once. Also recognizes Optical fonts.
• Sparse selection for multiple previews. Supports multiple windows for font detail. That's incredibly useful for comparisons!
• Rich preview options, like custom text and ligature activation.
• Detailed font information with huge zoom factor, baseline display, x-height and bouding box.
• Unicode support.
• Virtual font folders.
• Detects font conflicts.
• More than font viewing: may intercept system calls to obtain fonts from some applications like InDesign or XPress.

It's a commercial product with an option to buy fonts on Linotype's site, but it is downloadable and usable for free. It's a beautiful professional tool. Real font lovers like me will find it more addictive than YouTube!

LyX: the WYSIWYM document processor

I'm always glad to see there are clever projects providing alternatives to boring WYSIWYG word processors. LyX is one of those. It defines itself as a "What You See Is What You Mean" document processor. LyX is a graphical environment for typing LaTeX-like documents. Text displays nicely with various font sizes and so on, but does not attempt to match exactly the final result, so it can display useful tags and so on. LyX documentations coins a few interesting terms: "WYSIWYM", "document processor" instead of "word processor" and "finger painting" for this boring way to set style at character level under a graphical user interface. LyX requires TeX. Check the demo video for mathematical equations, it rocks.

Novelang-0.13.0 released!

Latest release of Novelang available here. Better detection of text inconsistencies (lexer now reports problems). Enhanced font list: doesn’t break where there are no custom font at all. Cleaned up samples directory: most of stuff here was for tests, that moved to src/test-resources. Enjoy!

Refactoring Novelang grammar

I started working on a refactoring of the Novelang grammar and it's a big job. By the way I switched to ANTLR-3.1.1, the latest version of ANTLR. The development occurs in the ANTLR-3.1.1 branch. ANTLR is the greatest tool for generating parsers. With version 3.1, it supports grammar imports, which means a complex grammar can split in smaller files. With careful design it would be possible to let third-party developers extend Novelang grammar, as ANTLR supports rule overriding. Alas, ANTLR-3.1.1 doesn't work well with multiple import levels so I'm keeping one huge grammar file for now. You can have a look at current Novelang grammar (master branch). For the end-user, the biggest feature brought by this refactoring is support for "monoline" text items. Basically this is for stuff delimited by a pair of line breaks and that may stand in the middle of a paragraph. By now, Novelang only recognizes URLs when delimited by two pairs of line breaks.

(This is some paragraph before the URL.)

http://novelang.sourceforge.net

(This is some paragraph after the URL.)

Recogninizing a URL as "monoline" text item would allow something like this:

This is a paragraph.
http://with-url-inside.com
...Same paragraph, continued.

That's a lot more natural. The URL still must start at the start of the line, because it's much easier to copy from the text editor. I previously discussed URL syntax here. Coding Horror blog has a nice post that should deter anyone to include URLs in plain text with no machine-understandable delimiter. The full-blown URL syntax supports URL decorations like this:

Go to 
  "Novelang website" 
  [Novelang website on Sourceforge.net]
http://novelang.sourceforge.net
and see all useful links.

The quoted and bracketed text blocks are optional and provide display text and alternate text. I can see no reasonable way to support them at grammar level. The best way to handle them is at tree-mangling stage (reordering the Abstract Syntax Tree generated by the parser). This means, the parser-generated AST should include nodes describing whitespace and line breaks. Support for monoline items is helpful (necessary?) for supporting lists. As previously discussed, here is how I want to write a list:

Here is a list on two levels:
* First item
* Second item
  * First subitem
  * Second subitem
* Third item
...And the paragraph continues here.

As for URL decoration, the grouping of list items is made at tree-mangling stage. Because identation matters, whitespaces in AST should tell how big they are. A list which can appear inside a paragraph will be called a small list. There is the need for another kind of list where items are paragraphs, to be called big list. The symbols for designating list items ("*", "#", "-", "---",...) are left to another discussion.