Functional Requirements

4.1:25 The system shall support editing on block level in order to fix wrong translations, e.g. in the case of complex material such as mathematics. It is assumed that all other improvements outside blocks can be accomplished by changing the input document.

4.1:26 The system shall support editing beyond block level, e.g. in order to change the layout of tables or to manually alter the volume breaking.

4.1:27 The system shall be able to merge changes made in the original text with changes made previously in the braille version (possibly independently by another person). This ensures that the transcriber is not condemned to keeping on editing in the braille version after the smallest change.

4.1:28 The system shall be able to produce “synchronization data” for various intermediary and output files, which can be used for finding a location in one file that corresponds to a location in another file.

4.1:29 The system shall provide a graphical user interface for editing an intermediary braille file.

4.1:30 The user interface shall provide a side-by-side view of the original text and braille with synchronized cursor positions. For any position in the braille view, the user shall instantly see the corresponding original text, so that he/she is encouraged to do changes in the original whenever possible.

4.1:31 There shall be support for inserting braille characters using 6/8 keys on the keyboard.

4.2:32 The system shall be able to output various e-braille formats.

4.2:33 The system shall support a new e-braille format.

4.3:34 The system shall support the braille code used in Denmark, Finland, Norway, Sweden and Switzerland for uncontracted braille.

The system shall support Finnish uncontracted braille.

The system shall support Swedish uncontracted braille.

The system shall support Norwegian uncontracted braille.

4.3:34B The system shall be easily extended with new languages - for uncontracted braille - to make the system work globally in the long term.

4.3:34C The system shall support the braille code used in the Netherlands for uncontracted braille.

4.3:35 The system shall support the braille code used in Denmark, Finland, Norway, Sweden and Switzerland for 8-dot braille.

liblouis tests: text --> braille translation

4.3:35B The system shall support the braille code used in the Netherlands for 8-dot braille.

4.3:35C The system shall support the possibility to leave out capital signs in some products.

4.3:36 The system shall support double letter spacing, meaning adding a space between characters. Some characters should be kept together such as a capital sign and a letter.

liblouis-core tests: text --> braille translation with letter spacing

4.3:37 The system shall support the braille code used in Denmark, Norway, Sweden and Switzerland for contracted braille.

The system shall support Norwegian contracted braille.

4.3:37B The system shall be easily extended with new languages - for contracted braille - to make the system work globally in the long term.

4.3:37C The system shall support the braille code used in the Netherlands for contracted braille.

4.3:38 The system shall support marking of text-level semantics (i.e. em, strong) with braille indicators.

The system shall support marking of text-level semantics with braille indicators for Finnish uncontracted braille.

Norwegian braille.

4.3:39 The system shall support marking of visual text styling/typography (i.e. span[@class]) with braille indicators. This is because we are often dealing with input files that are marked up according to visual features of the print text instead of semantic meaning.

tests: text with visual styling (xml+css) --> braille translation

4.3:40 The system shall have a flexible and configurable mapping from markup to braille indicators. Because there is only a limited set of braille indicators they must be reused for different semantic meanings or typography depending on document and context. It must be possible to ignore certain styles that don't convey any useful information for the braille version.

tests: text with text-level semantics (xml) + configuration (css) --> braille translation

4.3:41 The system shall be able to perform automatic hyphenation for uncontracted and contracted braille.

The system shall support automatic hyphenation for Finnish uncontracted braille.

The system shall be able to perform automatic hyphenation of Norwegian.

The system shall be able to perform automatic hyphenation of Dutch.

4.3:42 The system shall support non-standard hyphenation. By non-standard hyphenation we mean that the spelling of a word can change when it is hyphenated. The braille translation of a hyphenated word can only change because the spelling changes, not e.g. because it is contracted in some other way. In other words the definition of non-standard hyphenation is not “extrapolated to braille”.

tests: text --> hyphenated text --> hyphenated braille

4.3:43 When automatic hyphenation is enabled, it shall be possible to exclude certain elements such as hyperlinks (based on markup).

4.3:44 The user shall be able to make a top-level configuration, e.g. toggle hyphenation.

4.3:45 The user shall have fine-grained control over the translation (on element-level) by means of configuration in those cases where markup of the input is inadequate or undesirable.

tests: text with markup (xml) + configuration (css) --> braille translation

4.4:46 The system shall have support for top, right, bottom and left margins on blocks.

4.4:47 The system shall have support for top, right, bottom and left borders and padding on blocks.

4.4:48 By default margins shall be collapsing. However there shall be a way to override this behaviour.

test margin vs. padding

4.4:49 By default empty lines at the top and bottom of a page shall be suppressed. However there shall be a way to override this behaviour.

