[citeproc bug] punctuation in quotes
If punctuation is set as a prefix in a macro, it doesn't get pushed into the preceding quotation marks.
Example using chicago-author-date
Is:
Chwieroth, Jeffrey M., H. Street, A. M. Hicks, and D. Pinheiro. 2007. “The Institutional Construction of Neoliberal Economic Globalization: The Case of Capital Market Liberalization in Latin America”. Paper presented at the 3rd annual meeting of the International Political Economy Society, Philadelphia, PA.
Should be:
Chwieroth, Jeffrey M., H. Street, A. M. Hicks, and D. Pinheiro. 2007. “The Institutional Construction of Neoliberal Economic Globalization: The Case of Capital Market Liberalization in Latin America.” Paper presented at the 3rd annual meeting of the International Political Economy Society, Philadelphia, PA.
(note the placement of the period at the end of the title.
citation data as RDF:
https://gist.github.com/adam3smith/8f6557c7eb55f034223c
@fbennett - I do realize that this can be prevented in styles, but it would be a huge relief to get this fixed, otherwise we need separate macros every time this comes up
edit: this is obviously on a computer with an en-US default-locale
Example using chicago-author-date
Is:
Chwieroth, Jeffrey M., H. Street, A. M. Hicks, and D. Pinheiro. 2007. “The Institutional Construction of Neoliberal Economic Globalization: The Case of Capital Market Liberalization in Latin America”. Paper presented at the 3rd annual meeting of the International Political Economy Society, Philadelphia, PA.
Should be:
Chwieroth, Jeffrey M., H. Street, A. M. Hicks, and D. Pinheiro. 2007. “The Institutional Construction of Neoliberal Economic Globalization: The Case of Capital Market Liberalization in Latin America.” Paper presented at the 3rd annual meeting of the International Political Economy Society, Philadelphia, PA.
(note the placement of the period at the end of the title.
citation data as RDF:
https://gist.github.com/adam3smith/8f6557c7eb55f034223c
@fbennett - I do realize that this can be prevented in styles, but it would be a huge relief to get this fixed, otherwise we need separate macros every time this comes up
edit: this is obviously on a computer with an en-US default-locale
<layout>
<text macro="the-title" quotes="true"/>
<text macro="the-publisher" prefix=". "/>
</layout>
As output, this yields:
"My Title." My Publisher
The problem arises when the affix is separated from the quotes by one or more levels of nesting:
<layout>
<text macro="the-title" quotes="true"/>
<group>
<text macro="the-publisher" prefix=". "/>
</group>
</layout>
This yields:
"My Title". My Publisher
I'll take another look, but in the worst case this will need reimplementation of the output method in the processor. If that proves necessary (if), I'm not sure when it can happen.
Could you let me know if this turns out to be very difficult and long-term? I'll try tinkering with the style, then.
The code that handles punctuation adjustments and quote swapping is decidedly awful. I tried several approaches to covering this case this morning, and only succeeded in breaking things horribly.
So yes, this particular headache is going to be with us for the foreseeable future.
The full stop after "1830" is now falling inside the quotes, with a Chicago style in the en-US locale. It used to fall outside:
Not sure if titles ending in a number are meant to be treated differently. Is the new behaviour correct?
The comma after the question mark is suppressed by the new code. It used to render:
We could discriminate in the suppression of the comma between styles that place it inside the quotes, and those that place it outside. Or we could preserve the behaviour of always including it when it appears against a question mark.
<text variable="title" quotes="true" suffix="."/>
The test input is the following:
This is 'The One'
This this CSL and input, and with punctuation-in-quote set to true, the new code is producing the following output:
In the current processor, the punctuation migrates into the inner quotes:
It's an edge case, but which behaviour is more correct?
unfortunately, for the next example, the old behavior is correct: we had that discussion recently, I believe that's a change in Chicago's 16th edition, see CMoS 14.105
Same for the 3rd example: is correct without doubt, see CMoS 6.11
[2] Doe, “His Anonymous Life”; Roe, “Her Anonymous Life.”
They now fall inside:
[2] Doe, “His Anonymous Life”; Roe, “Her Anonymous Life.”
Would I be right that the new behaviour is correct?
Small steps, but should be ready for testing pretty soon.
The new version is producing this:
It's been set up to avoid migrating punctuation across a style boundary, so it balks at the italics. For a period, this isn't a bit deal, but it would be cleaner to stick with that general rule, and handle anomalies like this by adjusting the CSL. Will that be okay?
If that's the price we have to pay, I'd say that's OK, but the anomalies that are going to occur are going to be item-specific, not style specific.
Concretely, the issue is going to be almost exclusively
Doe. Book Title “with a quote at the end.” 1900.
If I understand the logic correctly, the probably more common
Doe. “Article Title Ending with Foreign Term.” 1900.
would be OK, right?
I'm pretty sure that books titles ending in quotation marks are exceedingly rare, so, again, I'd be OK going ahead with this, though if its an easy fix the old version is correct.
If migration is permitted, the format of punctuation will shift depending on the field content:
The effect will be more or less visible depending on the font applied.
The first example above (normal typeface) seems correct to me; but if we block on all styling boundaries, migration will fail in the other example. With migration blocked, it looks like this:
With migration allowed, it would look like this:
To my eye, the first example (with blocking) sets off the title more clearly. On the other hand, it does look like Chicago does apply a consistent rule that all punctuation must fall inside adjacent quotation marks, will-ye nil-ye; and my own judgement could be affected by exposure to programming -- I see the commas here as structural markup, and it looks better to me if they are consistently formatted.
Anyway, it's your call. We can run with the first example in each pair, or with the second. (Other combinations would be difficult to implement, since some of the logical structure of the citation elements has been lost when the punctuation adjustment takes place.)
In the second case, yes, the first example is unfortunately incorrect. Let me think about this. you'll be happy to learn that Chicago has separate comma rules for computer code (seriously! there's a reason I'm so fond of the manual) for exactly that reason.
Should a comma following a title that is set in italics also be italicized?
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
The only exception to the general rule that punctuation does not cross a style boundary would be in (6).
We can make that happen by drilling down the trailing children of a styled node, and triggering an exception if a quotes attribute is found among them. Field content (including quoted spans) is expressed in node form at this point of processing, so that should provide a general solution (within citeproc-js).
Will that be okay?
Yes, these are all exactly right, that's wonderful.
It should produce results like those highlighted in green in this thread, pretty much regardless of the underlying structure of the style CSL. The code for punctuation and space duplicate suppression, terminal punctuation merging and quote swapping has been completely rewritten, so there may be some glitches; but the processor passes all but three of the 990 fixtures in the test suite (the failures being minor things that were failing before the rewrite, for separate reasons).
Let's hope it works. :)