- From: Peter Moulder <pjrm@mail.internode.on.net>
- Date: Tue, 13 Nov 2018 18:15:02 +1100
- To: Hans Meiser <brille1@hotmail.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
The approach taken by the PDF user-agent Prince is that construction of natural language is best left to script: otherwise, the parameter array will inevitably be found lacking once someone wants text like "at the top of" or "in the appendix" or whatever. More specifically, it allows a generated-content function prince-script(FUNC-IDENT, ARGS) where ARGS are other generated-content items (such as counter(page) and target-counter(URI, page)). So for just the page-number description, one might have CSS a[href ^= "#"]::after { content: " (on " prince-script(describeRef, counter(page), target-counter(attr(href), page)) ")" ; } and javascript Prince.addScriptFunc("describeRef", function(ownPage, targetPage) { /* To distinguish "above" from "below", one would query the dom * here, after adding function arguments attr(id), attr(href). */ if (ownPage == targetPage) { return "this page"; } else if (targetPage == ownPage + 1) { return "next page"; } else if (targetPage == ownPage - 1) { return "previous page"; } else { return "page " + targetPage; } }); (Prince cautiously requires FUNC-IDENT to be registered explicitly using Prince.addScriptFunc rather than automatically exposing all global named javascript functions. The second argument can either be a named javascript function, or an anonymous function as used above.) Depending on the desired behaviour of the suggested paragraph() function, it might be implementable just by querying a particular counter (and/or the page counter of paragraph elements). For the most general case, one can query the formatted document and re-start the layout with revised javascript inputs. A number of PDF-centric user agents for CSS allow use of javascript; I haven't looked at how the above would differ between them. pjrm.
Received on Tuesday, 13 November 2018 07:15:31 UTC