emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Citation syntax and ODT


From: Vaidheeswaran C
Subject: Re: [O] Citation syntax and ODT
Date: Tue, 24 Feb 2015 10:04:35 +0530
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20121216 Icedove/3.0.11

On Tuesday 24 February 2015 04:55 AM, Richard Lawrence wrote:
Vaidheeswaran C<address@hidden>  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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]