My intuition was correct (and led to some bug fixes in the numbers
handling machinery, which is all to the good). In response to Carles’
objection to passing through possibly-broken connecting punctuation,
I’ve extended the logic to assume more complete control over
punctuation and formatting in the target case.
Since calling applications would have to do something similar in order
to supply pre-parsed content, embedding this logic in the processor
seems likely to serve the purpose at lower social cost.
This should play nice with the companion proposal to open up issue,
volume and edition as variables available for use with cs:label, with
its contextual pluralization behavior.
Here’s a revised proposal for the specification:On Sat, Nov 13, 2010 at 11:00 AM, Frank Bennett <@Frank_Bennett> wrote:
On Sat, Nov 13, 2010 at 10:55 AM, Frank Bennett <@Frank_Bennett> wrote:
On Sat, Nov 13, 2010 at 10:48 AM, Carles Pina <@Carles_Pina> wrote:
Hi,
On 13 November 2010 01:10, Frank Bennett <@Frank_Bennett> wrote:
While making fixes in response to some of the recent activity on the
Zotero forums, it occurred to me that it would be kind for cs:number
to recognize, and apply formatting to, more than one number. For
example, we might have input like this:
volume: 11-15
If rendered with , the
specified rule would produce this output:
xi
Whereas a user will certainly expect something like this:
xi-xv
I have extended citeproc-js a little to handle this case, and I’d like
to propose a change to the specification along these lines:
“If a variable displayed with cs:number contains no characters other
than numbers, and optionally one or more connecting comma, space,
hyphen or ampersand characters, each number in the variable will be
rendered with appropriate formatting (e.g. “3 & 4” rendered with
form=“ordinal” becomes “3rd & 4th”). If additional characters are
included in the input, only the first number encountered is used for
rendering (e.g. “12” when the entire string is “12th edition”).”
What do you think?
In general speaking, I usually prefer to give to citeproc-js as well
detailed and defined as I can*. So in this case I would prefer to
break up the number variable to have a “start” and “end” elements
instead of free text. And that the users of citeproc-js / citation
engine should handle it (forcing the input in two fields, splitting
the input somehow, etc.).
But there could be holes in the sequence: “3, 4 & 6”.
On the other hand, I may have missed something in my current patch.
citeproc-js has range collapsing logic for numbers that should be able
to handle this case, if the discretionary prefixes are set correctly.
Hmm …
If a variable rendered with cs:number contains no characters other
than numbers, and optionally one or more connecting comma, space,
hyphen or ampersand characters, it is treated as a list. In this
case, the intervening punctuation is ignored, and the list is sorted
and rendered with appropriate connecting punctuation (e.g. “4, 3 & 5”
rendered with form=“ordinal” becomes “3rd-5th”).
If additional characters are included in the input, only the first
number encountered is used for rendering (e.g. “12” when the entire
string is “12th edition”).