Ideas for a Custom Version of Crimson Editor

Jump to: navigation, search

---

Crimson Editoris free and open source. It is being developed under its original name at the Emerald Editorsite at sourceforge. A version could be developed which is optimized for proofreading and any other uses related to Project Gutenberg.

Ideas for Features and Improvements

• Fix its mis-rendering of the DPCustomMono2 font (by returning the maximum width instead of the average width in CCedtView::GetSpaceWidth). Presently, it collapses some spaces between words so that they run together. The fix mentioned above messes up word wrapping a little, so that would need to be fixed if the word wrap feature is to be kept.
• Preconfigure it very thoughtfully, so most users won't have to bother with it.
• Add utilities such as GutCheck as extensions, with a convenient means to navigate between the items they find. Highlighting or markings might be helpful too. Simply using Crimson Editor's bookmark feature would let the user go to all the lines of interest by repeatedly pressing F2.
• Fine tune the syntax-highlighting feature for use by proofreaders.
  • Changes should be highlighted and bookmarked
  • Provide descriptive "keywords" for marking possible problems:
    • MisplacedQuote
    • MissingQuote
    • DigitInWord
    • PunctuationInWord
  • Rapidly blink portions of text by selected types. This might be preferred by some to help locate errors and problem text.
• Easily navigate between markup pairs.
• Useful macros.
• Capitalization for proper names and titles.
• Improve the spell-checker. Provide means to easily add project-specific words. It presently doesn't recognize contractions.
• Add features suggested for the PrufIt project (that is, combine the projects).
• Add capabilities to support the uses of metadata as a solution to fancy formatting, updates and other issues
• Snap window size to about 80 characters wide for the currently selected font.
• A reference guide to formatting.
• Remove any features not needed by proofreaders, especially any that could interfere with them.
• Snap to and from a single line size (or a few lines) positioned in the middle of the screen with no extra GUI elements (toolbar, statusbar, scrollbar,...), for use in conjunction with an image viewer.
• Synchronize its scrolling with IrfanView, so the two work together as a single program.
• Save both local and remote copies simultaneously (besides backup copies).
• Download images, and etexts directly.
• Different operating modes for different aspects of proofreading, with clear indications of which one is active.

Highlighting Guide

It needs three different types of ranges:

1. Based strictly on character class: alphabetic characters versus punctuation and digits
2. Both beginnings and ends using the same marker, such as quoted text.
3. Each end using different markers, such as braces, parentheses and some multi-character markers.

• Alphabetic characters should always be black except inside quotes
• Punctuation and digits should always be red (or with a red background, since some punctuation characters are small and harder to see).
• Quoted text. Text within quotes should always have a distinct color, but the background color should reflect any other type of range it occurs in. Brown, green or blue would be a good color for quoted text.
• Bold text should be rendered bold and perhaps colored too.
• Italicized text should be rendered in italics and perhaps colored too.
• Braces and parentheses "[]{}<>()"
• Other pairs (opening and closing quotes,...)
• Multi-character markers

Background colors should only be used for text within ranges other than quoted text. All ranges delimited by markers should be global and fully nestable. It should detect improperly nested markers and alert the user.

Suitable efficiency for highlighting should be obtainable by maintaining an array of on/off events for all supported ranges. An element of the event array would consist of an 8-bit code for the event and 24 bits for the line number, for a total of 32 bits per element:

struct RANGEEVENT {
	unsigned int code: 8;
	unsigned int line: 24;
};

For highlighting purposes, there's no need to store the character positions where the events occur. All range markers would be retained in the text, of course. 24 bits can store values up to 16,777,216, which should be plenty for line numbers. Using this method should result in very fast code and be fairly easy to implement.

Sample on/off codes for ranges (except letters and delimiters). For "off" events, a code's MSB is set to zero.

#define BoldOn			0x80
#define BoldOff			0x00
#define ItalicsOn		0x81
#define ItalicsOff		0x01
#define DblQuoteOn		0x82
#define DblQuoteOff		0x02
#define SnglQuoteOn		0x83
#define SnglQuoteOff		0x03
#define IllustOn		0x84
#define IllustOff		0x04
#define ParenOn			0x85
#define ParenOff		0x05
#define SquareOn		0x86
#define SquareOff		0x06
#define CurlyOn			0x87
#define CurlyOff		0x07
#define AngleOn			0x88
#define AngleOff		0x08
#define ContentsOn		0x89
#define ContentsOff		0x09

There needs to be separate codes for each alternative markup styles.

Codes for Other Types of Content to Provide Markers For:

#define Book			0xC0
#define Volume			0xC1
#define Section			0xC2
#define Chapter			0xC3
#define Extra			0xC4 // copyright, producer notes and so on...
#define BkMark			0xC5
#define Error			0xC6
#define Spell			0xC7

It should support at least one group of keywords to use as temporary markers by automatic error checking code.

Links

• Crimson Editor's original home
• Emerald Editor
• Emerald Editor Forums
• "Using Crimson Editor for Proofreading" has a screenshot, plus highlighting, color and settings files specially designed for proofreaders.