Citation style

Mogliii · July 3, 2009, 6:42pm

Hi,

I am new to this mailinglist.

I sometimes use the IEEE citation style with Zotero. Currently it will
show multiple citations in text in the following form

[1,3-5,7] <<
but according to http://wwwlib.murdoch.edu.au/find/citation/ieee.html,
the citation should preferably look like
[1], [3]-[5], [7] <<,
which I already saw in some IEEE publications.

I already worked a bit with the xml files, but unfortunately there is
very little documentation about the available options to be used.

My first try was to

So each should be enclosed with square brackets, but apart from
that be handled as with the original. Also I removed the prefix and
suffix of the .

But this does not show any difference.

Any help appreciated.
Marek

Bruce_D_Arcus1 · July 3, 2009, 6:49pm

Hi,

I am new to this mailinglist.

I sometimes use the IEEE citation style with Zotero. Currently it will show
multiple citations in text in the following form

[1,3-5,7] <<
but according to http://wwwlib.murdoch.edu.au/find/citation/ieee.html, the
citation should preferably look like
[1], [3]-[5], [7] <<,
which I already saw in some IEEE publications.

Well, the doc says preferred, but that the other is acceptable as well.

I already worked a bit with the xml files, but unfortunately there is very
little documentation about the available options to be used.

Did you see this?

http://www.zotero.org/support/dev/csl_syntax_summary

My first try was to

So each should be enclosed with square brackets, but apart from that
be handled as with the original. Also I removed the prefix and suffix of the
.

Hmm … that should probably work (except I’d remove the “collapse” option).

Frank, do you agree?

Bruce

Frank_Bennett · July 3, 2009, 7:03pm

Hi,

I am new to this mailinglist.

I sometimes use the IEEE citation style with Zotero. Currently it will show
multiple citations in text in the following form

[1,3-5,7] <<
but according to http://wwwlib.murdoch.edu.au/find/citation/ieee.html, the
citation should preferably look like
[1], [3]-[5], [7] <<,
which I already saw in some IEEE publications.

Well, the doc says preferred, but that the other is acceptable as well.

I already worked a bit with the xml files, but unfortunately there is very
little documentation about the available options to be used.

Did you see this?

http://www.zotero.org/support/dev/csl_syntax_summary

My first try was to

So each should be enclosed with square brackets, but apart from that
be handled as with the original. Also I removed the prefix and suffix of the
.

Hmm … that should probably work (except I’d remove the “collapse” option).

Frank, do you agree?

I think the collapse option is needed there, to produce the [3]-[5]
span in the output. We use it in a similar case in the test suite:

http://bitbucket.org/fbennett/citeproc-js/src/tip/std/humans/collapse_CitationNumberRangesWithAffixes.txt

I’m not sure whether the current processor handles this one correctly
(tracking sequence numbers while preserving affixes and decorations
can get slippery). The new processor will do this for sure, though.

Mogliii · July 3, 2009, 9:45pm

Thank you for the help.

I had seen the help on the zotero page. But I think not everything is
explained. For example there is no list of all possible zotero items
(book, journal and the like). But it helps a lot.

And about the engine: I guess the old engine fails on that, as I do not
get the desired output. I checked out the latest version and tried to
run ./std/grind.py (the README.txt still mentions grind.sh). I get the
following output:

$ python std/grind.py
…Traceback (most recent call last):
File “/home/marek/Documents/temp1/citeproc-js/std/grind.py”, line 197,
in
tests.process()
File “/home/marek/Documents/temp1/citeproc-js/std/grind.py”, line 72,
in process
test.dump()
File “/home/marek/Documents/temp1/citeproc-js/std/grind.py”, line 159,
in dump
json.dump(self.data, open(tpath_out,“w+”), indent=4, sort_keys=True,
ensure_ascii=False )
File “/var/lib/python-support/python2.5/simplejson/init.py”, line
185, in dump
fp.write(chunk)
UnicodeEncodeError: ‘ascii’ codec can’t encode character u’\xf6’ in
position 3: ordinal not in range(128)

I am running ubuntu 8.10 on 64bit. Is the simplejson package broken?

Best wishes,
Marek

Frank Bennett wrote:

Frank_Bennett · July 4, 2009, 2:26am

Thank you for the help.

I had seen the help on the zotero page. But I think not everything is
explained. For example there is no list of all possible zotero items (book,
journal and the like). But it helps a lot.

And about the engine: I guess the old engine fails on that, as I do not get
the desired output. I checked out the latest version and tried to run
./std/grind.py (the README.txt still mentions grind.sh). I get the following
output:

$ python std/grind.py
…Traceback (most recent call last):
File “/home/marek/Documents/temp1/citeproc-js/std/grind.py”, line 197, in

tests.process()
File “/home/marek/Documents/temp1/citeproc-js/std/grind.py”, line 72, in
process
test.dump()
File “/home/marek/Documents/temp1/citeproc-js/std/grind.py”, line 159, in
dump
json.dump(self.data, open(tpath_out,“w+”), indent=4, sort_keys=True,
ensure_ascii=False )
File “/var/lib/python-support/python2.5/simplejson/init.py”, line 185,
in dump
fp.write(chunk)
UnicodeEncodeError: ‘ascii’ codec can’t encode character u’\xf6’ in position
3: ordinal not in range(128)

