12 April 2014: The OpenOffice Wiki is not, and never was, affected by the heartbleed bug. Users' passwords are safe and wiki users do not need take any actions.

Reveal Codes - Alternative for OOo Writer

From Apache OpenOffice Wiki
Jump to: navigation, search

Take the following as the text for a document:

This is a heading
This is a paragraph with some hard formatted bold text.

In WordPerfect's Reveal Codes feature it would look like this:

[[Image:]]

The problem with implementing this feature in OOo Writer is the difference in the method of saving formatting codes. WP uses a single file with nested code tags (open & close) similar to HTML. OOo uses a zipped combination of several XML files. One of these contain the styles (both explicit & temporary), another contains the text content with open & close tags referring to styles (explicit and / or temporary). Each hard coded format change is converted into a new temporary style, and the content's tags are updated as such. Also there is no possibility of having any nested or overlapping tags – a new temporary style is generated for each difference.

To show an analogue of the differences here would be the pseudo code for the example above:

Ooo's StylesXML inside the ODT file

Explicit Style settings

Temporary Style settingsOoo's Content XML inside the ODT file

<Style=Heading1>This is a heading</Style><Style=Text body>This is a paragraph with some </Style><Style=Temp0001>hard formatted bold text</Style><Style=Text body>.</Style>Word Perfect's File

Default style formatting settings (e.g. Font, Size, etc.)

Explicit Style settings

Start of contents: <Style=Heading1>This is a heading</Style><Style=Text body>This is a paragraph with some <Bold>hard formatted bold text</Bold>.</Style>As you can see OOo only uses styles, no formatting is actually allowed. If the user changes a portion of text to have a hard formatted style (e.g. Bold) a separate temporary style is created. This style is copied from the previously “current” style and the change is made in the style's settings. Then the portion of text is applied the new style.

This in turn means there are no formatting codes as per WP's files. And seeing as there are only style tags in Ooo's files, there's also no possibility of any piece of text being applied more than one style (or any less).


The basic idea behind Reveal Codes is to enable the user to see exactly where what changes, and to allow the user to modify this so the document is formatted correctly. Especially if the user's combining data from various documents, inconsistencies may appear. And having to reformat all of a large document could become a time-wasting exercise.

Thus, a reveal-codes-like feature could help to fix the inconsistencies instead of requiring the user to reformat all – just to fix the portions which cause problems. Therefore a similar idea to Reveal Codes could be implemented. Proposed is to do exactly the same as WP does by indicating graphically how the data is stored in the file, but since OOo stores it slightly differently the indication would become a bit altered. The code display should inform the user where each style / hard-coding style is applied. A mode-less dock-able, and size-able frame would be ideal – default position as WP at bottom. It should look something like this (note text only mock-up):

Heading1► This ▪ is ▪ a ▪ ▄ heading ◄ Text body► This ▪ is ▪ a ▪ paragraph ▪ with ▪ some ▪ ◄ T1► hard ▪ formatted ▪ bold ▪ text ◄ Text▪body► . ◄The shaded portions represent the tags, and should be implemented as buttons. The spaces to be shown by some other character in order for the user to see them clearly. Also any line returns should be indicated – much like the existing “View → Nonprinting Characters” feature, although some extra differentiation should be applied for various codes (e.g. Tab, Page Break, Line-Return, etc.). The red block indicates the current cursor position: in the above a press of Backspace would remove the space prior to the word heading, while a press of Del would remove the h from heading (as would be expected). Any automatically generated styles should be indicated differently so the user can see what has been hard formatted – suggested using a differently coloured button as per example above.

[[Image:]]Another thing WP does is to indicate some further data when the cursor is moved to just before a tag. As seen to the right , the button expands to indicate some basic settings for the paragraph style called Heading 1.

The standard cursor behaviour would still apply. If the Code Display is open (maybe also if it's current – i.e. the active control on the Writer form) and the cursor is just before (or after) a style tag the Del & Backspace keys should remove that style assignment and revert to the previous. E.g. say the user wanted to remove the bold hard-formatting, the cursor should be moved to just before the T1 button (notice it expands to indicate some formatting info).

Heading1► This ▪ is ▪ a ▪ heading ◄ Text body► This ▪ is ▪ a ▪ paragraph ▪ with ▪ some ▪ ▄ T1;Bold► hard ▪ formatted ▪ bold ▪ text ◄ Text▪body► . ◄If the user now presses the Del key, the T1 style applied would be removed and the previous Text body style should be applied. In this instance the next style is also Text body, so these 2 assignments should be merged. The Code Display should now look like this:

Heading1► This ▪ is ▪ a ▪ heading ◄ Text body► This ▪ is ▪ a ▪ paragraph ▪ with ▪ some ▪ ▄ hard ▪ formatted ▪ bold ▪ text . ◄Further the user should be able to drag any style open tag to a new position. The close tag of the previous style should move with it, and if the tag is dragged over any other those should be removed.

Suggested indicators for non-printing characters:

¶ = Line-Return▪ = Space◊ = Tab / Indent§ = Page Break


Further functionality of the Display Codes feature:

Apart from the above, a double click on any explicit style tag should open the Style Editing dialog. However, how would a double-click have to be implemented on a temporary style? Should it be compared to the existing explicit styles, searching for differences and then opening the relevant dialog (e.g. if a font setting open the font dialog, if a paragraph setting → the paragraph dialog).

Because of the way OOo saves its styles, it would probably not be necessary to implement inside the styles editor as WP does. In WP this is usually used to adjust the order of settings – Ooo's settings seem to have no order at all and work the same way whatever order the settings are placed.

To go beyond RC, a comparison between the adjacent styles should be indicated. This could be implemented as a right-click on or in between the style tag's open and close buttons. Preferably also a mode-less, size-able and dock-able frame, or a fly-out frame anchored to the Display Code. When open this should update as and when the cursor moves to a new position. To keep consistency we could split this into the style groups using a tabbed interface. Sample as below:


Paragraph / Character / Frame / Page / List
Previous Style's Name Current Style's Name Next Style's Name
Font: Times New Roman Font: Arial Font: Helvetica
Merge to PreviousExpandMerge to Next

As can be seen, only the differences should be indicated by default. An Expand button to show all the settings, or possibly another collapsible tabbed interface based on the style editor (seeing as there's too many settings to display in one list).

Further a merge button to “join” the current style with the previous or next. Clicking the Merge Prev. should have the same effect as deleting the style tag in Display Codes.

Personal tools