From: Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
To: Richard Lawrence <richard.lawrence@berkeley.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: Citation syntax and ODT
Date: Tue, 24 Feb 2015 10:04:35 +0530 [thread overview]
Message-ID: <54EBFF5B.30009@gmail.com> (raw)
In-Reply-To: <87fv9wrz0s.fsf@berkeley.edu>
On Tuesday 24 February 2015 04:55 AM, Richard Lawrence wrote:
> Vaidheeswaran C<vaidheeswaran.chinnaraju@gmail.com> writes:
>
>>> But whatever style is chosen, I would still think that the fact that the
>>> citation is in-text rather than parenthetical, and that it has a prefix
>>> and suffix, should be represented in the output.
>>
>> 1. When you choose 'style' (Chicago etc.) wouldn't be one of in-text
>> or parenthetical already chosen for you? Stated other way, is the
>> choice between parenthetical or in-text document-wide or is it that
>> one could intermix the two styles in the same document.
>
> These could be intermixed in the same document. The document-level
> style determines how each type ultimately looks, but the choice of style
> is (mostly) independent of using parenthetical vs. in-text citations.
Often times there is a difference between what is possible and what is
the common practice. So,
1. How often do you intermix in-text and parenthetical styles.
2. Can the document author re-word his work in such a way that an
in-text or parenthetical citation could be replaced by the other
without compromising on the overall style of the produced document.
>> 2. Citation processor like JabRef just takes a cite-key. It doesn't
>> take a pre or post-note. So, the pre and post notes should be
>> spliced in to the exported document by the elisp module that
>> interfaces with the citation processor.
>
> Right. That's what I'm thinking, anyway.
>
>> If we are going to interface with a citation-processor, the best
>> course of action would be to have someone first 'gauge' the
>> capabilities provided by the citation processor and let that
>> experience inform what Org should aspire to do.
>
> Yes. Other people have more experience with this than me. But based on
> what Pandoc is able to do, I am pretty confident that everything that
> has been proposed could be handled by a CSL processor like citeproc-js
> (or Pandoc's own). The possible exceptions are the common prefix and
> common suffix in a multi-work citation, which I imagine would be easy
> enough to add to the output of the citation processor.
In case of JabRef or bibtex2html, it is the 'command line' that is
used for interfacing.
In case of pandoc (I could be wrong here), the nature of interface is
most likely to be a post-processing step on the produced document.
This post-processing could happen as part of elisp hook or the
document may be pipelined through a pandoc provided command-line tool.
The point is that the choice of the citation processor will determine
the nature of investments that need to be made in to the export
module.
JabRef or bibtex2html are really very poor cousins when compared to
modern tools like Zotero. They would continue to remain poor cousins.
So, I can imagine a scenario where JabRef or bibtex2html is relegated
to the background (i.e., a contrib/ Org-module) while Zotero/Pandoc
takes the prime-time (i.e., a lisp/ Org-module).
In so far as zotero is concerned, there 'used to be' no standalone JS
command-line environment or the toolchain was cumbersome.
----------------------------------------------------------------
I am reluctant to invest my time in citeproc-js or pandoc related
integration work (so far as it concerns ODT exporter). Part of the
reason for this relucatance is that setting up of the toolchain would
involve more than a simple 'apt-get ...'. (My Debian is a bit old.)
I am reluctant to work on JabRef integration unless I get an apriori
commitment from the maintainers that it will be part of the Emacs
distribution.
> Best,
> Richard
>
>
next prev parent reply other threads:[~2015-02-24 4:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 7:22 Citation syntax and ODT Vaidheeswaran
2015-02-23 4:11 ` Richard Lawrence
2015-02-23 6:22 ` Vaidheeswaran
2015-02-23 7:10 ` Vaidheeswaran
2015-02-23 17:15 ` Richard Lawrence
2015-02-23 18:11 ` Vaidheeswaran C
2015-02-23 23:25 ` Richard Lawrence
2015-02-24 3:26 ` Alexis
2015-02-24 3:52 ` Vaidheeswaran C
2015-02-24 4:34 ` Vaidheeswaran C [this message]
2015-02-24 5:01 ` Thomas S. Dye
2015-02-24 5:31 ` Vaidheeswaran C
2015-02-24 6:07 ` Thomas S. Dye
2015-02-24 6:37 ` Vaidheeswaran C
2015-02-24 7:48 ` Thomas S. Dye
2015-02-24 17:19 ` Jorge A. Alfaro-Murillo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54EBFF5B.30009@gmail.com \
--to=vaidheeswaran.chinnaraju@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=richard.lawrence@berkeley.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).