test margin vs. padding

4.4:50 There shall be the possibility of shrinking a block with a border to the size of its contents. This feature shall be supported at least for blocks with left-aligned text and no nested blocks.

4.4:51 The system shall have support for first line indentation.

4.4:52 Besides left-aligned text, the system shall have support for centered and right-aligned text.

4.4:53 The system shall support block alignment relative to a vertical position on the page.

4.4:54 The system shall by default handle whitespace characters (spaces, tabs, line feeds) in the source XML according to the following rules:

• Comments are removed entirely and do not affect whitespace handling.
• All whitespace surrounding block elements is removed.
• Leading and trailing whitespace inside block elements are removed.
• Sequences of whitespace characters are reduced to a single space character. Newline characters are handled as other whitespace.

4.4:55 The user shall be able to override the default handling of whitespace for certain elements:

• Prevent collapsing of sequences of whitespace.
• Preserve leading and trailing whitespace inside block elements.
• Preserve newline characters as forced line breaks.

4.4:57 There shall be the option to reformat a table into a list,

• either by linearizing the table row-by-row with delimiters between cells,
• or by rendering each row as a sublist, where the cells are the list items. It must be possible to set off cells with a left margin according to their column, so that a stairstep format can be accomplished.
• It must be possible to prepend cells with their column header.

4.4:58 There shall be the option to render a table in matrix format, thereby mimicking the original form. This feature shall be supported at least for small tables that fit on a page horizontally without the need for text wrapping in cells, and that have no column- or rowspan. The matrix format supports borders and padding on rows, columns and cells.

4.4:56 The system shall provide a way to control the layout of each table separately.

tests: xml + configuration (css) --> formatted braille (pef)

4.4:59 When a table in matrix format spans multiple pages, there shall be the possibility of repeating the table heading at the top of each page.

4.4:60 There shall be the possibility of transposing tables, that is, treat rows as if they were columns and columns as if they were rows.

4.4:61 The system shall provide a table layout fallback mechanism that determines the best way to render a certain table by trying several alternatives.

4.4:62 The system shall be able to cope with column- and rowspan in tables (in a yet undefined way).

4.4:63 There shall be the option to render a big or complex table in matrix format through wrapping of text in cells and automatic computing of optimal column widths.

4.4:64 There shall be the option to render a wide table on facing pages.

4.4:65 The system shall be able to render tables of contents, list of images, index, glossaries, etc. in a two-column format with the entries on the left and other content such as page numbers aligned on the right. Optionally leaders may be used to connect the two columns.

4.4:66 The system shall support positioning of notes at the bottom of the page on which they are being referenced.

4.4:67 The system shall support collecting of notes either at the end of each volume, or at the end of the entire book.

4.4:68 The system shall provide a notes layout fallback mechanism that determines the best way to render notes. Notes of a certain type (e.g. footnote or endnote) shall be handled consistently throughout the whole document.

4.4:69 The system shall support inline rendering of notes right after the note reference, possibly surrounded by brackets or the like. This feature shall be supported at least for very small notes. As an option, notes may be floated to the end of sentences.

4.4:70 The system shall support rendering of certain elements such as line numbers in the left margin, taking them out of the normal text flow so that text that follows the element can continue on the same line.

4.4:71 The system shall provide the possibility of moving certain content that hinders readability, such as large tables, to a later position in the document.

4.4:72 The system shall provide the possibility of omitting certain content.

4.4:73 There shall be the possibility of rendering certain elements such as line numbers in the left margin, thereby reducing the area for normal text. A line break is inserted first whenever such an element is placed in the left margin, text that follows the element starts on the new line as well. In other words, the element is not taken out of the normal flow of the text.

4.4:74 The system shall support single and double line spacing.

4.4:75 When printing double-sided with line spacing greater than 1, printed lines shall alternate on odd and even pages.

4.4:76 The system shall support line spacing between single and double.

4.5:78 The user shall have control over page breaking by means of

• inserting hard page breaks,
• protecting blocks from being split across multiple pages,
• avoiding page breaks within blocks leaving only the first line(s) on the first page (orphan control),
• avoiding page breaks within blocks leaving only the last line(s) on the second page (widow control), and
• keeping a block’s first line(s) on the same page as the preceding block.

4.5:79 The system shall provide the option to disable page breaking for the purpose of producing digital documents (for reading on a refreshable braille display).

4.5:80 The user shall have control over the page dimensions and the size of page margins.

4.5:81 There shall be support for content in the header and footer of pages. Content can be rendered in the left corner, the center and the right corner.

