-
Notifications
You must be signed in to change notification settings - Fork 5
On page numbers
eBraille
There are three kinds of page numbers needed: braille, print, and print page change indicators.
Print page change indicators are hard coded in the document content. The other kinds are calculated by the reading system.
References to print pages may be hard-coded text in the document.
References to braille pages need to be calculated by the reading system.
For details of a way to encode a table of contents entry with braille page reference, see the final section.
Page numbers occur in various styles and places, particularly in hardcopy documents. They may be used differently when a document is displayed on a refreshable braille display, but the underlying principles mostly remain the same.
Page numbers from the original document may occur as part of the running text. Generally, these will be hard-coded numbers, according to the original print document, e.g.
"For more information see page 76."
Authors may decide to code such page references as links, or page reference links.
Print page change indicators are inserted by transcribers to indicate where the original print document had a change of page. They generally interrupt the flow of the body text and may occur on most lines of the braille page. Note some regions have rules for when they may be omitted.
In a hardcopy document, the first and/or last line of each page may be used to show, amongst other information, page numbers. The rules vary from braille region to braille region.
The page header/footer line is the hardcopy equivalent of a "status bar" of a word processor or the "where am I" command of a screen reader. Thus, in refreshable braille displays, page header/footer lines may be omitted, or may be displayed on user command, or may show as a status bar on multiline devices.
The information that appears on a header/footer line is controlled by a template, probably some form of CSS extension. The Reading System then fills in the information as indicated by the template.
The precise format of a template has not been discussed, but as an idea, CSS extension, see issue #138:
There are therefore three kinds of page numbers we will consider:
The print page change indicator shows where a page change occurs in the original print document. In BANA countries it is a full line across the page of dots 3-6 immediately followed by the new print page right aligned. (Other countries have other methods for showing this, not listed here).
The Best Practice Tagging document shows encoding for how print page change indicators are encoded in the main text of the eBraille document.
Simplifying, the print page number on the page header/footer line is roughly speaking a copy of the most recent number indicated by the last print page change indicator. This copy is shown on the page header/footer line (first or last line of the braille page), as indicated by the page header/footer template in CSS.
In BANA countries, if a print page spans more than one braille page, prefix letters are added to the number, thus a8, b8, c8. Other countries may show a range of pages if there is a change, e.g. 8-9.
Therefore, as the braille page size varies according to Reading System, print page numbers on page header/footer lines must be generated by the Reading System. This includes managing any prefix letters, page range indications, or any other consideration. Only the basic page number comes from the document content. This is why there is a CSS template to manage how to position the page number and any prefix is generated.
Note: on refreshable braille displays, page header/footer lines may not be displayed at all, or only be displayed on user command. See Page Header/Footer Lines, above.
Braille page numbers normally refer to physical sheets of braille paper and have little or no connection to the original print document.
Braille page numbers are generally shown on the page header/footer line, according to the header/footer template in CSS.
As the braille page size varies according to Reading System, the reading system must generate the braille page numbers.
Braille page numbers may be of various styles, including (but not limited to) Arabic or Roman numbers, with or without prefix characters.
It is suggested that a <div> is used to specify the style for braille page numbers in the main parts of a book.
For example, in BANA countries, the "T" pages may be one <div>, the "P" pages, another, and the main body a third. Alternatively, there could be a div for the Roman page numbers and another div for the Arabic.
Example
<div class="t-pages">
... ← all the content for T-pages goes here
</div>
The class information is contained in CSS extension because braille page numbers cannot be calculated, they have to be generated by the Reading System. The CSS governs the position, numbering system and any prefix characters needed.
References to pages in the document may be to print or braille page numbers. As stated above, print page numbers are likely to be hard coded from the original text, and therefore require no special attention.
However, should braille page references be required, they cannot be hard coded as the braille page size varies according to Reading System. In order to create a braille page reference, a mechanism similar to a "page ref" field code in a Microsoft Word document is required. There is no such tag in standard HTML to do this.
Most commonly, braille page references will be needed if a table of contents wants to refer to braille page numbers.
Tables of Contents in braille are of various forms, for example, for an entire print book, a single braille volume, and so on. Different regions have different rules for how to lay out and what to include in a Table of Contents, so the below concentrates on a single entry which contains a reference to a braille page.
In a hardcopy braille book, a table of contents entry generally consists of:
-
A heading, taken from the book. It is indented appropriately according to the heading level.
-
A leader line, which can be of various types,
-
A page reference where to find the item. The page reference may be to a print or a braille page number.
Of course, if there is no page number present, there is generally no leader line either.
In an eBraille document it is likely that entries in the table of contents will be links pointing to the relevant heading. It would therefore be possible to dispense with the page numbers and simply have a list of links.
However, the moment this document is needed in hardcopy, the page numbers need to be present as an alternative to links.
There is no harm if a refreshable braille display wants to display the page numbers, mimicking what would appear in hardcopy.
As stated above, print page references may be hard-coded numbers. Braille page references need to be calculated by the reading system.
Two speculative methods are given below for how braille page references may be coded in the eBraille file.
If a media query is given in CSS for a particular braille page size, a braille page number may be hard-coded, because the number will only appear for that particular page size.
For example, a media query checking for, say, 40 character by 25 line pages, could then hard code a page reference for say, braille page 78. This could be done thus:
<span class="media40x25">78</span>
The advantage of this method is that media query syntax can be used, governed by CSS, with little extra work needed in the Reading System.
The disadvantage is that, to cater for a variety of possible paper sizes, multiple queries would have to be included for every single braille page number reference, leading to file size bloat. It may also be an added burden on authors to cater for a variety of page sizes.
This method also has the disadvantage that, if the page size is not one of those specifically listed in the media queries, then the page reference will fail and there will be no output.
An alternative approach is to invent a new tag which can be put in the document to represent a braille page reference. This tag would trigger the Reading System to calculate the braille page for the destination of a link and fill in the contents.
Note that already, we are requiring the Reading System to render braille page numbers for the page header/footer line, which it must calculate when rendering the document. The same numbering logic can be used for rendering braille page references – in fact, the number could simply be copied from the page header/footer line.
For the braille page reference, the encoding could be something along the lines:
<@brlpageref href="#chapter5"/>
Although there is some custom coding required in the Reading System to handle the proposed new tag, the advantage of this system is that braille page references will work, no matter what the page size. The coding in the file is also succinct, avoiding a multiplicity of page sizes.
Below is a possible encoding for a complete item in a table of contents, referring to a braille page number. For simplicity, assume the overall structure of the table as a whole has already been set up. The link points to a main heading, chapter 5.
<li\>
<a href="#chapter5">⠼⠑⠲⠀⠠⠞⠑⠉⠓⠝⠕⠇⠕⠛⠽
<span class="tocbraillepage">
<@brlpageref href="#chapter5"/>
</span>
</a>
</li>
The class in the span above would be used to generate the required leader line and align the braille page number appropriately. example output:
⠼⠑⠲⠀⠠⠞⠑⠉⠓⠝⠕⠇⠕⠛⠽⠀⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠐⠀⠼⠙⠉