Leading spaces for author/author-date-styles

Rintze

Depending on the citation style there either are or aren't any spaces between the actual citations and the text on which they follow. Just compare the Nature style which has superscript numbers (e.g. "as shown by Darwin1") with some generic author-date style (e.g. "as earlier shown (Darwin, 1834)").

When you already have written a manuscript with the Word plugin, but want to switch styles (from a style with these spaces to one without, or vice versa), you have to delete or insert all these spaces by hand. I recently circumvented this problem in Reference Manager by using an customized author-date style with a leading space before each citation (so the citation field shows as " (Darwin, 1834)" instead of "(Darwin, 1834)"). This allowed me to switch easily between different type of styles without having this problem.

My question was whether an option to provide such leading spaces in the citation field could be provided for those styles that require spacing. Perhaps it could be included as a preference in the Word/OO-plugins? It would require some logic to distinguish between the two types of styles: whether separating spaces are used could either be included as a parameter in CSL, or it could be deducted from the use of brackets (I can't recall having seen any bracketed non-superscripted styles that don't use separating spaces).

adamsmith

I would very much second that.
I guess this could be hard coded into the styles (i.e. use prefix=" (" ) but we'd have to hardcode this for all style + (and maybe more importantly) old documents would look wrong (though that might result from any solution we chose and since this could be fixed by search for "double space (" it might be OK.
Would be great if Bruce and Dan could chime in - this seems like it has easy solutions.

noksagt

Most styles that I've written have been numeric. In most of these, the numbers are either superscripted with no separation or have a single space and the number in brackets. I've encoded the space in the latter styles because it allows me to more easily use a non-breaking space (which is preferred to keep the citation close to the material you're trying to cite) & switch between styles.

I don't know if I see "broken" older documents as a compelling reason not to encode spaces into the style. As adamsmith points out, the fix is easy.

bdarcus

Not really sure how the current Zotero code or Frank's update handles this, but perhaps we should a) have style authors add the preceding whitespace character to the citation where appropriate (as in author-date styles), and b) add some language to the CSL spec to make this explicit (e.g. no black magic)?

fbennett

The new processor currently just returns the cite as defined in CSL. This seems like something that would be handled in the plugin?

Rintze

So is there consensus that:
- CSL already can handle this (the leading space can just be added as a prefix to the layout element in cs:citation)
- all CSL styles written for styles that use leading spaces should eventually contain these leading spaces, so that authors can easily switch between numeric and author-date styles
- that for the transition, it would be very helpful if it were possible to have a preference in the word processor plugins to remove leading-spaces from cites. I'm not sure if the spaces can easily be stripped by the plugin itself, or that this should happen in citeproc-js (in which case the plugin should send a hint to citeproc if space-stripping should be applied)
?

All that seems to be needed is commitment from the plugin developers (Simon, Dan) that the preference will be included? Once it has been included, we can start changing existing styles.

bdarcus

Thinking about this some more, this is tricky.

I would probably personally want my software to adjust the spacing as appropriate. I, for example, almost always use author-date styles, but sometimes need to use note styles. It would seem strange to author my documents if I was using something like markdown without a separating whitespace character.

Is it possible to make any generalizations about the expected behavior here, like only superscript markers (including footnote markers) might not have separating whitespace? Perhaps we should simply include a note about this in the CSL spec, but otherwise leave it alone?

Rintze

It would seem strange to author my documents if I was using something like markdown without a separating whitespace character.

For those parsers that work with plain text (Pandoc/citeproc-hs, RTF-scan), it might make sense to remove any leading spaces from the reference links. I don't know how this is currently handled, but I'd think that:
"As discussed before [Rossato2006], " and "As discussed before[Rossato2006], " should both yield the same result, e.g.:
"As discussed before², " or "As discussed before (Rossato, 2006), ", depending on the style.
(reference links as used at http://code.haskell.org/citeproc-hs/#using-citeproc-hs-with-pandoc)

Is it possible to make any generalizations about the expected behavior here, like only superscript markers (including footnote markers) might not have separating whitespace?

I think you can remove the "might". But what would you want to do with this generalization?

Perhaps we should simply include a note about this in the CSL spec, but otherwise leave it alone?

What would the note contain?

fbennett

In the short term, encoding spaces into styles that need them should do no harm; outer spaces can easily be stripped if another mechanism is adopted later on.

Short thought: Why not go ahead and include explicit spaces in author-date styles now, and just state in documentation that a citation string _without_ a leading space "should be handled by the calling application in a way that produces an appropriate amount of non-breaking space between the citation and the text to the left of it". Then applications that ignore the guidance note will produce something like correct output, and those that follow it will produce something better. (If I'm grasping the use cases correctly here.)

Longer thought:

Over the longer term, this is probably not something that CSL should be used to control directly, because CSL does not control the wrappers that an application puts around the strings sent back to the calling application. Some document processing systems might have a container type for number-marks that does the right thing with spacing, others might not. The spacing decision should be left to middleware (the plugin, in Zotero, and the relevant document processing modules, in Pandoc, reStructuredText, Red Cloth, etc.) that is specifically designed for the target document environment and can make the necessary adjustments.

Ignoring CSL-provided spacing (in the long-term solution) would also help protect the generality of styles. As noksagt points out, in a numeric style, the mark (the number) and text to the left of it should be separated by a non-breaking space. There are three of those: the plain vanilla non-breaking space (U+00A0), the non-breaking thin space (U+202F) and the word joiner (U+2060). If publishers vary in their choices for typesetting reasons, we wouldn't want that alone to force the deployment of additional versions of a style.

(Both of these considerations could be seen to affect note styles as well as numeric styles; there are similar issues around the spacing between the footnote mark and the text to the left of it.)