Handling Line Ends in MultiLine Text Fields

Database Access

Document - ID	Specification Owner	Last Change	Status
	Frank Schönheit	2004-04-26	final
Conforms to	
Applies to	OpenOffice.org Base
Task ID(s)	13497, 14649
Category	Bug Fix

Abstract

When processing multi line text on a computer, there have always been two major approaches how to indicate a line break in a text, represented by a character string: so called "Unix style" line-ends and "DOS style" line-ends. Depending on which approach is used for a particular data set, applications working with this data need to take different measures to properly deal with the text.

Database Access is also affected by this: When storing multi line text in a database table (field), there is no general definition which of the two approaches is to be used, instead, the approach is chosen by the designer of the database, and/or the designer of the applications working with this database.

To allow the user the most flexibility in designing her database, and to improve OpenOffice.org's capabilities to interoperate with databases which follow any of the two approaches, the multi line text field in OpenOffice.org database forms will be extended with a setting how it should treat the input the user made – in a Unix-like or in a DOS-like way.

i-Team Members (The specification owner is part of the i-Team)

	Name	E-mail Address
User Experience	Christian Jansen (cj)	cj@openoffice.org
Development	Frank Schönheit (fs)	fs@openoffice.org
Quality Assurance	Marc Neumann (msc)	msc@openoffice.org
Documentation	Uwe Fischer (ufi)	ufi@openoffice.org

Approved for Implementation

	Approved by	Date
User Experience	Christian Jansen	2004-03-30
Development		
Quality Assurance	Marc Neumann	2004-03-24
Documentation	Uwe Fischer	2004-03-25
String Review	Elizabeth Matthis	2004-04-14

Document Change History

Rev. Level	Change	Initials	Date
1.0	final revision	fs	2004-04-26

Contents

Glossary	1

Legend	1

1	Motivation	1

2	User Scenarios	1

3	Requirements and Dependencies	2

3.1	Requirements	2

3.2	Technical Dependencies	2

4	Competitive Analyses	2

4.1	Microsoft Office	2

5	Detailed Specification	2

5.1	The "Line end format" property	2

5.2	Text columns in table controls	3

5.2.1	Keyboard handling	4

5.2.2	Interactively changing the row height	4

5.3	Defining the preferred line end format	4

5.3.1	User interface	4

5.3.2	Usage	5

5.4	Future Tasks	5

6	Notes	5

7	References	5

Glossary

Term	Description
Unix-style line ends	A special characters inserted into a character string to indicate that at this place, the string should be wrapped to a new line when displayed to the user. The character has the number 10, and is usually denoted as \r, or "line feed" (LF). These line ends are normally used in the Unix world.
DOS-style line ends	A pair of two special characters inserted into a character string to indicate that at this place, the string should be wrapped to a new line when displayed to the user. The characters have the number 13 and 10, and are usually denoted as \r\n, or "carriage return" (CR) and "line feed" (LF).
table data view	The grid-like view to data of a database table or query, accessible via the menu item Tools|Data Sources.
table cell	One cell (the intersection between a row and a column) in the → table data view.
active table cell	The one cell which is currently focused for the user to enter data into the underlying column of the database table. Only one cell in a → table data view can be active at a time.
property browser	A component for inspecting and modifying (form related) objects such as controls and → logical forms.
logical form	A component which is used to logically group multiple controls in a form document. A logical form does not have any visual representation in the document, it can only be seen in the → form navigator.
form navigator	a tool window used when designing a form document, which displays the hierarchical structure of the → logical forms and form controls in the document.

Legend

Throughout the document, some character styles are used to indicate various things. In particular:

This kind of text denotes a property name, as to be seen in the property browser.

This kind of text denotes a property value, as to be seen in the property browser.

Motivation

The very original motivation for this feature is that in the real world, there exist database installations with text with both Unix-style and DOS-style line ends. OpenOffice.org, however, so far is only capable of working with Unix-style line ends, while DOS-style line ends will be destroyed when edited with OpenOffice.org. This leads to incompatibilities when working with database applications which use DOS-style line ends, most notably with Microsoft Access.

User Scenarios

Users create database forms bound to an MS Access databases, with text fields which display and edit the content of a MS Access memo column. Up to OpenOffice.org 1.x, changes written using this text field are not properly readable in MS Access itself.

The user displays a table in the data source browser, which contains at least one column with text containing line breaks. Since the form table control - which is the basis for the table data view – does currently (up to OpenOffice.org 1.x) not handle line breaks at all, but simply cuts all line break characters, the data table view is effectively useless for editing multi line text, since all written text loses all it's line break information.

Requirements and Dependencies

Requirements

n/a

Technical Dependencies

n/a

Competitive Analyses

Microsoft Office

Various applications in Microsoft's office suite feature form controls for entering text. None of them, to the author's best knowledge, allows deciding which line end format should be used for stored text.

Microsoft Access already features multi line text in what is their equivalent to OpenOffice.org's table data view, but there is no particular UI associated with it.

Detailed Specification

The text fields which are available for OpenOffice.org form documents will be refitted with a new property, which controls how the control exchanges its text with other components. In particular, this property controls in which format the text will we written into a database table column, if the control is part of a database form, and properly bound to a table column. Additionally, the property will be available for grid control text columns.

The "Line end format" property

