Curl as a markup DSL for Russian Text

[RobertShiplett]

If you visit a Russian topic at http://en.wikipedia.org you should see diacritic markup of the accent on each Russian word.

These marks are created using UNICODE combining characters. You can see this by pasting a text example with those accents into a UTF-8 text editor.

Place your insert cursor behind a letter FOLLOWING a character with an accent. Go back once with the arrow. Hit BACKSPACE once - and now the character should display there without the accent mark.

An e-text viewer with the option to display these accents would be very valuable to Russian-LANG-X bilingual text viewers. There are Python and Perl modules for achieving this, but they will not give you a markup DSL such as Curl macros offer.

Should this capacity be coded as a mix-in ?

As a String method, {to-unaccented } would be no more unusual than {to-upper-clone } (though not as trivial as in the days of ASCII) and the method would be a welcome addition to the new COM.CURL.LIB package as another class method on StringUtil in the package COM.CURL.LIB.LANG ( should 'combining-character' be another param to {is-member? } ? )

But is that where this behavior belongs? Look at what happens today in an Epub reader if you add a note or bookmark to selected text: there will be no option to flip the view so as not to display that garish yellow "ink" marking the selected text. The option for a clean view is very important when reading poetry - but it is only available in Curl by using alternate views with redefined macros.

What is needed is the ability to add a menu item to a Visual component's popup menu so as to toggle a display option: the visual repaints -and passes up the selected option to the container. Or should the container be pushing the option down as "shared" ?

We now have TextVisual and ParagraphVisual as classes ... what would that option look like - the option to see text with selected formats suppressed (no italics, no bold, no link highlighting). Would all of the text format macros have to be re-implemented to check their container's global flag? Would only text-format-procedures be capable?

Example: StringUtil lib class now has:

public inline {StringUtil.katakana-to-hiragana str:String}:String

Example: Visual currently has the non-local option for the default {font-size }.

Example: TextVisual has:

style-options : Options specified for this object via the style mechanism, if any.
getter protected Visual.style-options:#OptionItem
setter protected Visual.style-options:#OptionItem
Description
The option list is represented as a linked list of OptionItems.
Use the getter Visual.options-present-here if you want to iterate over all options set on a Visual, whether set directly or via a style sheet.

ParagraphVisual has:

public {OptionListInterface.add-style-option key:OptionKey, value:any }:void

Add an option to the style-options list or change the value of an already existing option. The change only occurs if the value differs from the current value of the option.

Personally, I see text-format-procedures as the way to go because of my bias for Curl as a DSL for rich text markup - and my preference for explicit markup over less evident styles. Certainly, from the reader-user's standpoint, flipping a style is as effective as flipping a flag. But that alternative is not so obviously preferable to me from the standpoint of one doing text markup on text to be displayed in a GUI. I am not opting to change "style" but to parse content (rather like katakana-to-hiragana .)

[alton]

Nice post. I like it. Thanks for sharing these information. Keep it up.