Print page range on first braille page does not include first print page

[bertfrees]

See test in test_css_formatter.xprocspec.

[bertfrees]

There are two separate issues:

1. The behavior of "page-start-except-last" is a bit unfortunate, but strictly speaking not a bug. To understand this let's consider the case where there is some content before the first page number ("2"). The page number range would still be the same ("4") and this would be a correct result according to the CSS:

   @top-center {
       content: string(print-page-from, page-start-except-last)
                string(print-page-to, page-last);
   }

   "page-start-except-last" is not defined in the spec yet but would be defined analogue to "page-start":

   a) The value of the first assignment on the page is used if the content box (fragment) of that element does not follow any other content boxes on the page.
   b) Otherwise the assignment in effect at the end of the previous page (entry value) is used.

   It currently says nothing about the case when there are content boxes preceding the first assignment on the page and there is no entry value, so it results in the empty string, and not the first value on the page ("page-first").

2. The fact that "page-start" and "page-start-except-last" do not select "2" in the test is a bug. Notably the "a)" part of the definition is broken. This could (and should) be fixed directly, however if we would slightly change the meaning/behavior of "page-start" and "page-start-except-last" in order to solve issue 1, we also make issue 2 less of a problem.

---

Example input:

<dtbook>
  <book>
    <bodymatter>
      <level1>
        <pagenum page="normal" id="p-2">2</pagenum>
        <h1>Hoofdstuk 1</h1>
        <p>Eerste alinea.</p>
        <pagenum page="normal" id="p-3">3</pagenum>
        <p>Tweede alinea.</p>
        <p>Derde
          <pagenum page="normal" id="p-4">4</pagenum>
          alinea.
        </p>
      </level1>
    </bodymatter>
  </book>
</dtbook>

and expected result:

⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠼⠃⠀⠤⠀⠼⠙⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠼⠁
⠨⠓⠕⠕⠋⠙⠎⠞⠥⠅⠀⠼⠁

⠨⠑⠑⠗⠎⠞⠑⠀⠁⠇⠊⠝⠑⠁⠲
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠼⠉
⠨⠞⠺⠑⠑⠙⠑⠀⠁⠇⠊⠝⠑⠁⠲
⠨⠙⠑⠗⠙⠑
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠼⠙
⠁⠇⠊⠝⠑⠁⠲

[bertfrees]

daisy/pipeline-mod-braille@463796f would fix it if it weren't for this rule in dedicon-default.scss:

frontmatter, bodymatter, rearmatter {
    /* The following line sets the values used for the top-center page position and the TOC. */
    string-set: print-page-from '', print-page-to '', print-page-toc '';
}

@dkager: What exactly does this do?

[dkager]

frontmatter, bodymatter, rearmatter {
    /* The following line sets the values used for the top-center page position and the TOC. */
    string-set: print-page-from '', print-page-to '', print-page-toc '';
}

Off the top of my head this ensures that there are no "left-over" page numbers when changing from frontmatter to bodymatter or from bodymatter to rearmatter. This rule can probably be removed if the scope of a can be limited some other way. Maybe by adding an explicit empty at the start of the bodymatter/rearmatter through XSLT.

[bertfrees]

So basically with the empty string you'd like the formatter to behave as if no string was set at all? The specification is currently unclear about what to do in the case of empty strings. And I'm not sure yet what the best would be. Moreover I also haven't figured out how string-set should best behave in combination with flows. It might be that your CSS "hack" wouldn't be needed if string-set would behave differently within flows.

What we'll do for now is make the behavior implementation-dependent. I'll add a "treat-string-set-empty-as-absent" parameter to the formatter so you have control.

[bertfrees]

I'll add a "treat-string-set-empty-as-absent" parameter to the formatter so you have control.

OK forget this. It's not that simple because you only want an empty string to mean absent in a backward search, not in a forward search. Now it's starting to smell hackish...

[bertfrees]

Maybe a better idea is to have a separate variable print-page-front for frontmatter page numbers?

[dkager]

In addition, I think accurate print page ranges has (much) higher priority than avoiding some "accidental" print page numbers when the bodymatter begins/ends. The latter can be hacked around, the prior not really.

[bertfrees]

Now that the related SBS issues sbsdev/pipeline-mod-sbs#42 and sbsdev/pipeline-mod-sbs#45 have been fixed, it should be straightforward to fix this issue. I think there are even no changes required in the CSS, just the changes to pipeline-mod-braille which you should be able to cherry-pick from SBS, or alternatively you can wait for these changes to be included in a new version of the Pipeline and then update to that version.

For the "left-overs" issue I've created a new Github issue: #54