csl processor bug - second field align

adamsmith

See here:
http://forums.zotero.org/discussion/18669/please-post-update-to-advances-in-complex-systems-style-to-work-with-csl-1/#Item_7

second field align does not work correctly when the search key includes a date.
Examples - IEEE works correctly:

<bibliography et-al-min="7" et-al-use-first="1" entry-spacing="0" second-field-align="flush">
<layout suffix=".">

The following two also work fine:
<bibliography et-al-min="7" et-al-use-first="1" entry-spacing="0" second-field-align="flush">
<sort>
<key variable="issued"/>
</sort>
<layout suffix=".">

<bibliography et-al-min="7" et-al-use-first="1" entry-spacing="0" second-field-align="flush">
<sort>
<key macro="author"/>
</sort>
<layout suffix=".">

But this completely messes up formatting

<bibliography et-al-min="7" et-al-use-first="1" entry-spacing="0" second-field-align="flush">
<sort>
<key macro="issued"/>
</sort>
<layout suffix=".">

I can consistently replicate that in different styles with second-field-align="flush" and a macro that includes a date as a sort key (doesn't have to be the first sort key, either).

fbennett

Thanks for this report! Can confirm that this is utterly messed up.

Some special magic is invoked on macros that contain a date -- the processor extracts the date and uses that for the key, and leaves out anything else contained in the macro. That's unavoidable because date sort-keys are very different from the string representation (the key needs to provide a sorting hint on negative dates, and account for ranged date values).

Something inside the code that unpacks the macro is apparently doing a bad thing. I'll look into it today.

fbennett

@adamsmith: This has been fixed in processor release 1.0.188. Thanks again for calling attention to it.