csl processor bug - second field align
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).
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).
This is an old discussion that has not been active in a long time. Instead of commenting here, you should start a new discussion. If you think the content of this discussion is still relevant, you can link to it from your new discussion.
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.