I have noticed that many test cases seem to assume an implicit ‘strip-periods’ on label tags. For example, in ‘name_SubstituteInheritLabel’ there is the following label and expected output:
" (ed.)"
I have three questions about this:
1.) are affixes generally applied after other style attributes (the tags are inside the parentheses)
2.) are periods implicitly stripped? Note that there is a period in the suffix and also in the default short form of the locale term for editor, but only one period in the output.
3.) furthermore, it is not clear to me which of the two periods was stripped, because of 1.) I would have assumed the period to be outside the tag if it were the period specified in the suffix; on the other hand, because of 2.) I would assume the period specified in the locale to have been stripped.
Could anyone explain this to me?
Thanks!
Sylvester
i think Frank (or perhaps Andrea) will have to explain this. This
question also reminds me of this long thread on whitespace-handling
that we never resolved AFAIK:
http://xbiblio-devel.2463403.n2.nabble.com/how-much-bugged-a-style-may-be-td5784767.html
Bruce
“Bruce D’Arcus” <@Bruce_D_Arcus1> writes:
I have noticed that many test cases seem to assume an implicit ‘strip-periods’ on label tags. For example, in ‘name_SubstituteInheritLabel’ there is the following label and expected output:
" (ed.)"
I have three questions about this:
1.) are affixes generally applied after other style attributes (the
tags are inside the parentheses)
«Affixes are generally insensitive to the formatting attributes acting
on the calling element: the only exception to this rule are affixes set
on cs:layout. In cases where formatting of affixes is desired, separate
cs:text elements can be used instead, with a value attribute to output
verbatim text.»
http://citationstyles.org/downloads/specification.html#affixes
2.) are periods implicitly stripped? Note that there is a period in
the suffix and also in the default short form of the locale term for
editor, but only one period in the output.
Yes, we decided (but there is no mention of that in the specification)
that processors should avoid a duplicate punctuation when applying a
suffix (or a delimiter, if I remember correctlly).
3.) furthermore, it is not clear to me which of the two periods was
stripped, because of 1.) I would have assumed the period to be
outside the tag if it were the period specified in the suffix; on
the other hand, because of 2.) I would assume the period specified in
the locale to have been stripped.
In citeproc-hs it is the suffix’s punctuation which would get removed.
i think Frank (or perhaps Andrea) will have to explain this. This
question also reminds me of this long thread on whitespace-handling
that we never resolved AFAIK:
http://xbiblio-devel.2463403.n2.nabble.com/how-much-bugged-a-style-may-be-td5784767.html
It is true that this somehow related to that. Whitespaces are in fact
treated as a form of punctuation, indeed.
Andrea,
thanks a lot for this! I’ll follow citeproc-hs’ example and remove the superfluous punctuation in the suffix in this case.
Best,
Sylvester
PGP.sig (195 Bytes)
“Bruce D’Arcus” <@Bruce_D_Arcus1> writes:
I have noticed that many test cases seem to assume an implicit ‘strip-periods’ on label tags. For example, in ‘name_SubstituteInheritLabel’ there is the following label and expected output:
" (ed.)"
I have three questions about this:
1.) are affixes generally applied after other style attributes (the
tags are inside the parentheses)
«Affixes are generally insensitive to the formatting attributes acting
on the calling element: the only exception to this rule are affixes set
on cs:layout. In cases where formatting of affixes is desired, separate
cs:text elements can be used instead, with a value attribute to output
verbatim text.»
Redirecting…
2.) are periods implicitly stripped? Note that there is a period in
the suffix and also in the default short form of the locale term for
editor, but only one period in the output.
Yes, we decided (but there is no mention of that in the specification)
that processors should avoid a duplicate punctuation when applying a
suffix (or a delimiter, if I remember correctlly).
3.) furthermore, it is not clear to me which of the two periods was
stripped, because of 1.) I would have assumed the period to be
outside the tag if it were the period specified in the suffix; on
the other hand, because of 2.) I would assume the period specified in
the locale to have been stripped.
In citeproc-hs it is the suffix’s punctuation which would get removed.
I’m late to the party, but the same is true of citeproc-js; we try
pretty hard not to touch field content, outside of rich text
processing.