19:12, 19 April 2012 (UTC) Still researching (= "stealing ideas from") Iannz's code. Problems include a bug in OO.o property sets, which causes a Basic error message that must be intercepted.
This is a preliminary specification. User feedback is welcome, either here, or on the Discussion page. Much more discussion can be found on Issue 3395 , and on the forum. Iannz's earlier work can be found on his home page; some of it is in this wiki.
For understanding the technicalities, Writer/Text_Formatting#Attributes provides a lovely and brief introduction.
A problem was introduced at the 3.1 level (Issue 103670 ) that the property-handling macros must allow for. Property names may exist for which no value can be found, producing a "runtime exception" Basic error. This is easily intercepted.
Provide a method in Writer to “reveal codes”, similar to a WordPerfect feature that most users of that Corel product would very much like to have in OO.o.
The general method will be to provide an extension, primarily written in Basic, which will evolve as better methods and user feedback become available.
The user selects a paragraph, either explicitly or implicitly (the paragraph containing the visual cursor), and invokes the extension (clicks on something). (In the initial implementation, if the user selects multiple paragraphs, only the first one may be displayed.)
The extension opens a new window (new Writer document), showing the text of the selection, with:
- NPC set
- Embedded numbered markers for each portion. Initially, these will be the section symbol (§) followed by a number, and shown in color (initially,
magentasepia, as stolen from Iannz). Eventually, both symbol and color should be user-selectable.
- List of attributes after the end of the text, labeled with the portion marker, and showing a kind of diff, of the attributes that differ from those of the previous portion. The list for the paragraph (Portion 0) will show only attributes that are changed by some later portion. Portion 0 may be of zero size. The lists will show the attribute’s name and new value. (Old value? Old value source?) (Back and forth hyperlinks, like wiki footnotes?)
The initial display will be read-only; the user must do any editing in the original window, and the results must be redisplayed. The initial implementation should redisplay itself whenever its window regains the focus.
The first major planned enhancement is the ability to merge a selected portion with either the previous or following portion, or both.
- Three icons / context-menu items will be provided: Merge Left, Merge Right, and Merge Both. One or two of these will in general be disabled for any particular portion; for instance, Portion 0 can only be merged to the right. If both previous and next portions have the same attributes, all three portions will be merged into one.
- Regardless of the merge direction, the attributes of the selected portion will be the ones changed. The normal case is expected to be that the user wants to get rid of a particular portion and its formatting. Since the results will be different for opposite merge directions, this may be confusing to the users. It may be possible to include a toggling button to reverse this effect, that is, to make the selected portion’s attributes override the others.
- This work will be performed on the original text, and the result redisplayed automatically.
- The change should be Undo-able in the normal way.
A second planned enhancement will allow editing (add/delete/change) of individual attributes in the portion attribute lists, subject to validation requirements.
It may be possible to finesse the horrendous validation problem by only allowing copying of existing attributes / values. This should provide enough functionality; the challenge is to make the copying convenient, probably using context menus.
Opening multiple “reveal codes” windows may be desirable, as for comparing the formats of different paragraphs. This should be safe to do, provided that the active window is up to date. Initially, any "reveal codes" window should refresh itself whenever it regains the focus. Considering the relatively small sections of text being displayed, this should be invisibly fast to the user, and hence suitable as a permanent solution. If not, more sophisticated techniques (listener for changes, marking as invalid) are available.