From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Kitchin Subject: Re: More questions about CSL and org-mode Date: Mon, 07 Dec 2015 11:18:09 -0500 Message-ID: References: <87r3izupne.fsf@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5yUS-0004lp-Cb for emacs-orgmode@gnu.org; Mon, 07 Dec 2015 11:18:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5yUP-0007Tl-34 for emacs-orgmode@gnu.org; Mon, 07 Dec 2015 11:18:16 -0500 Received: from mail-qg0-x229.google.com ([2607:f8b0:400d:c04::229]:35315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5yUO-0007Th-Vy for emacs-orgmode@gnu.org; Mon, 07 Dec 2015 11:18:13 -0500 Received: by qgec40 with SMTP id c40so147073456qge.2 for ; Mon, 07 Dec 2015 08:18:12 -0800 (PST) In-reply-to: <87r3izupne.fsf@berkeley.edu> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Richard Lawrence Cc: Org Mode Richard Lawrence writes: > Hi John, > > John Kitchin writes: > >> Hi all, >> >> This is mostly for the people working on citations in org-mode. >> >> I have been reading about CSL more this weekend. IIRC, one of the >> reasons to develop the new citation syntax was to get the ability to >> have pre/post text in citations more conveniently than what is currently >> possible. > > Yes, that is my understanding, too. > >> I have not seen any possibility for this with CSL, however. Is my >> understanding correct? Is this a problem, or something partially handled >> by org-export and partially by a citeproc? > > The CSL processors I've looked at support prefix and suffix text for > individual references within a citation. See, for example, the > citeproc-js documentation: > > http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#citation-data-object > > prefix, suffix, and some other fields are supported. pandoc-citeproc > supports the same set of fields. Interesting. I guess these are not standard for all processors? It also looks like it would be hard to get something like an inline reference formatted as [1] but refer to Reference 1, e.g. from citenum. It is possible to have (Kitchin 2007) and (2007) but not a citation reference to Kitchin that is derived from e.g. a citeauthor command in LaTeX. I am not raising any objections here, just getting a sense for what is feasible. > > However, my understanding is that neither citeproc-js nor > pandoc-citeproc support a BibLaTeX-style "common" prefix/suffix that > belongs to the citation as a whole, rather than the individual > references within it, as is available in the multi-cite commands. We > currently have support for such common prefixes/suffixes in Org syntax. > > My solution to this in my org-citeproc wrapper for pandoc-citeproc is to > prepend the common prefix to the prefix for the first reference in a > citation, and append the common suffix to the last reference. This is > not a great solution, because it is not really defined what kind of > punctuation (if any) should separate the common prefix from the first > item's prefix, and so on. But I figured that was not an important issue > to address until we actually have people making use of common prefix and > suffix syntax who are not exporting to LaTeX... agreed. > >> IIUC, the current aim is to get a citeproc that will do the following on >> export: >> 1. replace in-text citation syntax with org-formatted replacements >> 2. Insert an org-formatted bibliography somewhere in the document >> 3. proceed with org-to-something export, with built-in >> exporters. > > That's basically my understanding too. There is one snag with the > "org-formatted replacement" plan, though, which I saw in a Zotero dev > discussion yesterday. CSL processing might result in multiple levels of > formatting, e.g. nested italics like > > Something with an internal Title > > and that won't translate very well back to Org syntax in general: > > /Something with an internal /Title// > > The suggestion was to just use HTML output, and then parse the HTML to > get a data structure that could be directly rendered into HTML, LaTeX, > etc., which support nested italics just fine. I think we could do this, > though maybe there's a better solution. That is, we can take HTML from > the citation processor and go directly to org-element objects, without > producing and re-parsing citations in Org format. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu