Space after first field in plain-text mode when using `second-field-align`

CSL Development
1

A Zotero user reported that, when pasting an IEEE reference into a plain-text editor, there’s no space after the citation number, resulting in "[1]Author" instead of "[1] Author".

I initially suggested we’d just need to add a space to the suffix="]" in the IEEE style, which would be ignored in HTML output due to whitespace collapsing. It then occurred to me that a more general fix would be to have the citation processor automatically add a space after the first field in plain-text output when second-field-align is used, rather than needing to hard-code a space in all similar styles. @Sebastian_Karcher agreed with the latter approach and suggested that a hard-coded space could cause problems with RTF/etc.

Somebody quickly submitted a patch that adopted the second approach. Unfortunately, in testing it, I found that, while it fixes the problem in IEEE and Nature, three other bundled Zotero styles — American Chemical Society, American Medical Association, and Vancouver — already hard-code a space after the citation number, so the patch would result in two spaces for those styles.

So we have two options:

  1. Hard-code spaces in the citation-number suffixes in IEEE, Nature, and any other similar styles to bring them in line with ACS, AMA, and Vancouver.

  2. Define the expected processor behavior here to be that a space is automatically added after the first field in plain-text mode when second-field-align is used, and then remove the space in ACS, AMA, Vancouver, and any other styles that do that.

(2) is arguably the more elegant option, but (1) is far easier, and since some styles already do (1) I’d be inclined to just go with that. But I don’t know what processors other than citeproc-js do here, nor have I tested the RTF output of the styles that hard-code a space to see what the effect is there.

2

Another drawback of the hard-coded space is that it makes the maxoffset parameter of citeproc-js's makeBibliography() increased by 1. This may cause the client unable to calculate the indentation length consistently.

3

Any other thoughts on this?

One way or another, the official CSL styles should be made consistent: either the hard-coded space should be removed from ACS/AMA/Vancouver (in which case we’ll patch our citeproc-js and submit a patch upstream) or the space should be added to IEEE/Nature.

(It also occurs to me that the amount of spacing after the number in plain-text output is probably arbitrary — I assume a single space is the convention but I’m not sure any of the guides actually specify exact spacing for plain-text output — so Zotero patching citeproc-js to add a space now, even before the hard-coded space is removed from ACS/AMA/Vancouver, wouldn’t really be a huge problem. Those styles would just temporarily have two spaces instead of one in plain-text mode.)

4

The type of issues that zepinglee points to are exactly what I’m worried about with hardcoding the space. I think we should just go ahead adding this in citeproc-js (and -rs), i.e. option 2. As you say, having a double space in plain text isn’t a huge deal (since it’s usually a tab), though in the long run we should try to have styles behave consistently, i.e. try to gradually fix this in the existing styles.