It's true that messing with field content is always a potential source of headaches, but the processor is very good about this. In a US-English style, outer quotes are always double-quotes, and inner quotes are always single in the output, regardless of the nesting order in the field. So if you enter this: Jones said 'my definition of "cosmos" differs from that of Smith' It will render in a US-English style as: Jones said “my definition of ‘cosmos’ differs from that of Smith” In a GB-English style it will render as: Jones said ‘my definition of “cosmos” differs from that of Smith’ In the plugin, handling of the straight double-quote still needs to be fixed, but once that's on stream these examples will process correctly. (We've made the fix already and are now testing, so this should be available within a couple of days.)
To be clear, this "flip-flop" behavior for outer and inner quotes is not a feature of the ODF/RTF Scan plugin: it's done by code that has been running in the Zotero processor for the past couple of years.
FYI, I was trying unsuccessfully to revert to markers until I figured out that RTF/ODF Scan did not like one page containing a landscape table. Ran fine after deleting table.
The error message showed up in red in the RTF Scan dialogue, beneath the input file line. The original doc was not produced using RTF Scan. It was an older doc created manually.
Frank has just released a new version that should fix the formatting issues when using Scrivener noted by benjaminsiegel. We've tested this and it works nicely, but we'd be happy to have some other people try it out.
@adamsmith. Back up there a ways I just noticed that you wondered how, in Scrivener, you compile to odt with footnotes. You can't. You must compile to rtf, convert the rtf to odt, then run rtf/odf scan. Apparently there are all kinds of rtf converters involved: the one in Scrivener and the one in whatever tool you use to make the conversion. Weird things happen. I have tried to coax Scrivener into souping up the odt compiler, but I don't think that it's a high priority with them at the moment. They use some third party for it.
Where Do I Put the Period? In the following citation:
{ For a carefully restored critical edition of the Memoirs, which contains a complete list of primary source materials for Finney research (pp. 671-678), see | Finney, et al., (1989) | | Only the 1989 edition appears to contain the scholarly material as Zondervan has issued a documentation-free edition (2002) under the same title. |zu:1297786:TVA7VIWF}
Somewhere after "(1989)" and before "Only," but where?
Is there any way to move from LibreOffice to Word after completing the RTF/ODF scan when using footnotes? Footnote style won't allow me to convert to bookmarks. I'm in the arts, and we use Chicago full note footnote style, and I also need to be able to send files in doc/docx form with the footnotes intact as footnotes, not just as body text. Is there any way for this to work?
I'd actually recommend using an author-date style in Libre Office, then saving as Bookmarks and .doc, opening in Word and changing to Chicago Full Note - Endnote's as suggested by Aurimas works, too, but LibreOffice's Endnote handling isn't great and I'm worried about converting those to .doc.
For a start, you want to use "p. 23" not "p 23" as the locator. ODF scan doesn't recognize this without the period. Try to fix that and see what happens.
@Frank - I haven't actually looked at this in the code, but I'm not sure we're handling undefined locators elegantly.
As I said, hadn't checked this, but the way we're handling it turns out to be fine.
If "p 23" (or anything else without a recognized locator abbreviation) is entered as a locator, we're defaulting to the locator being page, i.e. in this case the citation e.g. in APA style becomes
(Smith, 1776, p. p 23)
I think that's exactly what we should be doing, so no problem here.
Can I make a request for a couple of potential changes.
In the following, (1) is it possible to remove the brackets round the date or have an option to do so, and (2) to have the ampersand as only an ampersand?
sure - I've made the change, will be in the next update unless Frank has objections. If you want it now, you can replace the file "Scannable Cite.js" in your zotero data folder with this version:
https://gist.github.com/adam3smith/7453404/raw/365a8625d8d9b8483ffb5b155f4ca093679117ca/Scannable+Cite.js
note that you will have to replace the "+" in the filename with a space.
(this will still have a comma before the ampersand. We could remove that, but it'd be a hassle and at least for me not worth it given that it's purely cosmetic.)
One further issue: sometimes it is necessary to put in plural chapters etc, eg:
chapters 1 and 2
paragraphs 3 and 4 etc
At present pages is recognised as plural, but not the others. I just tried to put in plural chapters (ie { | Kelman, 2011 |chs. 3 and 5| | zotero://select/items/0_KBZ6TKU9}) and it recognised it as pages (ie in Harvard (Kelman 2011, p.chs. 3 and 5)) (which I assume is the default).
That has nothing to do with ODF scan - the processor parses the content of the locator field and decides whether it's singular or plural (e.g. 3-5 is recognized as plural, even when specified as ch.).
That includes pages - we just allow both labels in the ODF scan marker since many people are accustomed to using pp. - but for the final citation it doesn't matter whether you use p. or pp.
That's helpful to know - I guessed as much after I posted.
However, given that there is an explicit provision for pp, people would be likely to assume that it is the same for the others - ie, you should use chs. paras. etc. If they do, then this causes a problem for the processor. For this reason, could we get the ODF scan to recognise chs. paras. etc and reduce them to ch. para. etc on conversion so that the processor handles them normally?
There are good reasons for keeping the processor's list of parsed strings as compact as possible, so the processor behaviour should remain as it stands.
While it would be possible for the RTF/ODF Scan plugin to normalise strings embedded in the locator (so that the ODF document is rebuilt with the singular form only), that would produce a potentially confusing discrepancy in behaviour: users would find that the plural forms seem to be recognised in scannable cites, but not in the locator field of the Zotero word processor plugin.
It will be simpler all around to keep things as they are.
{ | Quine, (1960) |p. 220|zotero://select/items/0_B4W7DS8M}
is missing a pipe (|). Should be
{ | Quine, (1960) |p. 220||zotero://select/items/0_B4W7DS8M}
Right now the scan is pretty sensitive to that. We might consider working on that, but not any time soon.
Upgrade Storage
Jones said 'my definition of "cosmos" differs from that of Smith'It will render in a US-English style as:
Jones said “my definition of ‘cosmos’ differs from that of Smith”In a GB-English style it will render as:
Jones said ‘my definition of “cosmos” differs from that of Smith’In the plugin, handling of the straight double-quote still needs to be fixed, but once that's on stream these examples will process correctly. (We've made the fix already and are now testing, so this should be available within a couple of days.)
To be clear, this "flip-flop" behavior for outer and inner quotes is not a feature of the ODF/RTF Scan plugin: it's done by code that has been running in the Zotero processor for the past couple of years.
FYI, I was trying unsuccessfully to revert to markers until I figured out that RTF/ODF Scan did not like one page containing a landscape table. Ran fine after deleting table.
The error message showed up in red in the RTF Scan dialogue, beneath the input file line. The original doc was not produced using RTF Scan. It was an older doc created manually.
{ For a carefully restored critical edition of the Memoirs, which contains a complete list of primary source materials for Finney research (pp. 671-678), see | Finney, et al., (1989) | | Only the 1989 edition appears to contain the scholarly material as Zondervan has issued a documentation-free edition (2002) under the same title. |zu:1297786:TVA7VIWF}
Somewhere after "(1989)" and before "Only," but where?
@Frank - I haven't actually looked at this in the code, but I'm not sure we're handling undefined locators elegantly.
If "p 23" (or anything else without a recognized locator abbreviation) is entered as a locator, we're defaulting to the locator being page, i.e. in this case the citation e.g. in APA style becomes
(Smith, 1776, p. p 23)
I think that's exactly what we should be doing, so no problem here.
In the following, (1) is it possible to remove the brackets round the date or have an option to do so, and (2) to have the ampersand as only an ampersand?
{ | Moore, & Hope, (1929) |p. 703| |zotero://select/items/0_RBUBSVEN}
Ie
{ | Moore & Hope, 1929 |p. 703| |zotero://select/items/0_RBUBSVEN}
https://gist.github.com/adam3smith/7453404/raw/365a8625d8d9b8483ffb5b155f4ca093679117ca/Scannable+Cite.js
note that you will have to replace the "+" in the filename with a space.
(this will still have a comma before the ampersand. We could remove that, but it'd be a hassle and at least for me not worth it given that it's purely cosmetic.)
chapters 1 and 2
paragraphs 3 and 4 etc
At present pages is recognised as plural, but not the others. I just tried to put in plural chapters (ie { | Kelman, 2011 |chs. 3 and 5| | zotero://select/items/0_KBZ6TKU9}) and it recognised it as pages (ie in Harvard (Kelman 2011, p.chs. 3 and 5)) (which I assume is the default).
It is possible to add these plurals?
Thanks!
That includes pages - we just allow both labels in the ODF scan marker since many people are accustomed to using pp. - but for the final citation it doesn't matter whether you use p. or pp.
However, given that there is an explicit provision for pp, people would be likely to assume that it is the same for the others - ie, you should use chs. paras. etc. If they do, then this causes a problem for the processor. For this reason, could we get the ODF scan to recognise chs. paras. etc and reduce them to ch. para. etc on conversion so that the processor handles them normally?
While it would be possible for the RTF/ODF Scan plugin to normalise strings embedded in the locator (so that the ODF document is rebuilt with the singular form only), that would produce a potentially confusing discrepancy in behaviour: users would find that the plural forms seem to be recognised in scannable cites, but not in the locator field of the Zotero word processor plugin.
It will be simpler all around to keep things as they are.
So can I check - is it unnecessary to put pp. when there is a range of pages in the field? Would say p. 4-5 be recognised?
{ | Leibniz, (1714) |para. 17| |zotero://select/items/0_J4FCVDF7}{ | Quine, (1960) |p. 220|zotero://select/items/0_B4W7DS8M}{ | Churchland, (1981) |p. 70| |zotero://select/items/0_AMBB9BEW}{ | Posner, (1995) |p. 398| |zotero://select/items/0_55ZAN9GM}{ | Pereboom, (2006) |p. xiv| |zotero://select/items/0_BJTFGVJE}{ | Pinker, (2009) |p. 54| |zotero://select/items/0_4GS4H5GB}
Comes out as:
Leibniz, (1714){ | Quine, (1960) |p. 220|zotero://select/items/0_B4W7DS8M}Pinker, (2009); Pereboom, (2006); Posner, (1995); Churchland, (1981)
Any ideas why this might be?
is missing a pipe (|). Should be
{ | Quine, (1960) |p. 220||zotero://select/items/0_B4W7DS8M}
Right now the scan is pretty sensitive to that. We might consider working on that, but not any time soon.
Pinker, (2009); Pereboom, (2006); Posner, (1995); Churchland, (1981); Quine, (1960); Leibniz, (1714)