Hi,
I saw Frank updated the styles with date ranges so to use en-dash
instead of hyphens for delimiting ranges.
Shouldn’t we use en-dashes for page (and other numeric) ranges too? (I
had this thought while implementing the page-range-format option).
Andrea
PS: citeproc-hs now supports bibsection for bibliographic output
selection, and successfully passes the bibsection group of tests.
Another question: is correct to use the “page-range-format” attribute
also for formatting the locator?
Andrea
I’d say yes, we should consistently use en-dashes for all numeric ranges.On Nov 27, 2010 12:54 PM, “Andrea Rossato” <@Andrea_Rossato1> wrote:
Hi,
I saw Frank updated the styles with date ranges so to use en-dash
instead of hyphens for delimiting ranges.Shouldn’t we use en-dashes for page (and other numeric) ranges too? (I
had this thought while implementing the page-range-format option).Andrea
PS: citeproc-hs now supports bibsection for bibliographic output
selection, and successfully passes the bibsection group of tests.
Hi,
I saw Frank updated the styles with date ranges so to use en-dash
instead of hyphens for delimiting ranges.Shouldn’t we use en-dashes for page (and other numeric) ranges too? (I
had this thought while implementing the page-range-format option).Another question: is correct to use the “page-range-format” attribute
also for formatting the locator?
Good point. At the moment, I’m pretty sure that citeproc-js doesn’t
touch the locator content, but when the label attribute is set to
“page”, at least the first run of numbers (with any ampersand, comma,
or hyphen delimiter cruft) could be reformatted, with the ranges
normalized. Shall we add that to the specification, and build some
tests?
Hi,
I saw Frank updated the styles with date ranges so to use en-dash
instead of hyphens for delimiting ranges.Shouldn’t we use en-dashes for page (and other numeric) ranges too? (I
had this thought while implementing the page-range-format option).Andrea
PS: citeproc-hs now supports bibsection for bibliographic output
selection, and successfully passes the bibsection group of tests.
That’s great! With bibsection, you can cover a use case for the
classics, where standard references in the citations are excluded from
the bibliography.
I’d say yes, we should consistently use en-dashes for all numeric ranges.
Very good. Changes coming up.
Hi,
I saw Frank updated the styles with date ranges so to use en-dash
instead of hyphens for delimiting ranges.
Thanks for being tolerant; I know I’ve been playing fast and loose
with the test suite lately. It’s just been due to time pressure.
I’d say yes, we should consistently use en-dashes for all numeric ranges.
Very good. Changes coming up.
Done.
Hi,
I saw Frank updated the styles with date ranges so to use en-dash
instead of hyphens for delimiting ranges.Shouldn’t we use en-dashes for page (and other numeric) ranges too? (I
had this thought while implementing the page-range-format option).Another question: is correct to use the “page-range-format” attribute
also for formatting the locator?Good point. At the moment, I’m pretty sure that citeproc-js doesn’t
touch the locator content, but when the label attribute is set to
“page”, at least the first run of numbers (with any ampersand, comma,
or hyphen delimiter cruft) could be reformatted, with the ranges
normalized. Shall we add that to the specification, and build some
tests?
Actually, I’d forgotten that the page range formatting code is a
little more sophisticated than that. “Number” for this purpose seems
to include any string that ends in a numeral. Same general logic
applies, though; we could reformat everything in a page-labeled
string, accounting for delimiter cruft, up to the first non-number.
I saw Frank already changed some styles. Not all, though. I’m
attaching a patch (I’m not able to push to bitbucket.org even though I
seem to have commit access).
Andrea
enDash.patch (1.88 KB)
I’d say yes, we should consistently use en-dashes for all numeric ranges.
I saw Frank already changed some styles. Not all, though. I’m
attaching a patch (I’m not able to push to bitbucket.org even though I
seem to have commit access).
The CSL in these tests doesn’t set page-range-format. I wasn’t sure
how cases like that should be handled (and I was lazy and didn’t look
further). While puzzling over it just now, I checked the
specification, and apparently they’re supposed to be left as is:
If that’s not the right treatment, I guess now is a good time to work
out how they should be handled. It does seem like a good idea to have
a literal option, though, in case automated reformatting causes
headaches under particular conditions.
You are perfectly right indeed. This is my fault.
Andrea
(obviously forget the patch and bless the fact I don’t have write
access to the test suite. keep it this way, please!)