A new property called Line end format will be introduced. It is available for text fields only, will be displayed as a drop down list box, and allows to chose between the values DOS-like (CR LF) and Unix-like (LF). Depending on the setting of this property, the text which can be obtained from the control via API will contain either DOS-like or Unix-like line ends. As a result, when such a field is bound to a database column, the text entered by the user will be stored to this database column with the chosen line end format.

Effectively, this means that the line end format set at this property is used when writing text into database column.

String list

Item	English	German	Comments
Label	Text lines end with	Textzeilen enden mit	
List Box Value	CR+LF (Windows)	CR+LF (Windows)	
List Box Value	LF (Unix)	LF (Unix)	UFI: may be we can just use "CR+LF" and "LF" because we talk about these characters and not operating systems; EM: no, we should include the OS in the notation because it appears to be the standard.

Illustration 1context for string list (Line end format property)

The default value for this property, which applies when a new text field control is created, without knowing which database it belongs to, is Unix-like (LF), thus keeping the compatibility with older documents.

Text columns in table controls

Table controls in forms allow to insert text columns, which will be refit with the Multiline property which is already known from normal text field controls. When set to Yes, the input field for this column allows displaying and entering multi line text.

Since normally only one line of text is visible in a table control, the currently displayed line in such a multi line input field follows the cursor. If the height of the rows in the table data view permits displaying more than one line, it's not defined which of the multiple lines is the top at which time. But, as before, the invariant is that the line at which the cursor is placed is visible.

If a multi line table cell (i.e. a cell in a column which has set the Multiline property to Yes) is not active, then the very first line of the contained text is the first visible line in the cell area.

Additionally, the text columns will also be refit with the Line end format property described in the previous chapter, with the same semantics.

Side note: There is a pending implementation to refit the text field with a rich text mode. In the course of this, the Multiline property is going to be replaced with another property, which has three possible values. This replacement is only done for text field controls, not for text columns in table controls – the latter will keep the Multiline property.

Keyboard handling

When the focus is set to an active table cell containing multi line text, the usual keys for editing text are accepted (cursor keys, Page Up/Down, etc.). In case such a key is not handled (for example when the user pressed the Cursor Up key while the cursor was already positioned at first line), then this key is handled by the grid control, e.g. for traveling to the previous row.

To enter a line break in a multi line table cell, the user has to press Ctrl-Enter.

Interactively changing the row height

With multi line text columns, table controls now have at least one column type whose content is not strictly limited to one line of text – for all previously possible controls, the content they're displaying is not higher than one line of text.

With this, it's becoming desirable to easily change the height of the rows in a table control, since now changing the row height is often necessary to quickly see the content of a cell.

The current method of changing a row height requires quite some manual work: it is opening a context menu, selecting an entry therein which opens a dialog, unchecking a checkbox in this dialog, entering some value in an edit field, and confirming the dialog. Thus, the table control will be refit with an easy possibility to changes the row height.

If the user moves the mouse over a row separator in the record marker of a table control, the mouse pointer changes to the usual "split vertically" shape. Then, the user can interactively change the row height by simply dragging the row separator.

Defining the preferred line end format

To not burden the user with defining a line end format for each and every text field form control she creates, a setting – available per data source – will be introduced which specifies the preferred line end format for user interface components working with this data source.

User interface

As long as the new database application which is created for OpenOffice.org 2.0 is not available, this setting will not have a user interface. Instead, data sources will support this setting on the API level only, by recognizing a boolean setting called "PreferDosLikeLineEnds" in their Info property.

In the new database application, a user interface will be available for this setting. For this, a new checkbox will be introduced in the "Data Handling" tab page of the "Advanced Properties" dialog of a database file. This checkbox will read "Prefer DOS-like line ends". For a newly created database file of type "MS Access" (which is available on Windows only), this property will be checked by default. For all other databases, the checkbox will by default be unchecked, always defaulting to Unix-like line ends this way.

String list

Item	English	German	Comments
Checkbox	End text lines with CR+LF	Textzeilen mit CR+LF beenden	

Illustration 2advanced settings of a OpenOffice.org 2.0 database See Illustration 2 for the screenshot of the dialog where the new setting will appear.

Usage

The setting described in the previous chapter is evaluated in the following places:

When a new text field form control is created, and there is a canonic way to determine the database this text field is expected to work with, then the data source setting is examined, and the Line end format property of the text field controls is initialized accordingly.
Canonic here means that either the control is created in a form document belonging to a database document (see the specification for the new database application, the reference is to be found in the "References" chapter), or in a logical form which is already properly bound to a data source.

When the data table view is opened for an existing query or table, and one of the columns contains a memo text column, then the line end setting of the data source / database is examined, and the Line end format property of the table control column which is to display the text column is initialized accordingly.

Future Tasks

Notes

References

Rich Text Control specification:
http://dba.openoffice.org/specifications/forms/rich_text_control.sxw

The new database application in OpenOffice.org 2.0:
http://dba.openoffice.org/specifications/Database_application.sxw

Setting up the properties of a database in OpenOffice.org 2.0:
http://dba.openoffice.org/specifications/Data_Source_Property_Dialog.sxw

Setting up a database in OpenOffice.org 2.0:
http://dba.openoffice.org/specifications/Data_Source_Property_Dialog.sxw

In OpenOffice.org 2.0, this was View|Data Sources

Handling Line Ends in MultiLine Text Fields

Page 5

http://dba.openoffice.org/specifications/multiline_line_ends.sxw

Frank Schönheit

2004-03-15T18:20:47