Actually, I can't seem to reproduce this failure in the test suite. There is a fixture on file, magic_StripPeriodsTrue.txt, which has been passing for the past five months or so (most recently a few minutes ago). I've added another, magic_StripPeriodsTrueShortForm.txt, to be sure that the form="short" attribute isn't interfering. But it seems okay.

Not sure where to start. What's your environment, what is the style, and what exact input string is leaving periods in place on you?

(Edit: As a side note, the cs:text node will not produce any output for variable "author", at least in citeproc-js/Zotero 2.1. Name variables must be rendered with cs:names.)

Aha. As my note says, strip-periods was newly introduced in CSL 1.0. Zotero version 2.1 is the first to use CSL 1.0.

Zotero 2.0.9 uses CSL 0.8.1, so strip-periods is not available there (and if you validate the style, validation will fail).

Thanks for the report. Will check this later today. (What is probably happening, off the top of my head, is that duplicate punctuation is being suppressed on the attribute, before strip-periods is applied. If that combination was missed in our tests, the code could be failing in that way. Shouldn't be hard to fix, but may take a little time to percolate through to a Zotero release.)

Thanks for the reminder; this had indeed slipped past. I've taken your sample code above, and refashioned it as a small valid CSL 1.0 style (the validator says that strip-periods is not allowed on the cs:name node, so I left that bit out).

Running against some sample input, with bare periods inserted at various locations in the style file, I get this output:Jane Roe.Journ Title.Jane Roe.Journ Title.
... where a period has been stripped from "Journ.", and the other periods are supplied by delimiters or suffix elements.

So the processor looks okay on this; and it's very unlikely that anything in Zotero could change the behavior. If it's not working in your installation, the most likely cause would seem to be invalid CSL, which can have unintended side effects. If you can post a style to gist/github, I'll be happy to give it a try in Zotero to see if the faulty output can be reproduced there.

http://gist.github.com/

(Edit: Just in case, note that the construct <suffix=".">, mentioned in your post above, is not valid, and will either produce an error, or no output at all.)

Yay, that's great to hear -- and glad to know that it's working for you!

I raised this issue with fbennett in early May. He mentioned he would correct this, but I don't know if the fix has already made it into citeproc-js and Zotero. You're running Zotero 2.1.7?

Just guessing, but the issue raised by Rintze was probably a similar issue with initialize-with~" ", which now works correctly. The strip-periods attribute is not allowed on the cs:name node in the CSL 1.0 schema.

I can see that it's useful there (to preserve names but drop periods from initials set in the source of the entry). But the CSL specification will need to be amended to allow it.

We probably shouldn't allow that one either. :)

Seriously, though, it's a little more complicated under the hood than it looks on the surface. Here's a more-or-less full rundown.

The most obvious problem is that, if the processor is extended to wrap content in hyperlinks, a clobber-periods function executed against the rendered string output of the macro (which is really the only feasible way for the processor to handle that construct) would clobber the periods in the URL as well. Ouch.

Even if we assume we'll code around that when it becomes an issue, there is a problem with determining exactly how the periods should be removed. In the general-purpose strip-periods function, we currently preserve space -- and replace the period with a space if it is mid-string. So "Env. L.J." becomes "Env L J". This is where the extraneous space is coming from; the processor is seeing the abbreviation mid-string, so it is forcing in a space. Culling spaces that are followed by punctuation is not practicable when working against rendered string content -- the given-name initial could be followed immediately by a closing tag for small-caps, say, with the space falling after. Parsing around such markup is something that we just don't do.

A cleaner approach would be for us to ban strip-periods on text nodes that call a macro, and allow it on name-part nodes (where it is currently banned). Then you would be legally entitled to do this:<names variable="author">
<name>
<name-part name="given" strip-periods="true"/>
</name>
</names>In fact this will actually work right now, producing the result you're after without any modifications to Zotero or the processor. The only problem is that it won't validate against the CSL 1.0 schema. :(

I'll raise this over in CSL-land and see where the discussion leads us.

At the moment, I reckon that the chances of it will becoming valid in the reasonably near future are pretty good. There is always a risk of the person closest to the code being blinkered by implementation details, though, and I've certainly had that experience in the past. We'll have a discussion, and see what emerges.

@liam.mchugh.russell,

I'm bundling up some changes for a new processor release. Looking at this strip-periods issue, and after running the tests in a couple of configurations, I've concluded that you're right: strip-periods should do just that, without attempting to insert any sort of placeholder.

When the revised processor comes through in a new release, we'll see whether the change elicits any cries of dismay. If not, we'll be good with Hein Online, and your original coding would, I think, also work.

You need the next release (after Zotero 2.1.8).

There's another problem which seems to be caused by strip-periods. Here's a summary of the offending code, taken from mcgill-guide-v7:

<group delimiter=". ">
<text macro="author-bib" strip-periods="true"/>
<text macro="render-book"/>
</group>
<macro name="author-bib">
<names variable="author">
<name name-as-sort-order="first" and="symbol" sort-separator=", " delimiter-precedes-last="never"/>
<et-al term="et-al"/>
<label form="short" prefix=", "/>
<substitute>
<names variable="editor"/>
</substitute>
</names>
</macro>

When this is passed one or more authors, it works fine. When there are no authors, but only one or more editors, it fails to render the intermediary period. When the strip-periods is removed, the intermediary period returns for both cases (though obviously, with unwanted periods in the authors names left intact).

I've added a test case to the CSL Test Submission group using fbennett's csl feedback plugin which replicates this problem from Zotero 2.1.8, which I am using. I know that certain changes to the processor which impact the implementation of strip-periods will be made in a future release, but I thought that it was important to identify this now, lest it should remain despite those changes.

Liam,

Thanks for raising this. I'll take a look in the next couple of days.

I am getting some very odd behaviour as a result of strip-periods again. Here is some code adapted from mcgill-guide-v7.csl:

<macro name="author-note">
<names variable="author">
<name and="symbol" delimiter-precedes-last="never"/>
<et-al term="et-al"/>
</names>
</macro>
<citation et-al-min="4" et-al-use-first="1">
<layout delimiter="; " suffix=".">
<text variable="URL" />
<text macro="author-note" strip-periods="true"/>
<text variable="title" quotes="true" suffix=","/>
</layout>
</citation>
<bibliography et-al-min="4" et-al-use-first="1">
<sort>
<key variable="issued"/>
</sort>
<layout>
<text variable="URL" />
</layout>
</bibliography>
</style>

For some reason, this strips periods from the URL and title as well as the author's name. When the call to the author-note macro is removed, the problem disappears. I am using the latest version of Zotero; I've reproduced this problem both in the test pane and the word plugin. I had originally thought that this was limited to the URL variable and had something to do with the "Include URLs..." option but no such luck. It seems to affect all variables. And what is most odd is:

1. It strips periods from the rendering of other variables whether the call to author-note macro comes before or after the rendering of other variables.
2. It appears to strip periods from the rendering of variables in the bibliography, even if the call to author-note is only made in the citation portion of the style!