4.5:82 The header and footer layout shall be able to change between sections within the document.

4.5:83 The system shall support flowing of text into the header or footer. With this is meant normal text that wraps around content in the right corner of the header or footer, not text that simply extends to the top or bottom of the page because there is no content in the header/footer. When there is content in either the left corner or the center, flowing into the header/footer is not allowed.

4.5:84 When printing double-sided, there shall be support for hard page breaks that jump to the next right- or left-hand page.

4.5:85 When printing double-sided, the system shall allow the page layout (page margins as well as header and footer layout) to differ between left- and right-hand pages.

4.5:86 Support for mixed braille and ink on the cover page, the main purpose being to help sighted people in finding a specific volume of a specific title. This feature doesn't require the text in ink to be exactly that of the original (so back-translation would be a possibility).

4.5:87 Support for interlining braille and ink, or combining braille and ink on facing pages. This feature requires synchronization between the source and the braille with medium (for facing pages) to high (for interlining) precision.

4.6:88 The system shall be able to perform automatic volume breaking with constraints. It shall be possible to precisely tweak the algorithm. It shall take values for minimal and maximal number of pages per volume. It shall support special ranges for the first and last volume of sections. The algorithm shall take into account that certain points in the book are better suited for being the start of a new volume than other points and that certain sections belong in certain volumes.

4.6:89 The system shall provide the possibility of repeating certain content, such as title pages, in several volumes.

4.6:90 The system shall support trimming down of a table of contents to a volume-scope table of contents that includes only the entries that reference items present in the current volume.

4.6:91 In the case of an extended table of contents that is not trimmed down (e.g. in the first volume), it shall be possible to group entries according to volume and insert a heading before each group.

4.6:92 In the case of endnotes being collected at the end of a book, it shall be possible to group the notes according to volume and insert a heading before each group.

4.6:93 The user shall have some form of manual control over volume breaking.

4.7:94 The system shall support formatting of numbers and other variables in a wide selection of formats. Supported formats shall include at least arabic, roman (small and capital), alpha (small and capital), downshifted, written out, and various date formats. It shall be possible to specify number prefixes and suffixes too. Some numbers might need specialized translation, such as ranges of print pages.

4.7:96 The system shall support automatic insertion of content that is not present in the source. Examples include:

• boilerplate text inserted e.g. on the title page,
• metadata and details about the production process,
• automatic transcriber notes that give information about omitted or moved content, about how tables are rendered,
• etc.

4.7:95 The system shall support insertion of content that is not present in the source, through configuration. Examples include:

• boilerplate text inserted e.g. on the title pages/colophons,
• freely definable one-character marks inserted in the left margin at certain elements,
• configurable titles for sidebars, figures,
• etc.

4.7:97 The system shall be able to perform automatic numbering of braille pages and volumes.

4.7:98 The system shall be able to perform automatic numbering on type "ol" lists. This includes advanced numbering of nested lists.

4.7:99 The system shall support resetting of braille page numbering at the start of major sections (frontmatter, bodymatter, rearmatter). Resetting numbering for each volume is not part of this requirement.

4.7:100 The system shall be able to perform automatic numbering (i.e. re-numbering) of notes. This feature relies on markup of the original numbering. The numbering shall be resettable for each page or for each volume.

4.7:101 The system shall support resetting braille page numbering for each volume.

4.7:103 The system shall support insertion of certain variables and counters at references evaluated at the target. An example is references in a table of contents. Supported variables shall include the print page number at the target, the braille page number at the target, and the note number if the target is a renumbered note. This feature relies on explicit markup of references.

4.7:104 The system shall support insertion of certain variables and counters at referenced items evaluated at the reference. Supported variables shall include the volume number at the reference and the braille page number at the reference.

4.7:118 The system shall support the creation of symbols lists, when characters have different meaning than normally (e.g. in mathematics).

4.9:108 The system shall support templates for different products, e.g. books vs. magazines.

4.9:109 The system shall support templates for different end user groups.

4.9:110 Users shall be able to reuse templates.

4.9:111 Certain users shall be able to create templates.

4.9:112 The system shall save jobs so that e.g. a job history can be showed, and jobs can be rerun.

4.9:113 The user shall be able to monitor jobs: get an overview of the jobs waiting, running, finished, etc., and receive notifications of certain events.

4.9:114 The system shall provide the user with help and guidance for creating templates.

4.9:115 The system shall provide a graphical user interface for creating and monitoring jobs.

4.10:119 The system shall support giving marked up mathematics code in ASCII-Math an output according to the mathematical braille code in the Netherlands.

4.7:117 The system shall support the possibility to integrate tactile drawings in braille.