Support for defining (custom) counter styles

[GoogleCodeExporter]

... for use in obfl:page-number and obfl:current-page, and possibly for 
evaluating numeric variables with obfl:evaluate.

The syntax could be inspired by the CSS @counter-style rule. Examples:

    <obfl:counter-style name='decimal'
                        system='numeric'
                        symbols='⠚ ⠁ ⠃ ⠉ ⠙ ⠑ ⠋ ⠛ ⠓ ⠊'
                        prefix='⠼'/>

    <obfl:counter-style name='lower-alpha'
                        system='alphabetic'
                        symbols='⠁ ⠃ ⠉ ⠙ ⠑ ⠋ ⠛ ⠓ ⠊ ⠚ ⠅ ⠇ ⠍ ⠝ ⠕ ⠏ ⠟ ⠗ ⠎ ⠞ ⠎ ⠥ ⠧ ⠺ ⠭ ⠽ ⠵'/>

    <obfl:counter-style name='lower-roman'
                        system='additive'
                        range='1 3999'
                        additive-symbols='1000 ⠍, 900 ⠉⠍, 500 ⠙, 400 ⠉⠙, 100 ⠉, 90 ⠭⠉, 50 ⠇, 40 ⠭⠇, 10 ⠭, 9 ⠊⠭, 5 ⠧, 4 ⠊⠧, 1 ⠊'/>

It would be allowed to define the existing styles (default, roman, upper-roman, 
lower-roman, upper-alpha, lower-alpha) as well as new custom styles.

See also http://www.w3.org/TR/css-counter-styles-3/#at-ruledef-counter-style 
and http://www.w3.org/TR/css-counter-styles-3/#predefined-counters.

Original issue reported on code.google.com by bertfrees on 19 Sep 2014 at 9:18

[GoogleCodeExporter]

The number styles in the examples are already supported. For completeness it 
could be useful to allow arbitrary counter styles, but are there known use 
cases?

Also, I have tried to keep OBFL-files compatible with non-braille uses, e.g. 
for plain-text formatting. Therefor, I try to avoid creating OBFL-files with 
braille in them. In my view, the translations to braille above should be 
handled by a translator. I know this clashes somewhat with the pre-translated 
idea, and perhaps we need to sort that out first.

Original comment by joel.hak...@mtm.se on 11 Oct 2014 at 10:28

• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

The B in OBFL stands for braille, right? :)

While I do understand that you don't want braille in OBFL files (basically so 
that a single input file can be used to produce various output formats, 
right?), I see it differently. I don't see OBFL as an authoring format, but as 
a format that can be (dynamically) generated from e.g. ePUB. So does it really 
matter if there is braille in it? Different OBFL files will be made for 
different uses. If it's not for braille, then the formatting will most likely 
also be different.

Anyway, in my examples I'm basically defining the translation in OBFL. I like 
this approach (we're defining the formatting, so why not the translation?), but 
it doesn't have to be like that. The key thing is that it should be possible to 
specify how a number has to be formatted. This could be done by controlling the 
translator through some parameter associated with the number (the `style` 
attribute). If I understand correctly, we don't have such control over the 
translation at the moment. How it works now is: the style attribute controls 
how the numbers are first formatted to text (by the formatter). The text is 
then passed to a translator which translates it to braille. How I think it 
should work is: the number (the integer, not the text) is passed to the 
translator together with the style attribute, and the translator does all of 
the translation. This would be a more pure separation of translation and 
formatting.

Allowing arbitrary numbering styles would be very useful! There are use cases. 
For example, using the symbols * ⁑ † ‡ (or the braille equivalents) to 
number footnotes. Another example is a compact way of printing the combined 
braille/print page number: as a number in the upper 4 dots for the braille 
page, followed by a number in the lower 4 dots for the print page (so without 
number signs and without a space in between).

By the way, I don't think this is about pre-translating vs. 
translating-while-formatting at all. Numbers that are generated in the 
formatting process must be translated on the fly.

Original comment by bertfrees on 11 Oct 2014 at 12:01