Formatting attributes and hyphen

1

Another rather finicky test question, I’m afraid.

bugreports_NumberInMacroWithVerticalAlign has the following input:

[
    {
        "edition": "2", 
        "id": "ITEM-1", 
        "title": "His Anonymous Life", 
        "type": "book"
    }, 
    {
        "edition": "3-5", 
        "id": "ITEM-2", 
        "title": "His Anonymous Life", 
        "type": "book"
    }
]

It has a nice simple csl. So far as is relevant:

 <macro name="edition-mac">
    <number variable="edition" font-style="italic"/>
  </macro>
  <citation>
    <layout delimiter="; ">
      <text macro="edition-mac" vertical-align="sup"/>
    </layout>
  </citation>

The expected result is:

<sup><i>2</i></sup>; <sup><i>3</i>–<i>5</i></sup>

I don’t quite understand this. I realise that because edition is a number field, and the entry here is numeric, it is correct for the processor to “sanitize” the hyphen, stripping off any spaces etc (though in fact there’s nothing to be done here). But citeproc-js seems to assume that the formatting attribute set on number should be applied only to the numbers, not to any hyphens etc (which is why it applies it only to the figures). If that’s what it means, I don’t think the specification says so: it simply says that

cs:number may carry affixes, display, formatting and text-case attributes.

Of course a prefix or suffix would be outside the scope of the formatting attributes: but the hyphen here is not a prefix, or a suffix. It’s not even, strictly speaking, a delimiter (though as I read the spec delimiters should get formatting attributes: though I daresay I may find as I work through the tests that I’m wrong about that).

In this particular case, I highly doubt that it makes any difference, since nobody could tell the difference between 3-5 3-5 (though the spacing may well be “out” in the latter case). But if it were 3-5 vs 3-5 it would be noticeable, and to my mind the latter is questionable. It would be still odder if one imagined things the other way round, with the formatting as superscript, where 3-5 looks dowright odd, compared to 3-5.

Is citeproc-js’s behaviour here compulsory? Right?

2

The boldface example is a good one. I think the result expected by the test is desirable for flexibility, although I’ll defer to others on whether it fits the specification: a style could apply boldface across the whole string by applying font-weight="bold" to an enclosing cs:group element.

(Edit: Group styling does indeed apply to delimiters set on the same cs:group element.)

3

I think Paul is right for the scenario in the test. If the hyphen is part of the variable, it should be part of the styling of that variable. The current behavior is counter-intiuitive (it’s also exceedingly rare – I doubt this has ever come up outside of tests).

Just to be clear, though, if the hyphen is generated by CSL behavior, such as e.g. collapse="citation-number" that’s a different situation and I would argue that in that case it should not be affected by styling on the variable, but should be affected by styling at a higher level (pretty sure that is the current behavior).

4

Sounds good! Fixed in citeproc-js and in tests.

5

Perfect. Thanks. Sebastian’s instincts do make sense to mem thoughI agree it’s not likely to occur often in practice. Blame the tests for doing what they are supposed to do!

6

Exactly what they are for! If you come across any CSL-M artifacts in the CSL test set, I can move them to the processor repo. I did a cleanup quite a while ago, but there may still be some slackers in there.