I am running ubuntu 8.10 on 64bit. Is the simplejson package broken?

Marek, thanks for reporting this. This was a lazy oversight on my part.
We use UTF-8 encoding when dumping the test cases to disk, but the
default encoding set in Python out of the box is ascii. I had worked around
this locally by setting the default encoding in my own Python installation to
utf-8, with result that the script was destined to break on most other systems.

This script is now set up to force the default encoding to utf-8, and should
work for you now. I’ve also fixed the README.txt – thanks for pointing
that out as well.

Frank Bennett

Rintze_Zelle · July 4, 2009, 8:08am

There is a thread on the xbiblio mailing list on, among others, the IEEE
citation collapsing:
http://sourceforge.net/mailarchive/message.php?msg_name=188351850904070046i2d2a3663t22e2c8a1a77521ef%40mail.gmail.com

The current CSL processor in Zotero indeed can’t handle the case.

Rintze

Mogliii · July 4, 2009, 1:15pm

I checked out the new version and grind.py does not report any problem.

When I run the test (./runtest.sh) I get three failures. I am not sure
what it means so I just report here. Below is the output:#####
Rhino file.encoding: UTF-8

182 tests to run in 34 groups

GROUP “tests.std_discretionary” has 4 tests to run

GROUP “tests.std_collapse” has 5 tests to run

GROUP “tests.sys_stdrhino_load” has 2 tests to run

GROUP “tests.queue” has 4 tests to run

GROUP “tests.sys_rhino_locale” has 8 tests to run

GROUP “tests.suffixator” has 2 tests to run

GROUP “tests.build” has 1 test to run

GROUP “tests.std_condition” has 1 test to run

GROUP “tests.std_namespaces” has 8 tests to run
_AssertFailure: doh._AssertFailure: assertEqual() failed:
expected

but got
    Book A

: assertEqual() failed:
expected

but got
    Book A

doh._AssertFailure: assertEqual() failed:
expected

but got
    Book A


ERROR IN:
     (function () {var test = new

StdRhinoTest(“namespaces_Nada3”);doh.assertEqual(test.result, test.run());})
_AssertFailure: doh._AssertFailure: assertEqual() failed:
expected
Book A
but got

: assertEqual() failed:
expected
Book A
but got

doh._AssertFailure: assertEqual() failed:
expected
Book A
but got

ERROR IN:
     (function () {var test = new

StdRhinoTest(“namespaces_NonNada2”);doh.assertEqual(test.result,
test.run());})
_AssertFailure: doh._AssertFailure: assertEqual() failed:
expected
Book A
but got

: assertEqual() failed:
expected
Book A
but got

doh._AssertFailure: assertEqual() failed:
expected
Book A
but got

ERROR IN:
     (function () {var test = new

StdRhinoTest(“namespaces_NonNada”);doh.assertEqual(test.result,
test.run());})

GROUP “tests.sys_stdrhino_locale” has 5 tests to run

GROUP “tests.ambigconfig” has 2 tests to run

GROUP “tests.std_locators” has 1 test to run

GROUP “tests.std_affix” has 1 test to run

GROUP “tests.std_fullstyles” has 2 tests to run

GROUP “tests.std_number” has 2 tests to run

GROUP “tests.formats” has 2 tests to run

GROUP “tests.stack” has 14 tests to run
Internal CSL processor error: attempt to replace nonexistent stack item
with hello (this error is correct)

GROUP “tests.blob” has 5 tests to run

GROUP “tests.flipflopper” has 18 tests to run

GROUP “tests.std_name” has 36 tests to run

GROUP “tests.opt” has 2 tests to run

GROUP “tests.std_date” has 4 tests to run

GROUP “tests.std_sort” has 4 tests to run

GROUP “tests.std_terms” has 2 tests to run

GROUP “tests.formatters” has 2 tests to run

GROUP “tests.std_magic” has 9 tests to run

GROUP “tests.fun” has 1 test to run

GROUP “tests.sys_rhino_load” has 2 tests to run

GROUP “tests.tmp” has 1 test to run

GROUP “tests.std_disambiguate” has 14 tests to run

GROUP “tests.romanizer” has 1 test to run

GROUP “tests.registry” has 1 test to run

GROUP “tests.load_styles” has 15 tests to run

GROUP “tests.output” has 1 test to run

TEST SUMMARY:

 182 tests in 34 groups
 0 errors
 3 failures

Sat Jul 4 15:09:55 CEST 2009 <--------------START
Sat Jul 4 15:10:12 CEST 2009 <--------------END

Mogliii · July 4, 2009, 1:19pm

Hi,

I see. So I will be patient until the new engine is released. I thought
its just a matter of tweaking the .xml file.

Thank you for pointing this out.
Marek

Rintze Zelle wrote:> There is a thread on the xbiblio mailing list on, among others, the

Bruce_D_Arcus1 · July 4, 2009, 2:39pm

It’s a known problem, so not per se a bug (e.g. the tests are working
correctly).