The free and open productivity suite

Acknowledgement of short vowels and carried Hamsas

The 7 short vowels (َ ً ُ ٌ ِ ٍ ْ) appear always above or below a consonant.

The 4 carried Hamsas (أ إ ؤ ئ) have impact on pronunciation and spell checking

0

Availability of different calendar format

The Arabic world uses different calendars, e,g Hijri, Gregorian and Coptic. All these calendars should be support accordingly to their circulation.

0

Backspace and Delete movement

Delete and backspace must follow the exact same rules the cursor traveling and marking

Exception Thai:

Delete will remove the whole Thai "block of characters". (which may consists of consonant, vowel, tonemark, etc.)

Backspace will remove just one character, not the whole block.

0

Bidirectionally

Most important and complex feature:

This feature contains the ability to write from right-to-left (RTL) as well as from left-to-right (LTR). It must be possible to change freely within those two directions.

Apart from the ability to set the default layout of the page/document (RTL or LTR) we should be capable to let the user select how the cursor travelling and marking work. There are the logical order and the visual one:

1. Logical order:
   Select/travel through text the way the text was written, e.g. if the user travels through mixed text (Arabic/Latin) the cursor will travel from RTL while in Arabic text and “jump” to LTR movement (and text beginning) when reaching LTR text.

2. Visual order:
   Travel through text the way the cursor travel direction is assigned. thus when the user travels RTL the whole text will be travelled through in LTR manner regardless of content. In this case text will be travelled through in reverse (logical) order.
   Note: A visual selection is basically not possible due to technical reason (take multiple selection to the nth ;o)

0

Character shaping (Arabic)

Since Arabic characters have four different statuses how they can be displayed, isolated, initial, middle and final, they can change their appearance. Those characters make multiple appearance within the Unicode and must be displayed accordingly

0

Cursor movement direction

The cursor can move either way:

One possibility is to invert the cursor movement, e.g. Cursor-right would move to left in RTL formatted text.

The other is to do analogue movements, e.g. Cursor right moves right, independent from LTR or RTL formatting.

Note: Most people consider the latter to be more appropriate since it follows the WYSIWYG motto.

See more about this issues at Bidirectionality

0

Cursor movement within text

Since Thai and Arabic (and other) CTL languages allow to order consonants and vowels not only in a horizontal but also in a vertical order it is mandatory to modify the (visible) cursor traveling.

It is not advised to copy cat MS here since they do not provide a real visible feedback where the cursor stands. It might be a solution to only partly move or highlight the cursor.

0

Embed different text layouts into each other

It must be possible to insert e.g. RTL formatted text into a LTR formatted paragraphs. The original formatting must not change

0

Hindi digits support

While the digits we (Latin based countries) use are erroneously called Arabic the Arabic world uses Hindi based digits

0

Iteration and word breaking

CTL languages have various ways how word breaking, hyphenation and iteration works. For all those there must be a framework to take this in account

1

Sorting

Sorting should obey all possible alphabetical orders

1

Search & Find

Special characteristics of finding, e.g. search only for isolated characters in Arabic.

Search by transliteration must also be included in the framework

2

Justification

E.g: In the Thai language fully-justified text is often desirable. But because there are very few spaces in Thai, rivers of "white space" may open up where the spaces lie or a line may be broken badly to reduce the width of the space. As in English, the problem is exacerbated when the column width is narrow. However Thai allows for a method of solving this problem that could not be used in English: Thai justification.

Stress short vowels by colour

Stress short vowels by colour

2

Visual and Logical Order.

Visual order:

The order in which the text, independent from its meaning, is displayed on the screen

Logical order:

The order in which the text was typed in.

2

Date converter

Due to the fact of all different calendar format a date converter would make life much easier. More information can be found here.

3

Localised templates and sample documents

A localised cultural and political set of clip-arts, templates and sample documents should be included.

At least the existing set of clip-arts, templates and sample documents should be revised for any possible clash.

3

Localised UI

