edition with superscript

Mario Jose

Hi all,

how can I do, if is possible, make style for "edition" with abbreviation, like st, nd, rd or th appear superscripted (only abbreviation). When I set this,

<number variable="edition" form="ordinal" vertical-align="sup" />"

number and abbreviation appear superscripted.
I do this in "terms" section:

<term name="ordinal-01" >st</term>
<term name="ordinal-02" >nd</term>
<term name="ordinal-03" >rd</term>
<term name="ordinal-03" >th</term>

<number variable="edition" form="text" />
<number variable="edition" form="ordinal" vertical-align="sup" />

or

<text variable="edition" />
<number variable="edition" form="ordinal" vertical-align="sup" />

but don't work. Appear like: 2^2nd. I would like this: 2^nd.

Thanks,

Mario

Gracile

Try this:
<!-- ORDINALS -->
<term name="ordinal-01">&amp;lt;sup&amp;gt;st&amp;lt;/sup&amp;gt;</term>
<term name="ordinal-02">&amp;lt;sup&amp;gt;nd&amp;lt;/sup&amp;gt;</term>
<term name="ordinal-03">&amp;lt;sup&amp;gt;th&amp;lt;/sup&amp;gt;</term>
<term name="ordinal-04">&amp;lt;sup&amp;gt;th&amp;lt;/sup&amp;gt;</term>


Mario Jose

Hi Gracile,

don't work. In my text appear: 2^nd

Hugs,

Mario

Gracile

Are you using zotero 2.1?
Did you try in the Zotero Reference Test pane or/and MS Word or/and Ooo?
Same issue here.

Mario Jose

Yes, I using zotero 2.1.6.

I try do this in Word. I do several codes do work this, but any one work.

Mario

Gracile

Indeed, I can confirm that with 2.1.6 and MS-Word.

That's strange because this has worked in zotero 2.1 beta2 (cf. my post in Nov. 2010).
Could the devs have a look on that? Thanks.

Gracile

I should add that this works well (for me) in the Zotero (2.1.6) Reference Test Pane. The issue affects (at least) MS-Word 2002. I did not try with Ooo (but Mario Jose had).

(Firefox 3.6.17, Zotero WinWord Integration 3.1)

Mario Jose

Hi,

my file is like this:

<?xml version="1.0" encoding="UTF-8"?>
<style xmlns="http://purl.org/net/xbiblio/csl" version="1.0" class="in-text" default-locale="pt-BR">

...

<locale xml:lang="pt-BR">
<terms>

Term ordinal Like Gracile cite above

</terms>
</locale>

...

<macro name="edition">
<choose>
<if type="book chapter" match="any">
<choose>
<if is-numeric="edition">
<group delimiter=" ">
<number variable="edition" form="ordinal" />
<text term="edition" form="short" suffix="." prefix=" " />
</group>
</if>
<else>
<text variable="edition" suffix=" ed."/>
</else>
</choose>
</if>
</choose>
</macro>

...

In Word, my text is like this:

LEGENDRE, P. & LEGENDRE, L. 1998. Numerical ecology. 2^nd ed., Amsterdam; New York: Elsevier.

I use Firefox 4.0.1, Zotero 2.1.6, Zotero WinWord Integration 3.1, Word 2007, WinXPSP3.

I don't know why don't work here.

Hugs,

Mario

bdarcus

Just to be clear, the proposed solution suggested by Gracile (adding escaped HTML code to the localized term definitions) is not the way to solve this issue. CSL doesn't support this level of detail, and it's not clear to me it should.

Gracile

@bruce:
I'm not sure to understand. Do you mean that CSL should not manage that? Or that escaping html should not be a solution?

Superscripting locales terms is a big need (not only for "edition", see locales-fr-FR for other examples: issue, folio...) and whatever the final solution, that would be great to let CSL proc handles this as a temporary workaround (as it was before - even unintentionally ;-)).

bdarcus

I'm not sure to understand. Do you mean that CSL should not manage that? Or that escaping html should not be a solution?

Both.

Escaped content should not be used anywhere in a style, and if the explicit unescaped markup isn't valid, then that simply means CSL doesn't do what you're asking it to do.

As for this case, is there any reason superscripting couldn't be handled by the processor (citeproc-js), or the application (Zotero)? Why does this have to be in CSL itself?

If there's a clear reason it needs to be in CSL, then the solution would probably be to allow the formatting attributes on the locale term.

<term name="ordinal-01" vertical-align="sup">st</term>

ajlyon

