Best Practice Tagging: Page numbers

[jrbowden]

The Best Practice Tagging document currently has a section entitled "Page Numbers". Please note again there are three types of page numbers and therefore this section needs to be more specific:

• Print page change (indicator, can occur anywhere on a page)
• Print page numbers (on header/footer line)
• Braille page numbers (on header/footer line)

[wfree-aph]

Thanks @jrbowden. Would you able to make suggestions about how these additional page number types could be handled?

[jrbowden]

The print page change occurs in the running text, therefore this is the only kind of page number that needs encoding within the content, see #70 and example in Wiki.

Print and braille page numbers in a page header/footer line, may or may not be needed, and cannot be pre-calculated. Therefore they cannot be in the content, but have to be calculated at rendering time by the reading system.

This is because one of the requirements of eBraille is that text is reflowable to the reading system page size. Therefore, a "braille page" becomes a variable quantity. Thus, we do not know where braille pages will occur until the page is rendered. Therefore the braille page number cannot be calculated in advance. Similarly, because the braille page size is variable, the number of any "extension print pages" is also variable and therefore cannot be calculated in advance.

Information for what to do for running headers and running footer lines is therefore relevant:

• if embossing to hard copy, or
• if displayed on multiline display, or
• if a user specifically requests it (e.g. pressin a "Where Am I" command).

If a header/footer line is to be constructed, I suggest CSS (extension) is needed to define the position and numbering scheme used for both print and braille page numbers on the header/footer line. The reading system must use data supplied in print page change tags to construct running print page numbers. Reading system then constructs the numbers.

The following is purely speculative (as the CSS vocabulary has not been determined):

1. Reading System needs to pick up the page number from the new print page indicator and assign to a string variable.

2. Reading system needs to place the print page number, plus any numbering scheme requirements in the correct place on the page header/footer line

3. CSS is used to control the position where the print page is shown in header/footer line - if at all.

4. CSS extension is used to determine any extension page numbering scheme - e.g.:

   • whether it is the print page at the start or end of the page that is used,
   • what happens if there is a change mid-page,
   • if any prefix characters are used (like BANA) for continuation pages.
   • if print page change indication is suppressed if it occurs in a particular place (like first line of a page (BANA) - in the UK the print page change is always shown on any line of the page.

5. CSS extension is used to determine how the new print page indicator is shown (e.g. BANA line of 36 right across, UK dots 5-25 centred, etc).

There are several possible CSS extensions here and I may not have got this right. We might also have to define CSS vocabulary which we can hook the CSS onto.

I'm thinking along the lines (for the UK):

@printpagenum
{
  align: left;
  valign: top;
  scheme: last-on-page;
  continuation-scheme: none;
  sideroom: 3;
}

@brlpagenum
{
  align: right;
  valign: top;
  scheme: arabic;
  prefix: none;
  start: 1;
  sideroom: 3;
}

@printpagechangeindicator
{
  indicator: 5-25;
  align: centre;
}

For the US, perhaps it might be more like:

@printpagenum
{
  align: right;
  valign: top;
  scheme: range;
  continuation-scheme: alpha-prefix;
  sideroom: 3;
}

@brlpagenum
{
  align: right;
  valign: bottom;
  scheme: arabic;
  prefix: none;
  start: 1;
  sideroom: 3;
}

@printpagechangeindicator
{
  indicator: 36;
  align: full-line;
  suppress: line-1;
}

One advantage of this system is that a div could be used for sections of document where the numbering scheme needs to change: e.g. Roman numbered pages, or (in the US) T or P pages.

As I say, highly speculative, and there may be better ways to do this.

[jylioja21]

I'm confused as to the reasoning for having a div with class doc-pagebreak around the page number in example 26. Would it not work to just have the span before the heading without the container div, or does it need to be kept with the heading? The example reads:

<div class="doc-pagebreak">
   <div id="pagexvii" role="doc-pagebreak" aria-label="⠠⠠⠭⠧⠊⠊"</>
   <h2>⠠⠋⠕⠗⠑⠺⠕⠗⠙</h2>
</div>
<p>⠠⠞⠓⠊⠎ ⠃⠕⠕⠅ ⠊⠎ ⠁⠊⠍⠑⠙ ⠁⠞ ⠲⠲⠲</p>

[jrbowden]

This is an interesting case and I wanted to try and make an exaple where a print page break occurred with a heading and needed to be kept together, hence the div. Often, a print page break may occur mid-paragraph, hence a span. But in this case, we want the page break to be on the same braille page as the next heading. Slightly more awkward, but feel free to suggest alternative coding that's better.

[jylioja21]

There is some CSS markup for page breaks: see break-before from MDN. There is also a similar property for break-after. Using these properties, options exist to start a new page, including left or right, and avoiding a page break before or after an element. In the example, could we avoid the need for the div wrapping the page break and heading with CSS like:

h2{
break-before: avoid-page;
}

There may be more complexity to sort out, such as if the print page break happens to fall at the start of a braille page, it may not have a full line width page indicator.

[jrbowden]

Thanks. I was hoping the CSS would be included in the class definition. I added the div to group the page reference number and heading together. My idea was that we can take a new page before the page indicator, but then want the page indicator to be kept with the heading and the heading needs to be kept with the first bit of the first paragraph that follows. Normally, a heading should be kept with the first part of the text that follows, so this example with the page indicator is a little more involved, keeping three things together. It's not simply a case of preventing a page break after a print page indicator by default, because these can occur on any line of a page, including the last one, in running text.