The UI should be available in the local language.

3

Re-design of menues and dialogues

To accomplish the RTL in Arabic (and other) languages the dialogues and menues need to be mirrored (in very simplified words!).

Apparently a simple mirroring though is not advised since the readability of dialogues might need to be updated to keep logical order.

3

Special font effects

Special font effects

3

Thai Buddhist Calendar

Thais use, apart from the “Gregorian calendar + Buddhist era” e.g. 18.10.2544 B.E., also a special calendar

3

Indexing and Thai "alphabetical" order

If a Thai document basically cannot have an index, due to the segmentation issue, it is not even possible to define what is a word and what is a phrase.

3

Diacritical marks

(Do we really need this feature at all!)

Diacritical marks should carry individual formatting. Its also advisable to fade them out, too. Unfortunately this applies (AFAIK) only to Arabic scripts. Thus it seems very advisable to connect those features like different colour or hiding of diacritical marks to the language attribute of the affected text. Why? Since e.g. Thai language also uses diacritical marks but there is no need for separated formatted and it would be lethal to hide them! So imagine a text that contains Arabic and Thai script! Hiding diacritical marks would lead to garbled and even unreadable Thai writing!

?

RTL UI

The complete UI must be capable of RTL layout (in most cases mirrored menus and dialogues)

?

Different calendars

Different calendars including different formatting are used in various Arabic regions. thus the number formatter must not only support different kinds of calendarial calculations but also different spellings. E.g. the month' names of various Arabic calendars can be spelled in Arabic, English transliteration and French transliteration.
Namely there are two important Arabic calendars:

1. Hedshri(?)

   1. With Hindi numbers

   2. With Arabic numbers

2. Gregorian

   1. In Arabic synonyms

   2. In Arabic transliteration from English

   3. In Arabic transliteration from French (optional)

?

Spreadsheet Calculation

Determine what figures/numbers should be used must be done by the number formatter. E.g. a spreadsheet is formatted in Thai than all numbers should be displayed in Thai numbers (which is a bad sample since Thais use Arabic numbers nowadays). moreover to accomplish the goal of Arabic number fallback Arabic numbers should be always part of the locale number format. It is to be determined what number format is to be defaulted (Arabic or local one). copying those numbers must always copy the correct string. Thus the target application will paste the correct Unicode glyphs.
A list of all available number sets of all StarOffice' supported locales is needed as well as the probability of their everyday-use.

?

Spreadsheets in Writer

Writer tables should work as Calc ones do

?

Number Formatting

Writer text should be able to adjust the number format according to the set locale. It should also be able to manually override this setting. The four possible settings are: Hindi (set all numbers to Hindi, regards of the selected locale), Arabic (see Hindi), Context (use the right layout depending on the surrounding context) and System (use the layout specified by the system's locale). The latter should be the default.

?

Search & Find (Arabic only)

Arabic input must be covered. Necessary options are “Match Kashida”, “Match Diacriticals”, “Match Alef Hamza” and “Match Control characters”.

?

Addressing G Sub Tables

To address G-Sub Tables in Unicode fonts (v.3) we need our font matching to be updated. G Sub-tables often contain in their Private Use Area (PUA) certain characters that are only used in certain countries or regions of countries and will be defaulted once the appropriate locale (e.g. Chines (Hong Kong) is selected.

?

Nesting of LTR in RTL text and vice versa

Nesting of LTR in RTL text and vice versa must be possible. Example: One writes Arabic text (RTL) and changes to English (LTR) and changes back after a few words to Arabic. Now one would like to insert Arabic (RTL) text in between two English words. This Arabic text must be nested in between the two English words without inverting the English word order (like MS Word does). this means each character must have an flag that indicates its text direction.

?

Grid Layout (CJK)

Grid layout for CJK text must be applicable to pages and text boxes. Necessary features are

1. Characters per row and column.

2. Pitch of characters

3. Count of rows and columns

4. Text behaviour regarding grid (e.g. snap to grid)

?