Superscripted terms are a perfectly reasonable need-- superscripts may be relatively uncommon and unimportant in American styles, but Gracile has provided many examples of why they matter for French styles-- this is a reasonable and common case that is at least as important as boldface.

ajlyon

Adding vertical-align to terms doesn't address Gracile's need for French terms: http://forums.zotero.org/discussion/15085/1/french-localization-csl-10/#Item_35

<term name="issue" form="short">
<single>n<sup>o</sup></single>
<multiple>n<sup>os</sup></multiple>
</term>

Not sure the best way to proceed, but this is the way the styles require it.

Rintze

The CSL processor will have to parse these HTML-like tags anyway, so requiring that it also parses the tags when they occur in term definitions (or in the value of "value" in cs:text) doesn't seem that awkward.

Mario Jose

Hi,

I try do this:

<term name="ordinal-01" vertical-align="sup">st</term>

and don't work too.

I try:

<term name="ordinal-01"><text value="st" vertical-align="sup" /></term>

and don't work too. When I do this, all tag appear in my text.

Mario

FHeimburger

Glad this has come up - I got around the ordinal "o"s for the numbers of a collection in French by using the special character codes from here http://www.webmonkey.com/2010/02/special_characters/ - so that gives me nº
... but that still leaves me needing superscripts "e"s at least - and they don't have specific codes as far as I can find

bdarcus

@Mario - as I said, this WILL NOT work now. We're discussing future possibilities.

As for those of you thinking this is reasonable, what happens when the mathematicians want inline MathML?

In any case, I'd suggest someone creating an issue, with detailed justification (including why this needs to be done in CSL, and not somewhere else; why it can't be done using unicode, etc.), over at https://github.com/citation-style-language/schema. Remember that I
'm pretty much a standards purist, so if we really to consider something like this, then it needs to be a really clean subset of actual HTML; not some "HTML-like" thing.

Gracile

@bruce: I fully agree with you on standards but that's standard HTML? I'd be happy to create an issue on csl's github and to contribute but I've already give reasons and examples of citations.

Your concern seems to be the question whether this should be handled by csl or by citeproc-js. I think I've a more precise understanding of the different elements at stake here(csl/citeproc/zotero UI, etc.) than "simple" users but I don't understand here what is tied to citeproc-js and what is tied to csl: where's the border? Since that is treated, transparently for the final user, in "locales-fr-FR.xml"...
[Rich text markup in zotero fields seems to me much more problematic (for accessibility, etc...) than the handling of html in locales-xx-XX.xml, those files which are modified by 0.01% of zotero users and are fairly stable.]
I'd just add that because that has worked well before (z. 2.1b2), this seems like a regression today.

In a nuthsell: what does mean "and not somewhere else".

Thanks.

fbennett

With some scratching around I've stumbled across a nice list of superscripted equivalents, which may cover many use cases.

bdarcus

@gracile - well, consider that a word-processor like Word or OOo can be setup to automatically superscript certain combinations of words, like in English "th." So one could say it might be good to let be handled "somewhere else." I think it belongs in CSL if a) it's clearly specific to citation styling (so in this case, superscripting of these terms are likely to vary by style, and can't be handled in citeproc-js or Word/OOo), and b) the use cases cannot be reasonably covered at some other point in the chain.

ajlyon

These clearly vary by language. CSL is going to need awareness of the language of a citation soon enough, since language-sensitive terms usage is not uncommon (certainly in Russian styles, I think in Japanese as well, and hard to imagine not being the case in Hebrew and Arabic). Only at the level of the citation processor do we have the knowledge required to do this right-- there is no way the word processor knows which languages and styles have requirements like this, and there's no way citeproc-js would know about such requirements if they aren't expressed in CSL.

I can see the argument that Unicode is a better way to handle this, but Unicode doesn't provide complete coverage of superscript characters. I don't see the argument that this isn't CSL's job. How can you expect CSL processors to work autonomously in a space like citeproc-node without providing them with all the style information necessary for complete formatting?

fbennett

@ajlyon,

Common Japanese characters that might be used are covered in the list linked in my post above, but the unicode approach does have the problem of inflexiblity; it wouldn't be reasonable to put users to the task of securing an extension of the Unicode standard just to get a particular character to render in superscript inside a citation.

On that point, I don't see any Cyrillic characters in the list linked above. Are there Russian conventions for superscripting or subscripting of ordinal suffixes or other terms? If so, that would seem to be pretty strong evidence of a need for greater flexibility than offered by the unicode approach.

ajlyon

Mentioning Japanese and Cyrillic, I mean that we already should be planning on having the terms and possibly more in a citation depend on the language it's in. This isn't in CSL 1.0, and the discussion stalled at xbiblio, but it matters a lot for much of the world. Once you are in a position where different systems of ordinals and the like are in use in a single bibliography, there's approximately zero chance that the post-processing can have enough knowledge of typographic and bibliographic convention to apply superscripts appropriately. The information needed to handle the correctly exists at only one point in the bibliographic workflow-- in the citation processor. And the processor will only know the language-specific conventions if CSL lets them be expressed in the style files and locales.

I'm intentionally conflating a separate issue here, since the seemingly reasonable suggestion of leaving this to the word processor becomes unworkable once you make the behavior differ citation-by-citation, as it might well do in completely reasonable cases.

But Russian doesn't tend to use superscripts, so that bit is moot here.

Gracile

I agree with ajlyon's comment but I'd like to find a quick solution.

I tried to replace HTML "sup" by unicode in my style.Three problems/questions:

1) I'm not sure that this is orthodox. Imprimerie nationale recommends to apply superscripts in its Lexique des règles typographiques. The final output is different with unicode;

2) That does not work well in MS Word: I got exclamation marks (except for "o", "s" and "n" - but "n" is a normal "n", maybe because there is no "modified letter small n") (+ issues with typefaces);

3) This is a much more cumbersome solution than superscripts (for user).

My main concern is the second one. I'd like to test with Ooo/LibreOffice and last MS-Word version (mine is 2002) but I don't have it.

---
Memo:
1D52; 006F # ᵒ → o MODIFIER LETTER SMALL O → LATIN SMALL LETTER O
02E2; 0073 # ˢ → s MODIFIER LETTER SMALL S → LATIN SMALL LETTER S
02B3; 0072 # ʳ → r MODIFIER LETTER SMALL R → LATIN SMALL LETTER R
1D49; 0065 # ᵉ → e MODIFIER LETTER SMALL E → LATIN SMALL LETTER E
1D48; 0064 # ᵈ → d MODIFIER LETTER SMALL D → LATIN SMALL LETTER D
207F; 006E # ⁿ → n SUPERSCRIPT LATIN SMALL LETTER N → LATIN SMALL LETTER N

fbennett

That does not work well in MS Word: I got exclamation marks (except for "o", "s" and "n" - but "n" is a normal "n", maybe because there is no "modified letter small n") (+ issues with typefaces);

That's pretty much a show-stopper. Looks like we need a solution in markup.

fbennett

@Gracile,

Encoded rich text markup embedded in ordinal terms as in your example will render properly in the next version of citeproc-js, just released.

bdarcus

Encoded rich text markup embedded in ordinal terms as in your example will render properly in the next version of citeproc-js, just released.

Maybe I'm misunderstanding, but ...

The CSL schema does not support embedded "rich text markup" in terms.

And as I said, adding escaped markup per example above is also not supported.

So how can citeproc-js now support the use case without violating the spec?

Or are you talking about the unicode route (which isn't really "rich text")?

fbennett

@bdarcus,

[I]f we really do consider something like this, then it needs to be a really clean subset of actual HTML; not some "HTML-like" thing.

The embedded markup in Gracile's solution is that of the rich-text markup extension, mentioned in the CSL 1.0 upgrade notes, supported by citeproc-js and Andrea Rossato's citeproc-hs, with support under development for the Ruby engine of Sylvester Keil.

As for those of you thinking this is reasonable, what happens when the mathematicians want inline MathML?

In locale terms? Or are you objecting to this form of rich text markup more generally, in data input as well?

For support in native CSL for this particular use case, there is this proposal, posted to xbiblio-devel in 2009. (I'll open a ticket for it in the schema tracker shortly, in case it's still of interest.)

fbennett

I don't remember seeing anything in the CSL specification that specifically denies Gracile's markup, and it will validate. If the language of the specification is tightened to prohibit such markup, or to prohibit it from being rendered as Gracile expects, then I guess the processor would be in violation, yes.

fbennett

Or are you talking about the unicode route (which isn't really "rich text")?

No, there's no misunderstanding. We're talking about the same thing.

bdarcus

In locale terms? Or are you objecting to this form of rich text markup more generally, in data input as well?

The former.

I don't remember seeing anything in the CSL specification that specifically denies Gracile's markup, and it will validate. If the language of the specification is tightened to prohibit such markup, or to prohibit it from being rendered as Gracile expects, then I guess the processor would be in violation, yes.

This is one of those things I didn't think needed to be added. But given this thread, maybe I should.

Using escaped XML markup to get around design choices in an XML language is definitely not cool. If we need this functionality, then we should design it in.

Will take a look at the github issue and move discussion there.