[-- Attachment #1: Type: text/plain, Size: 2373 bytes --] Hi everyone, I thought I should send an update to let you know that org-citeproc [1], the command-line citation processing tool I've been working on, now supports multi-cites. I believe that means it is now capable of processing all citations in the basic citation syntax. It can output plain text, HTML, and ODT (and a Pandoc native format, mostly useful for debugging). org-citeproc hooks up with the Org exporters via Aaron Ecay's org-cite [2] library, so that it is possible to export a document containing citations as text, HTML, or ODT. A sample Org document, bib file, CSL file, and outputs are attached. I am pretty convinced at this point that the approach that the combination of org-cite and org-citeproc represents is viable, even if org-citeproc is not the tool (or one of the tools) that the Org community eventually adopts. If you'd like to help out with developing it, here are some things that would be useful: 1) If you are comfortable building a Haskell program and running an unstable branch of Org, it would be great to have people test org-cite and org-citeproc with more realistic documents, and with other CSL files. The basic things work, but there are surely many corner cases to be weeded out. 2) If you know Haskell, I would appreciate feedback on the org-citeproc code. I am pretty new to Haskell and suspect there is a lot in my code that could be cleaned up or made more idiomatic. 3) If you know Elisp, there are plenty of things still TODO in org-cite.el. I haven't hacked on this much except to get it working with org-citeproc. 4) I would also be interested in seeing a parallel implementation in org-cite of citation processing via Zotero. I think the infrastructure org-cite provides should make it relatively easy to get something like this working, perhaps in combination with the zotxt plugin. This would provide two benefits: it would help prove the org-cite API is general enough, and it would provide an alternative to org-citeproc for people who already have a CSL implementation (namely Zotero) installed and don't want to build/install a separate Haskell program just to process citations. Here's the code: [1] https://github.com/wyleyr/org-citeproc [2] https://github.com/wyleyr/org-mode (This branch contains the version of org-cite needed to work with org-citeproc.) Thanks for looking! Best, Richard [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Test document --] [-- Type: text/x-org, Size: 3979 bytes --] #+OPTIONS: ':nil *:t -:t ::t <:t H:3 \n:nil ^:t arch:nil author:t #+OPTIONS: c:nil creator:comment d:(not "LOGBOOK") date:t e:t #+OPTIONS: email:nil f:t inline:t num:t p:nil pri:nil prop:nil stat:t #+OPTIONS: tags:t tasks:t tex:t timestamp:t title:t toc:t todo:t |:t #+TITLE: Org-Citeproc tests #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+SELECT_TAGS: export #+EXCLUDE_TAGS: noexport #+CREATOR: Emacs 23.4.1 (Org mode 8.3beta) #+CSL_FILE: chicago-author-date.csl #+BIBDB: bibtex testdoc.bib * Org markup ** Simple citations *** Parenthetical Some great ideas occur in books [@Brandom1994]. Others in articles [@Hofweber2007]. Still others are in collections of previously published work [@Russell1919], or in conference proceedings [@Rogers1996]; sometimes they are the proceedings themselves [@RogersKepser2007]. Sometimes, a great idea can be found in a dissertation [@Caponigro2003], and sometimes on just a handout [@Ross1985]. Some remain forever unpublished [@Faraci1970]. *** In-text Some great ideas occur in books, such as @Brandom1994. Others in articles, such as @Hofweber2007. Still others are in collections of previously published work, such as @Russell1919, or in conference proceedings like @Rogers1996; sometimes they are the proceedings themselves such as @RogersKepser2007. Sometimes, a great idea can be found in a dissertation, such as @Caponigro2003, and sometimes on just a handout like @Ross1985. Some remain forever unpublished, such as @Faraci1970. *** With prefix and suffix data Some great ideas occur in books [(cite): see @Brandom1994 chapter 7]. Others in articles [(cite): @Hofweber2007 section 1]. Still others are in collections of previously published work, such as [cite: @Russell1919 cf. section 3], or in conference proceedings [(cite): e.g., @Rogers1996]. Sometimes, a great idea can be found in a dissertation, like an idea by [cite: see @Caponigro2003 chapter 1], and sometimes on just a handout, like others by [cite: e.g., @Ross1985]. *** Citations to works with tricky field data In some cases, the authors have names which are tricky to represent in BibTeX, like @BelnapSteel1976, or @Vaanaanen2011. @denDikkenMeinungerWilder2000 has a lead author that should probably be capitalized in sentence-initial position. Sometimes, it's the journal name which is difficult [@Belnap1970]. ** Multi-cite citations *** Parenthetical, keys only Some great ideas occur in books, articles, or collections [(cite): @Brandom1994; @Hofweber2007; @Russell1919]. Some occur in conference proceedings or dissertations [(cite): @Rogers1996; @RogersKepser2007; @Caponigro2003], and sometimes remain unpublished [(cite): @Ross1985; @Faraci1970]. *** Parenthetical, with prefix and suffix data for individual works Some great ideas occur in books, articles, or collections [(cite): see @Brandom1994 chapter 7; also @Hofweber2007; @Russell1919 is the locus classicus]. Some occur in conference proceedings or dissertations [(cite): @Rogers1996; for an overview, see @RogersKepser2007 and references therein]. *** Parenthetical, with common prefix and suffix data Some great ideas occur in books, articles, or collections [(cite): For more on this topic, see ; @Brandom1994; @Hofweber2007; @Russell1919; and references therein]. *** All in-text, keys only Some great ideas occur in books, articles, or collections such as [cite: @Brandom1994; @Hofweber2007; @Russell1919]. Some occur in conference proceedings or dissertations like [cite: @Rogers1996; @RogersKepser2007; @Caponigro2003], and sometimes remain unpublished, like [cite: @Ross1985; @Faraci1970]. *** All in-text, with common prefix and suffix Some great ideas occur in books, articles, or collections. [cite: See: ; @Brandom1994; @Hofweber2007; @Russell1919; and references therein.] Some occur in conference proceedings or dissertations. [cite: For more on this topic, see ; @Rogers1996; @RogersKepser2007; @Caponigro2003]. * References #+BIBLIOGRAPHY: here [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: Bibtex database for test document --] [-- Type: text/x-bibtex, Size: 2610 bytes --] @book{Brandom1994, author={Robert Brandom}, title={Making it Explicit}, publisher={Harvard University Press}, year={1994} } @article{Hofweber2007, author={Hofweber, Thomas}, title={Innocent Statements and their Metaphysically Loaded Counterparts}, journal={Philosophers' Imprint}, year={2007}, volume={7}, number={1}, month={February} } @incollection{Russell1919, author={Bertrand Russell}, title={Descriptions}, booktitle={The Philosophy of Language}, publisher={Oxford University Press}, year={2001}, editor={A. P. Martinich}, chapter={15}, pages={221--227}, edition={Fourth} } @inproceedings{Rogers1996, author={James Rogers}, title={A model-theoretic framework for theories of syntax}, booktitle={Proceedings of the 34th annual meeting on Association for Computational Linguistics}, year={1996}, pages={10--16}, address={Santa Cruz, CA, USA}, organization={Association for Computational Linguistics} } @proceedings{RogersKepser2007, title={Model-theoretic syntax at 10}, year={2007}, editor={James Rogers and Stephan Kepser}, organization={Association for Logic, Language and Information} } @phdthesis{Caponigro2003, author={Ivano Caponigro}, title={Free not to ask: On the semantics of free relatives and Wh-words cross-linguistically}, school={University of California, Los Angeles}, year={2003}, note={Cited text available at http://idiom.ucsd.edu/~ivano/Papers/2003_dissertation_revised_7-13-05.pdf} } @misc{Ross1985, author={Ross, John R.}, title={The source of pseudocleft sentences}, howpublished={Handout of a talk given at New York University}, month={November}, year={1985} } @unpublished{Faraci1970, author={Faraci, R.}, title={On the deep question of pseudo-clefts}, year={1970} } @book{BelnapSteel1976, author={Belnap, Jr., Nuel D. and Steel, Jr., Thomas B.}, title={The logic of questions and answers}, publisher={Yale University Press}, year={1976} } @book{Vaanaanen2011, author={Jouko V\"{a}\"{a}n\"{a}\"{a}nen}, title={Models and Games}, publisher={Cambridge University Press}, year={2011}, volume={132}, series={Cambridge studies in advanced mathematics} } @article{denDikkenMeinungerWilder2000, author={{den Dikken}, Marcel and Andr\'{e} Meinunger and Chris Wilder}, title={Pseudoclefts and ellipsis}, journal={Studia Linguistica}, year={2000}, volume={54}, pages={41--89} } @article{Belnap1970, author={Belnap, Nuel}, title={Conditional assertion and restricted quantification}, journal={No\^{u}s}, year={1970}, volume={4}, number={1}, pages={1--12} } [-- Attachment #4: Test document rendered as text --] [-- Type: text/plain, Size: 7146 bytes --] ━━━━━━━━━━━━━━━━━━━━ ORG-CITEPROC TESTS Richard Lawrence ━━━━━━━━━━━━━━━━━━━━ Table of Contents ───────────────── 1 Org markup .. 1.1 Simple citations ..... 1.1.1 Parenthetical ..... 1.1.2 In-text ..... 1.1.3 With prefix and suffix data ..... 1.1.4 Citations to works with tricky field data .. 1.2 Multi-cite citations ..... 1.2.1 Parenthetical, keys only ..... 1.2.2 Parenthetical, with prefix and suffix data for individual works ..... 1.2.3 Parenthetical, with common prefix and suffix data ..... 1.2.4 All in-text, keys only ..... 1.2.5 All in-text, with common prefix and suffix 2 References 1 Org markup ════════════ 1.1 Simple citations ──────────────────── 1.1.1 Parenthetical ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Some great ideas occur in books (Brandom 1994). Others in articles (Hofweber 2007). Still others are in collections of previously published work (Russell 2001), or in conference proceedings (Rogers 1996); sometimes they are the proceedings themselves (Rogers and Kepser 2007). Sometimes, a great idea can be found in a dissertation (Caponigro 2003), and sometimes on just a handout (Ross 1985). Some remain forever unpublished (Faraci 1970). 1.1.2 In-text ╌╌╌╌╌╌╌╌╌╌╌╌╌ Some great ideas occur in books, such as Brandom (1994). Others in articles, such as Hofweber (2007). Still others are in collections of previously published work, such as Russell (2001), or in conference proceedings like Rogers (1996); sometimes they are the proceedings themselves such as Rogers and Kepser (2007). Sometimes, a great idea can be found in a dissertation, such as Caponigro (2003), and sometimes on just a handout like Ross (1985). Some remain forever unpublished, such as Faraci (1970). 1.1.3 With prefix and suffix data ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Some great ideas occur in books (see Brandom 1994 chapter 7). Others in articles (Hofweber 2007 section 1). Still others are in collections of previously published work, such as Russell (2001 cf. section 3), or in conference proceedings (e.g., Rogers 1996). Sometimes, a great idea can be found in a dissertation, like an idea by Caponigro (see 2003 chapter 1), and sometimes on just a handout, like others by Ross (e.g., 1985). 1.1.4 Citations to works with tricky field data ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ In some cases, the authors have names which are tricky to represent in BibTeX, like N. D. Belnap Jr. and Steel (1976), or Väänäänen (2011). den Dikken, Meinunger, and Wilder (2000) has a lead author that should probably be capitalized in sentence-initial position. Sometimes, it's the journal name which is difficult (N. Belnap 1970). 1.2 Multi-cite citations ──────────────────────── 1.2.1 Parenthetical, keys only ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Some great ideas occur in books, articles, or collections (Brandom 1994; Hofweber 2007; Russell 2001). Some occur in conference proceedings or dissertations (Rogers 1996; Rogers and Kepser 2007; Caponigro 2003), and sometimes remain unpublished (Ross 1985; Faraci 1970). 1.2.2 Parenthetical, with prefix and suffix data for individual works ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Some great ideas occur in books, articles, or collections (see Brandom 1994 chapter 7; also Hofweber 2007; Russell 2001 is the locus classicus). Some occur in conference proceedings or dissertations (Rogers 1996; for an overview, see Rogers and Kepser 2007 and references therein). 1.2.3 Parenthetical, with common prefix and suffix data ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Some great ideas occur in books, articles, or collections (For more on this topic, see Brandom 1994; Hofweber 2007; Russell 2001, and references therein). 1.2.4 All in-text, keys only ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Some great ideas occur in books, articles, or collections such as Brandom (1994), Hofweber (2007), Russell (2001). Some occur in conference proceedings or dissertations like Rogers (1996), Rogers and Kepser (2007), Caponigro (2003), and sometimes remain unpublished, like Ross (1985), Faraci (1970). 1.2.5 All in-text, with common prefix and suffix ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Some great ideas occur in books, articles, or collections. See: Brandom (1994), Hofweber (2007), Russell (2001), and references therein. Some occur in conference proceedings or dissertations. For more on this topic, see Rogers (1996), Rogers and Kepser (2007), Caponigro (2003). 2 References ════════════ Belnap, Nuel. 1970. “Conditional Assertion and Restricted Quantification.” _Noûs_ 4 (1): 1–12. Belnap, Nuel D., Jr., and Thomas B. Steel Jr. 1976. _The Logic of Questions and Answers_. Yale University Press. Brandom, Robert. 1994. _Making It Explicit_. Harvard University Press. Caponigro, Ivano. 2003. “Free Not to Ask: On the Semantics of Free Relatives and Wh-Words Cross-Linguistically.” PhD thesis, University of California, Los Angeles. den Dikken, Marcel, André Meinunger, and Chris Wilder. 2000. “Pseudoclefts and Ellipsis.” _Studia Linguistica_ 54: 41–89. Faraci, R. 1970. “On the Deep Question of Pseudo-Clefts.” Hofweber, Thomas. 2007. “Innocent Statements and Their Metaphysically Loaded Counterparts.” _Philosophers’ Imprint_ 7 (1). Rogers, James. 1996. “A Model-Theoretic Framework for Theories of Syntax.” In _Proceedings of the 34th Annual Meeting on Association for Computational Linguistics_, 10–16. Santa Cruz, CA, USA: Association for Computational Linguistics. Rogers, James, and Stephan Kepser, eds. 2007. _Model-Theoretic Syntax at 10_. Association for Logic, Language; Information. Ross, John R. 1985. “The Source of Pseudocleft Sentences.” Handout of a talk given at New York University. Russell, Bertrand. 2001. “Descriptions.” In _The Philosophy of Language_, edited by A. P. Martinich, Fourth, 221–27. Oxford University Press. Väänäänen, Jouko. 2011. _Models and Games_. Vol. 132. Cambridge Studies in Advanced Mathematics. Cambridge University Press. [-- Attachment #5: Test document rendered as HTML --] [-- Type: text/html, Size: 12689 bytes --] [-- Attachment #6: Test document rendered as ODT --] [-- Type: application/vnd.oasis.opendocument.text, Size: 12730 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --] On Saturday, 28 Mar 2015 at 10:53, Richard Lawrence wrote: > Hi everyone, > > I thought I should send an update to let you know that org-citeproc [1], > the command-line citation processing tool I've been working on, now > supports multi-cites. I believe that means it is now capable of > processing all citations in the basic citation syntax. It can output > plain text, HTML, and ODT (and a Pandoc native format, mostly useful for > debugging). This looks really good! Thanks. However, for some reason, libreoffice doesn't display the citations in the ODT document you have included. I have had a look at the actual ODT file and it looks fine. Can you suggest what may be wrong? I'm attaching a crop of a screenshot to illustrate what I mean. Highlighted is where I would have expected to see some text for the citation. A second question: what will be required to use the new cite syntax with LaTeX/PDF which will remain my main target for export? Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-820-gd92ef9 [-- Attachment #2: screendump-20150331091550.png --] [-- Type: image/png, Size: 38029 bytes --]
Hi Eric and all, Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Saturday, 28 Mar 2015 at 10:53, Richard Lawrence wrote: >> I thought I should send an update to let you know that org-citeproc [1], >> the command-line citation processing tool I've been working on, now >> supports multi-cites. I believe that means it is now capable of >> processing all citations in the basic citation syntax. It can output >> plain text, HTML, and ODT (and a Pandoc native format, mostly useful for >> debugging). > > This looks really good! Thanks. Thanks! > However, for some reason, libreoffice doesn't display the citations in > the ODT document you have included. I have had a look at the actual ODT > file and it looks fine. Can you suggest what may be wrong? Hmm, you're right. I don't have LibreOffice on the machine where I am working on org-citeproc, but I tested it on another machine (OS X, LibreOffice version 4.2.8.2 I think), and the citation text is indeed missing. As you say, the actual file looks fine to me, and it displays correctly on Google Drive (which is where I originally tested the output). So LibreOffice might be where the problem is. That doesn't mean there isn't a problem with org-citeproc, or the ODT exporter, but given that the file looks fine and another viewer handles it correctly, LibreOffice would be my first suspect. I don't really know anything about the ODT format, though. My code more-or-less blindly pastes Pandoc-generated XML into the document during Org ODT export. Can someone who knows more about the format take a look at the file and see if there is some subtle problem I'm not noticing? > A second question: what will be required to use the new cite syntax with > LaTeX/PDF which will remain my main target for export? I think this needs more discussion, actually. The citation syntax can basically be mapped directly to BibLaTeX syntax, so generating LaTeX that will be processed with BibLaTeX is a simple and straightforward modification to Org's LaTeX exporter, and compiling the exported document should continue to require no external programs except the LaTeX distribution itself. That is, `C-c C-e l whatever' should continue to be all that is needed from a user's perspective, plus or minus some LATEX_HEADER setup. However, there are a couple of other scenarios to think about: 1) Some people may still need to use plain BibTeX. Generating LaTeX that is intended to be processed with BibTeX, as opposed to BibLaTeX, is a little trickier, because (IIUC) BibTeX does not support multi-cite citations. Also, I don't know how easy it would be to capture the other features of citations (e.g., the in-text vs. parenthetical distinction) without relying on a package like natbib. If generating BibTeX-compatible LaTeX is needed, is it OK to rely on such a package? 2) Some people might find it useful *not* to generate LaTeX citation commands, and instead have a tool like org-citeproc process citations instead, with the exporter inserting the rendered output into the document. This could be useful if e.g. you are preparing to submit to a journal that provides a CSL file, but not a BibTeX or BibLaTeX style. If either of these scenarios represents an important use case, it will be more work to implement. I suggest that for now we just target BibLaTeX, but I'd like to hear from other people about whether there's reason to do more than that. Best, Richard
Richard Lawrence <richard.lawrence@berkeley.edu> writes: > However, there are a couple of other scenarios to think about: > > 1) Some people may still need to use plain BibTeX. Generating LaTeX > that is intended to be processed with BibTeX, as opposed to BibLaTeX, is > a little trickier, because (IIUC) BibTeX does not support multi-cite > citations. I know next to nothing about citations in general, so please bear with me: if multi-cite support means being able to condense citations (e.g. [1-3, 5, 9]), then bibtex can do at least some of that (e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/). > Also, I don't know how easy it would be to capture the other > features of citations (e.g., the in-text vs. parenthetical distinction) > without relying on a package like natbib. If generating > BibTeX-compatible LaTeX is needed, is it OK to rely on such a package? > IMO yes. Nick
Aloha all, Nick Dokos <ndokos@gmail.com> writes: > Richard Lawrence <richard.lawrence@berkeley.edu> writes: > >> However, there are a couple of other scenarios to think about: >> >> 1) Some people may still need to use plain BibTeX. Generating LaTeX >> that is intended to be processed with BibTeX, as opposed to BibLaTeX, is >> a little trickier, because (IIUC) BibTeX does not support multi-cite >> citations. > > I know next to nothing about citations in general, so please bear with > me: if multi-cite support means being able to condense citations (e.g. > [1-3, 5, 9]), then bibtex can do at least some of that > (e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/). Multiple citations with natbib are limited in the sense that individual citations within them don't carry pre- and post-notes. BibLaTeX does away with this restriction. >> Also, I don't know how easy it would be to capture the other >> features of citations (e.g., the in-text vs. parenthetical distinction) >> without relying on a package like natbib. If generating >> BibTeX-compatible LaTeX is needed, is it OK to rely on such a package? >> > > IMO yes. IMO yes, too. The org-export-cite-add-citation-mode-latex function that Aaron Ecay wrote allows the author to choose (implicitly) which package to use. I like this design because it can accommodate new packages without changes to the Org mode code. ,------------------------------------------------------------------------- | Your comment inspired me to implement | org-export-cite-add-citation-mode-latex in the experimental citation | support I just pushed. So you can do: | | (org-export-cite-add-citation-mode-latex "tsd" | "\\mycitecommand[%s][%s]{%s}" "\\myparencitecommand[%s][%s]{%s}") | | Add to your document: | | #+CITATION_MODE: tsd | | And citations should just work with your chosen commands. I’m sure when | advanced citation support comes along (whether from subtypes or plists), | a similarly simple wrapper can be implemented. `------------------------------------------------------------------------- I haven't found time to experiment with the citation developments or to read through the developing code base. Was this feature of Aaron's experimental support subsequently dropped? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
On Tuesday, 31 Mar 2015 at 12:13, Richard Lawrence wrote: > Hi Eric and all, > > Eric S Fraga <e.fraga@ucl.ac.uk> writes: [...] >> However, for some reason, libreoffice doesn't display the citations in >> the ODT document you have included. I have had a look at the actual ODT >> file and it looks fine. Can you suggest what may be wrong? > > Hmm, you're right. I don't have LibreOffice on the machine where I am > working on org-citeproc, but I tested it on another machine (OS X, > LibreOffice version 4.2.8.2 I think), and the citation text is indeed > missing. Thanks for confirming this. At least it's not me! I hope somebody can figure out what is going on here. [...] >> A second question: what will be required to use the new cite syntax with >> LaTeX/PDF which will remain my main target for export? > > I think this needs more discussion, actually. > > The citation syntax can basically be mapped directly to BibLaTeX syntax, > so generating LaTeX that will be processed with BibLaTeX is a simple and > straightforward modification to Org's LaTeX exporter, and compiling the Although I normally use bibtex, I am happy moving to biblatex if it means unifying org's citation approaches. I don't need the extra features (e.g. multicite) in practice but I'm also not attached to bibtex. thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-921-gfd8c84
Hi Tom and all, tsd@tsdye.com (Thomas S. Dye) writes: >> I know next to nothing about citations in general, so please bear with >> me: if multi-cite support means being able to condense citations (e.g. >> [1-3, 5, 9]), then bibtex can do at least some of that >> (e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/). > > Multiple citations with natbib are limited in the sense that individual > citations within them don't carry pre- and post-notes. BibLaTeX does > away with this restriction. Just to clarify: our syntax allows both pre- and post-notes for each individual reference within a citation, plus common pre- and post-notes for the citation as a whole. Is it only the latter which BibTeX does not support? Or is it also that it can't handle pre- and post-notes for individual references when there is more than one work cited? I don't think I've ever tried to do something that complicated with plain BibTeX. (Also, do you think it is important to support plain BibTeX at all? It seems like we should not bother with this problem unless it's important for a lot of people. I personally would be fine with just targeting BibLaTeX, and it sounds like Eric would be too.) > The org-export-cite-add-citation-mode-latex function that Aaron Ecay > wrote allows the author to choose (implicitly) which package to use. I > like this design because it can accommodate new packages without changes > to the Org mode code. > > ,------------------------------------------------------------------------- > | Your comment inspired me to implement > | org-export-cite-add-citation-mode-latex in the experimental citation > | support I just pushed. So you can do: > | > | (org-export-cite-add-citation-mode-latex "tsd" > | "\\mycitecommand[%s][%s]{%s}" "\\myparencitecommand[%s][%s]{%s}") > | > | Add to your document: > | > | #+CITATION_MODE: tsd > | > | And citations should just work with your chosen commands. I’m sure when > | advanced citation support comes along (whether from subtypes or plists), > | a similarly simple wrapper can be implemented. > `------------------------------------------------------------------------- > > I haven't found time to experiment with the citation developments or to > read through the developing code base. Was this feature of Aaron's > experimental support subsequently dropped? No, I haven't touched that part of the code, and as far as I know that should still work. However, I also haven't been able to make sense of how the CITATION_MODE and CITATION_STYLE keywords should work in non-LaTeX backends, so my code doesn't make any use of them, either. If I understand correctly, the mode and the style are two pieces of information that jointly determine how citations should be formatted. The reason they are separated is that you can have multiple styles associated with a mode (or is it the other way around?). Is it right to say that in LaTeX, choosing a mode and a style determines both which citation commands are available and what their behavior is? In the CSL world, both of these pieces of information seem to be determined by the choice of CSL stylesheet. Thus, I went with a single keyword, CSL_FILE, to specify this information. I guess one could also go the other way, and try to select a stylesheet based on CITATION_MODE and CITATION_STYLE, but I wasn't sure how to do that. I also don't really know if it would be useful to provide a notion of `custom modes' outside of LaTeX; as far as I can see, all customization would just come down to selecting a different stylesheet. But maybe I'm missing something important? Best, Richard
Richard Lawrence <richard.lawrence@berkeley.edu> writes:
> I don't really know anything about the ODT format, though. My code
> more-or-less blindly pastes Pandoc-generated XML into the document
> during Org ODT export. Can someone who knows more about the format take
> a look at the file and see if there is some subtle problem I'm not
> noticing?
I can't test your code 'cause I, for personal/silly reasons, refuse to
spend any more dealing with compiling Haskell.
That being said, my gut feeling is that you have to define the data
elsewhere.
For example, to add a (sub)title to a odt document the field/keyword is
defined in a file different from contents.xml and will just not be printed
if used in contents.xml only.
Also, the bibliography is not "correct" in the sense that if it was setup
in the right semantic way, it would be gray in LO, like the TOC.
—Rasmus
--
Bang bang
Richard Lawrence <richard.lawrence@berkeley.edu> writes: > Hi Tom and all, > > tsd@tsdye.com (Thomas S. Dye) writes: > >>> I know next to nothing about citations in general, so please bear with >>> me: if multi-cite support means being able to condense citations (e.g. >>> [1-3, 5, 9]), then bibtex can do at least some of that >>> (e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/). >> >> Multiple citations with natbib are limited in the sense that individual >> citations within them don't carry pre- and post-notes. BibLaTeX does >> away with this restriction. > > Just to clarify: our syntax allows both pre- and post-notes for each > individual reference within a citation, plus common pre- and post-notes > for the citation as a whole. Is it only the latter which BibTeX does > not support? Or is it also that it can't handle pre- and post-notes for > individual references when there is more than one work cited? I don't > think I've ever tried to do something that complicated with plain BibTeX. IIUC, plain BibTeX just supports \cite, and it was the natbib style that introduced parenthetical, \citep, and text, \citet, citation commands. The corresponding commands in BibLaTeX styles are \parencite and \textcite. With natbib, it is possible to give a pre-note and a post-note to the citation as a whole, but not to individual citations within it. In order to support your syntax fully, I think BibLaTeX is needed. > (Also, do you think it is important to support plain BibTeX at all? It > seems like we should not bother with this problem unless it's important > for a lot of people. I personally would be fine with just targeting > BibLaTeX, and it sounds like Eric would be too.) Well, one benefit of Aaron's function was to make this choice superfluous, both now and in the future. It binds the two citation commands you've implemented to citation commands implemented in CITATION_STYLE. As Aaron notes, it should be easy to modify this (to bind additional commands) when advanced citation support comes along. >> The org-export-cite-add-citation-mode-latex function that Aaron Ecay >> wrote allows the author to choose (implicitly) which package to use. I >> like this design because it can accommodate new packages without changes >> to the Org mode code. >> >> ,------------------------------------------------------------------------- >> | Your comment inspired me to implement >> | org-export-cite-add-citation-mode-latex in the experimental citation >> | support I just pushed. So you can do: >> | >> | (org-export-cite-add-citation-mode-latex "tsd" >> | "\\mycitecommand[%s][%s]{%s}" "\\myparencitecommand[%s][%s]{%s}") >> | >> | Add to your document: >> | >> | #+CITATION_MODE: tsd >> | >> | And citations should just work with your chosen commands. I’m sure when >> | advanced citation support comes along (whether from subtypes or plists), >> | a similarly simple wrapper can be implemented. >> `------------------------------------------------------------------------- >> >> I haven't found time to experiment with the citation developments or to >> read through the developing code base. Was this feature of Aaron's >> experimental support subsequently dropped? > > No, I haven't touched that part of the code, and as far as I know that > should still work. However, I also haven't been able to make sense of > how the CITATION_MODE and CITATION_STYLE keywords should work in > non-LaTeX backends, so my code doesn't make any use of them, either. IIUC, CITATION_STYLE refers to the bibliography style file. CITATION_MODE makes it possible for an author using your syntax to get away from the Harvard mode citations that seem to be your target and use another mode such as the footnote citations common in the humanities. > If I understand correctly, the mode and the style are two pieces of > information that jointly determine how citations should be formatted. > The reason they are separated is that you can have multiple styles > associated with a mode (or is it the other way around?). Is it right to > say that in LaTeX, choosing a mode and a style determines both > which citation commands are available and what their behavior is? Typically, a bibliography style file defines several citation commands, which might belong to one or more modes. It sounds to me as if the CSL world conflates styles and modes, but I haven't looked closely. > In the CSL world, both of these pieces of information seem to be > determined by the choice of CSL stylesheet. Thus, I went with a single > keyword, CSL_FILE, to specify this information. I guess one could also > go the other way, and try to select a stylesheet based on CITATION_MODE > and CITATION_STYLE, but I wasn't sure how to do that. I also don't > really know if it would be useful to provide a notion of `custom modes' > outside of LaTeX; as far as I can see, all customization would just come > down to selecting a different stylesheet. But maybe I'm missing > something important? I think you might be able to merge CSL_FILE and CITATION_STYLE, since they both point to a style file. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Hi,
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Tuesday, 31 Mar 2015 at 12:13, Richard Lawrence wrote:
>> Hi Eric and all,
>>
>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
> [...]
>
>>> However, for some reason, libreoffice doesn't display the citations in
>>> the ODT document you have included. I have had a look at the actual ODT
>>> file and it looks fine. Can you suggest what may be wrong?
>>
>> Hmm, you're right. I don't have LibreOffice on the machine where I am
>> working on org-citeproc, but I tested it on another machine (OS X,
>> LibreOffice version 4.2.8.2 I think), and the citation text is indeed
>> missing.
>
> Thanks for confirming this. At least it's not me! I hope somebody
> can figure out what is going on here.
>
> [...]
>
>>> A second question: what will be required to use the new cite syntax with
>>> LaTeX/PDF which will remain my main target for export?
>>
>> I think this needs more discussion, actually.
>>
>> The citation syntax can basically be mapped directly to BibLaTeX syntax,
>> so generating LaTeX that will be processed with BibLaTeX is a simple and
>> straightforward modification to Org's LaTeX exporter, and compiling the
>
> Although I normally use bibtex, I am happy moving to biblatex if it
> means unifying org's citation approaches. I don't need the extra
> features (e.g. multicite) in practice but I'm also not attached to
> bibtex.
I am a happy biblatex user for all my 'own' documents. But (as was
mentioned previously) scientific journals that accept latex submissions
will require bibtex and won't support biblatex. So, I'd say that one of
the other methods (preferably bibtex) is still necessary.
Regards,
Andreas
Rasmus <rasmus@gmx.us> writes: > Richard Lawrence <richard.lawrence@berkeley.edu> writes: > >> I don't really know anything about the ODT format, though. My code >> more-or-less blindly pastes Pandoc-generated XML into the document >> during Org ODT export. Can someone who knows more about the format take >> a look at the file and see if there is some subtle problem I'm not >> noticing? > > I can't test your code 'cause I, for personal/silly reasons, refuse to > spend any more dealing with compiling Haskell. Fair enough. :) > That being said, my gut feeling is that you have to define the data > elsewhere. > > For example, to add a (sub)title to a odt document the field/keyword is > defined in a file different from contents.xml and will just not be printed > if used in contents.xml only. Hmm. But the citations are all just represented as <text:p> nodes...surely that doesn't have to be defined elsewhere? I am now guessing that the problem is that you can't have one <text:p> inside another. Each paragraph is wrapped in a <text:p>, but so are the citations within it...maybe that is not correct and so LibreOffice doesn't like it. > Also, the bibliography is not "correct" in the sense that if it was setup > in the right semantic way, it would be gray in LO, like the TOC. Do you know what other markup is required in this case? It looks like maybe the TOC is gray because it is marked with a "text:protected" attribute, or maybe because it has an associated "OrgIndexSection" style? Thanks! Best, Richard
Hi Tom and all, Thanks for answering my questions! tsd@tsdye.com (Thomas S. Dye) writes: > With natbib, it is possible to give a pre-note and a post-note to the > citation as a whole, but not to individual citations within it. In > order to support your syntax fully, I think BibLaTeX is needed. OK, good to know. >> (Also, do you think it is important to support plain BibTeX at all? It >> seems like we should not bother with this problem unless it's important >> for a lot of people. I personally would be fine with just targeting >> BibLaTeX, and it sounds like Eric would be too.) > > Well, one benefit of Aaron's function was to make this choice > superfluous, both now and in the future. It binds the two citation > commands you've implemented to citation commands implemented in > CITATION_STYLE. As Aaron notes, it should be easy to modify this (to > bind additional commands) when advanced citation support comes along. I think I have to retract what I said earlier: I doubt this part of Aaron's code still works in my branch, because I think Aaron was assuming citation objects contain just one reference; in my branch, I've merged in the parser support Nicolas later implemented for multi-cite citations. So a CITATION_MODE needs to know how to turn a list of works, each with associated prefix and suffix data, into a complete citation command. This complicates things enough that probably custom citation modes should be defined as Lisp functions, rather than via format strings...what do you think? I'm still having a hard time seeing what an analogous customization would look like for non-LaTeX backends. The LaTeX exporter is unique in that Org produces output which must then be further processed by another tool, so having customizable control over how a citation `looks' to that tool makes sense. But in other backends, the Org exporter itself produces the final document; there's no intermediate representation besides Org's own, plus whatever arguments are passed to a citation processing tool like org-citeproc. So, if that's right, the analogous customization in a non-LaTeX backend would be something like a filter, one that pre-processes citation objects before they are run through the external tool, or that post-processes the strings that come back (or both). Does that make sense? Certainly, both of those things are possible. > Typically, a bibliography style file defines several citation commands, > which might belong to one or more modes. ... > I think you might be able to merge CSL_FILE and CITATION_STYLE, since > they both point to a style file. OK, I see, that makes things clearer. Would it make sense to have two keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the style can vary independently when exporting to LaTeX vs. non-LaTeX? I'm thinking it will be tricky to come up with a single set of values for a CITATION_STYLE keyword that can be correctly mapped to both kinds of backend. Or maybe CITATION_STYLE should have "sub"-keywords, like #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl or something similar? Best, Richard
Aloha Richard, Richard Lawrence <richard.lawrence@berkeley.edu> writes: > Hi Tom and all, > > Thanks for answering my questions! > > tsd@tsdye.com (Thomas S. Dye) writes: > >> With natbib, it is possible to give a pre-note and a post-note to the >> citation as a whole, but not to individual citations within it. In >> order to support your syntax fully, I think BibLaTeX is needed. > > OK, good to know. > >>> (Also, do you think it is important to support plain BibTeX at all? It >>> seems like we should not bother with this problem unless it's important >>> for a lot of people. I personally would be fine with just targeting >>> BibLaTeX, and it sounds like Eric would be too.) >> >> Well, one benefit of Aaron's function was to make this choice >> superfluous, both now and in the future. It binds the two citation >> commands you've implemented to citation commands implemented in >> CITATION_STYLE. As Aaron notes, it should be easy to modify this (to >> bind additional commands) when advanced citation support comes along. > > I think I have to retract what I said earlier: I doubt this part of > Aaron's code still works in my branch, because I think Aaron was > assuming citation objects contain just one reference; in my branch, I've > merged in the parser support Nicolas later implemented for multi-cite > citations. So a CITATION_MODE needs to know how to turn a list of > works, each with associated prefix and suffix data, into a complete > citation command. > > This complicates things enough that probably custom citation modes > should be defined as Lisp functions, rather than via format > strings...what do you think? > > I'm still having a hard time seeing what an analogous customization > would look like for non-LaTeX backends. The LaTeX exporter is unique in > that Org produces output which must then be further processed by another > tool, so having customizable control over how a citation `looks' to that > tool makes sense. But in other backends, the Org exporter itself > produces the final document; there's no intermediate representation > besides Org's own, plus whatever arguments are passed to a citation > processing tool like org-citeproc. So, if that's right, the analogous > customization in a non-LaTeX backend would be something like a filter, > one that pre-processes citation objects before they are run through the > external tool, or that post-processes the strings that come back (or > both). Does that make sense? Certainly, both of those things are > possible. Yes, I think an export filter would work for LaTeX. The general form for BibLaTeX is: \cites(⟨multiprenote⟩)(⟨multipostnote⟩)[⟨prenote⟩][⟨postnote⟩]{⟨key⟩}...[⟨prenote⟩][⟨postnote⟩]{⟨key⟩} where \cites can also be \parencites, \textcites, etc. For natbib it is: \cite[⟨prenote⟩][⟨postnote⟩]{⟨key⟩,...⟨key⟩} where \cite can also be \citep, \citet, etc. >> Typically, a bibliography style file defines several citation commands, >> which might belong to one or more modes. ... >> I think you might be able to merge CSL_FILE and CITATION_STYLE, since >> they both point to a style file. > > OK, I see, that makes things clearer. Would it make sense to have two > keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the > style can vary independently when exporting to LaTeX vs. non-LaTeX? I'm > thinking it will be tricky to come up with a single set of values for a > CITATION_STYLE keyword that can be correctly mapped to both kinds of > backend. Or maybe CITATION_STYLE should have "sub"-keywords, like > > #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl Won't the backends sort this out without the additional mapping? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --] Hi, Richard Lawrence <richard.lawrence@berkeley.edu> writes: >> That being said, my gut feeling is that you have to define the data >> elsewhere. >> >> For example, to add a (sub)title to a odt document the field/keyword is >> defined in a file different from contents.xml and will just not be printed >> if used in contents.xml only. > > Hmm. But the citations are all just represented as <text:p> > nodes...surely that doesn't have to be defined elsewhere? You are right. Also, oolatex inserts citations as plain text as well. As I recall, it can be done "semantically" and section 6.3 of the odt standard suggest that this may be true, but it's not immediately obvious how to do it. > I am now guessing that the problem is that you can't have one <text:p> > inside another. Each paragraph is wrapped in a <text:p>, but so are the > citations within it...maybe that is not correct and so LibreOffice > doesn't like it. I don't think <text:p> can be nested cf. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415138_253892949 >> Also, the bibliography is not "correct" in the sense that if it was setup >> in the right semantic way, it would be gray in LO, like the TOC. > > Do you know what other markup is required in this case? It looks like > maybe the TOC is gray because it is marked with a "text:protected" > attribute, or maybe because it has an associated "OrgIndexSection" > style? It has to be formatted as a bibliography. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_bibliography I've attached a minimal oolatex example (mk4ht oolatex test.tex) of \documentclass{article} \usepackage[english]{babel} \usepackage[authordate]{biblatex-chicago} \addbibresource{~/documents/literature/lit.bib} \begin{document} before \textcite[pre][post]{schulte12} and after \printbibliography \end{document} Hope it helps, Rasmus -- . . . The proofs are technical in nature and provides no real understanding [-- Attachment #2: test.odt --] [-- Type: application/vnd.oasis.opendocument.text, Size: 7527 bytes --]
On Wednesday, 1 Apr 2015 at 08:49, Andreas Leha wrote:
[...]
> I am a happy biblatex user for all my 'own' documents. But (as was
> mentioned previously) scientific journals that accept latex submissions
> will require bibtex and won't support biblatex. So, I'd say that one of
> the other methods (preferably bibtex) is still necessary.
Ahhh, yes, I'd forgotten that journals expect bibtex. This is a key
requirement for me as well therefore.
Thanks,
eric
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-921-gfd8c84
Hi Eric and all,
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Wednesday, 1 Apr 2015 at 08:49, Andreas Leha wrote:
>
> [...]
>
>> I am a happy biblatex user for all my 'own' documents. But (as was
>> mentioned previously) scientific journals that accept latex submissions
>> will require bibtex and won't support biblatex. So, I'd say that one of
>> the other methods (preferably bibtex) is still necessary.
>
> Ahhh, yes, I'd forgotten that journals expect bibtex. This is a key
> requirement for me as well therefore.
Can someone suggest how a parenthetical citation with common prefix and
suffix data, like
[(cite): For more on this topic, see:; @Work1 for a review; @Work2;
and references therein.]
should map to plain BibTeX? Maybe there is no general answer to this
question, but what would a reasonable default be? Maybe this?
(For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
and references therein.)
That is, just place the prefix and suffix data in the surrounding text,
inserting commas after the part for each individual work, and wrapping
the whole thing in parentheses?
Thanks!
Best,
Richard
Hi Rasmus, Thanks, this is helpful. I will try to fix these things soon. Rasmus <rasmus@gmx.us> writes: > >> Hmm. But the citations are all just represented as <text:p> >> nodes...surely that doesn't have to be defined elsewhere? > > You are right. Also, oolatex inserts citations as plain text as well. As > I recall, it can be done "semantically" and section 6.3 of the odt > standard suggest that this may be true, but it's not immediately obvious > how to do it. > >> I am now guessing that the problem is that you can't have one <text:p> >> inside another. Each paragraph is wrapped in a <text:p>, but so are the >> citations within it...maybe that is not correct and so LibreOffice >> doesn't like it. > > I don't think <text:p> can be nested cf. > > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415138_253892949 OK, good to know. Looks like <text:reference-mark> or <text:note> might be the way to go. >>> Also, the bibliography is not "correct" in the sense that if it was setup >>> in the right semantic way, it would be gray in LO, like the TOC. >> >> Do you know what other markup is required in this case? It looks like >> maybe the TOC is gray because it is marked with a "text:protected" >> attribute, or maybe because it has an associated "OrgIndexSection" >> style? > > It has to be formatted as a bibliography. > > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_bibliography > Also useful. This might take a while for me to figure out, as Pandoc does not seem to generate this markup when formatting a bibliography...maybe I'll see if they are willing to work on this upstream. Best, Richard
Hi Richard, hi all, First of all, thanks very much for your work! I’ve been (barely) following this discussion, but have been too busy to do any actual coding. I sat down today to try to integrate Richard’s branch with my work, but didn’t get very far. I think it would be a waste of effort to try to support more than one citation processor (citeproc-java vs. org-citeproc). I went round and round with myself about this, and concluded that we ought to keep on working on the org-citeproc approach for now (drop citeproc-java). But I do think someone eventually ought to reimplement org-citeproc based on citeproc-js, to yield something that can be distributed via npm. This will be less fool-proof than java, but better than the Haskell experience for many users (such as Rasmus and me – far from non-technical people!). You mention zotero as a third option – it’s possible, but I think we’d be better served by a tool that focuses solely on processing and is not so closely tied with database management. There are a couple of other differences in our approaches. The first is whether the processor generates the in-text citations (you) or whether it’s done in elisp (me). It’s not obvious which is superior. The real test will come when more diverse citation types are implemented (e.g. full citations in footnotes or numbers which reference a numbered bibliography at the end of the document). The second is whether the processor generates markup in the target language directly (you) or whether the processor’s output is converted to org markup, then passed through org’s exporters (me). I think my approach here is preferable, since it generalizes to every backend. Do you think something like this could work for org-citeproc? It would probably require some additional special code in ox-odt. (But we might need that in any case, see below.) It would be good from an intelligibility/maintainability perspective if you could use the json.el library rather than generating json strings by hand. This is part of the emacs core since version 23.something, so compatibility should not be a big issue. You wrote (mixing replies to various emails in this thread): > This complicates things enough that probably custom citation modes > [in Latex – AE] should be defined as Lisp functions, rather than via > format strings...what do you think? I’d rather avoid it, since I think org->latex is going to be an important usecase for many people. I see us eventually supporting two flavors of latex output. The first should aim to generate a full set of biblatex commands but with little user customizability. The second will rely on just 2 citation commands (paren and non-paren), plus some elisp routines for combining them into multicites etc. These two cite commands then can be customized by the user. If people need more flexibility but cannot use biblatex, they can always hack up a custom exporter for themselves. But I think we ought to support relatively simple needs with simple configuration settings. > OK, I see, that makes things clearer. Would it make sense to have two > keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the > style can vary independently when exporting to LaTeX vs. non-LaTeX? Yes. > I'm thinking it will be tricky to come up with a single set of values > for a CITATION_STYLE keyword that can be correctly mapped to both > kinds of backend. I agree. > Or maybe CITATION_STYLE should have "sub"-keywords, like > > #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl This is equivalent (up to bikeshedding) to separate keywords. I’d like the bikeshed painted with separate keywords, though, because that leaves room for passing additional options to biblatex (to be added to the \usepackage and/or \printbibliography commands). > Can someone suggest how a parenthetical citation with common prefix and > suffix data, like > > [(cite): For more on this topic, see:; @Work1 for a review; @Work2; > and references therein.] > > should map to plain BibTeX? Maybe there is no general answer to this > question, but what would a reasonable default be? Maybe this? > > (For more on this topic, see: \cite{Work1} for a review, \cite{Work2}, > and references therein.) > > That is, just place the prefix and suffix data in the surrounding text, > inserting commas after the part for each individual work, and wrapping > the whole thing in parentheses? I agree. (This is like the second flavor of latex support I described above.) > Also useful. This might take a while for me to figure out, as Pandoc > does not seem to generate this markup when formatting a > bibliography...maybe I'll see if they are willing to work on this > upstream. I think we should not rely on pandoc to fix this for us. It makes it harder to move away from Haskell if (when) we want to. I used up all the time I had today to understanding the code and surrounding conceptual issues. However, I will try to integrate your changes with my branch sometime in the next few days-week. Thanks again, -- Aaron Ecay
Hi Tom and all,
tsd@tsdye.com (Thomas S. Dye) writes:
>> OK, I see, that makes things clearer. Would it make sense to have two
>> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
>> style can vary independently when exporting to LaTeX vs. non-LaTeX? I'm
>> thinking it will be tricky to come up with a single set of values for a
>> CITATION_STYLE keyword that can be correctly mapped to both kinds of
>> backend. Or maybe CITATION_STYLE should have "sub"-keywords, like
>>
>> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl
>
> Won't the backends sort this out without the additional mapping?
Surely they could, but I guess I'm unclear on how that should happen.
Org could keep a variable mapping citation styles to default values for
the respective backends, like:
(defcustom org-cite-citation-styles
'(("author-year" (biblatex-pkg-args "citestyle=authoryear,bibstyle=authoryear")
(csl-file "/path/to/chicago-author-date.csl"))
...))
so in a document, you could just write
#+CITATION_STYLE: author-year
or similar. Is this what you have in mind?
That seems like a good way to provide reasonable defaults using a
high-level label. But I think using a high-level label like this will
underdetermine the actual style to use (on both sides, I assume); and
the problem is that if we make the labels more fine-grained, there's no
longer any guarantee that, for a given style label, a suitable style
file will be available on both LaTeX and non-LaTeX backends.
There obviously needs to be some mechanism so authors can specify their
citation style quite precisely for the backends they are interested in.
(Maybe just customizing this variable would do the trick.) But what
should the fallback mechanism look like when a particular style does not
specify the required information for a given export backend? E.g., if
CITATION_STYLE is X and we're exporting to HTML, but the entry in
org-cite-citation-styles does not specify a CSL file for style X? Would
it be enough to have a single 'default clause or similar in
org-cite-citation-styles to use in that kind of case?
Best,
Richard
Hi Richard, Richard Lawrence <richard.lawrence@berkeley.edu> writes: > Hi Tom and all, > > tsd@tsdye.com (Thomas S. Dye) writes: > >>> OK, I see, that makes things clearer. Would it make sense to have two >>> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the >>> style can vary independently when exporting to LaTeX vs. non-LaTeX? I'm >>> thinking it will be tricky to come up with a single set of values for a >>> CITATION_STYLE keyword that can be correctly mapped to both kinds of >>> backend. Or maybe CITATION_STYLE should have "sub"-keywords, like >>> >>> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl >> >> Won't the backends sort this out without the additional mapping? > > Surely they could, but I guess I'm unclear on how that should happen. > > Org could keep a variable mapping citation styles to default values for > the respective backends, like: > > (defcustom org-cite-citation-styles > '(("author-year" (biblatex-pkg-args "citestyle=authoryear,bibstyle=authoryear") > (csl-file "/path/to/chicago-author-date.csl")) > ...)) > > so in a document, you could just write > > #+CITATION_STYLE: author-year > > or similar. Is this what you have in mind? > > That seems like a good way to provide reasonable defaults using a > high-level label. But I think using a high-level label like this will > underdetermine the actual style to use (on both sides, I assume); and > the problem is that if we make the labels more fine-grained, there's no > longer any guarantee that, for a given style label, a suitable style > file will be available on both LaTeX and non-LaTeX backends. > > There obviously needs to be some mechanism so authors can specify their > citation style quite precisely for the backends they are interested in. > (Maybe just customizing this variable would do the trick.) But what > should the fallback mechanism look like when a particular style does not > specify the required information for a given export backend? E.g., if > CITATION_STYLE is X and we're exporting to HTML, but the entry in > org-cite-citation-styles does not specify a CSL file for style X? Would > it be enough to have a single 'default clause or similar in > org-cite-citation-styles to use in that kind of case? I was thinking the author would change CITATION_STYLE to fit the export, but I like your idea of setting up a universal configuration. As for a fallback mechanism, I like your idea of a user-configurable default. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Hi Aaron, Thanks for your comments, and for looking over my code! Aaron Ecay <aaronecay@gmail.com> writes: > I’ve been (barely) following this discussion, but have been too busy to > do any actual coding. I sat down today to try to integrate Richard’s > branch with my work, but didn’t get very far. I think it would be a > waste of effort to try to support more than one citation processor > (citeproc-java vs. org-citeproc). In the long run, I agree, though I still think it might be good in the short term to see how a few different tools behave. > I went round and round with myself about this, and concluded that we > ought to keep on working on the org-citeproc approach for now (drop > citeproc-java). (I take that as a compliment -- thanks! I'm curious as to what persuaded you.) > But I do think someone eventually ought to reimplement org-citeproc > based on citeproc-js, to yield something that can be distributed via > npm. This will be less fool-proof than java, but better than the > Haskell experience for many users (such as Rasmus and me – far from > non-technical people!). That is fine with me, as I think citeproc-js is the canonical implementation, and probably the best supported. I am not the person to do this, though, as I don't really know JavaScript, and personally I have found it rather frustrating to work with whenever I have had to do so. (I am a little puzzled, though, as to why you and Rasmus find the Haskell experience unpalatable. On my machine, I installed the Haskell Platform, and after that, building and installing pandoc, pandoc-citeproc, and other programs via cabal Just Works. Has that not been your experience? Why would instructions like "First install Node.js, then do: $ npm install org-citeproc" be better than "First install the Haskell platform, then do: $ cabal install org-citeproc"?) > You mention zotero as a third option – it’s possible, but I think we’d > be better served by a tool that focuses solely on processing and is > not so closely tied with database management. Yes, I agree, at least for those of us who don't use a citation manager. On the other hand, other people already have Zotero, but would find it difficult to install and configure a command-line tool and supporting platform. If there were a common API so that most of org-cite could operate independently of external tools, but call out to whichever tool was installed at critical moments, I think that would be beneficial from a user's perspective. (That was part of my motivation for representing citations to org-citeproc as citeproc-js-compatible JSON.) I know that would be more work, but it shouldn't lead to too much duplicated effort if we are careful to separate the tool-independent code from the tool-dependent code, and to minimize the latter. It would also make it easier to support new and better tools in the future as they become available. > There are a couple of other differences in our approaches. > > The first is whether the processor generates the in-text citations (you) > or whether it’s done in elisp (me). It’s not obvious which is superior. > The real test will come when more diverse citation types are implemented > (e.g. full citations in footnotes or numbers which reference a numbered > bibliography at the end of the document). > > The second is whether the processor generates markup in the target > language directly (you) or whether the processor’s output is converted > to org markup, then passed through org’s exporters (me). I think my > approach here is preferable, since it generalizes to every backend. Do > you think something like this could work for org-citeproc? It would > probably require some additional special code in ox-odt. (But we might > need that in any case, see below.) Yes, I think that could work, and shouldn't be too hard to achieve, as Pandoc already has an Org writer. And I agree it is probably preferable to go this way. I realized this when I tested org-citeproc with a CSL file for a note-based style; things start to get complicated when you have to parse the output format to look for e.g. a footnote reference and definition. > It would be good from an intelligibility/maintainability perspective if > you could use the json.el library rather than generating json strings by > hand. This is part of the emacs core since version 23.something, so > compatibility should not be a big issue. Ah, ok, I didn't know about json.el. Yes, I agree. > You wrote (mixing replies to various emails in this thread): > >> This complicates things enough that probably custom citation modes >> [in Latex – AE] should be defined as Lisp functions, rather than via >> format strings...what do you think? > > I’d rather avoid it, since I think org->latex is going to be an important > usecase for many people. I see us eventually supporting two flavors of > latex output. The first should aim to generate a full set of biblatex > commands but with little user customizability. The second will rely on > just 2 citation commands (paren and non-paren), plus some elisp routines > for combining them into multicites etc. These two cite commands then can > be customized by the user. > > If people need more flexibility but cannot use biblatex, they can > always hack up a custom exporter for themselves. But I think we ought > to support relatively simple needs with simple configuration settings. Hmm, OK, interesting. To me, this actually seems more complicated, but I guess I am probably not typical. As a fairly technical user I would personally prefer the flexibility of just writing a function that is responsible for taking a citation object and returning an arbitrary string to insert into the output. This seems simpler than worrying about which flavor of latex output I need, and therefore which type of customization is available. But I can see how things would be different for someone who doesn't want to learn enough Elisp to manipulate citation objects. >> Or maybe CITATION_STYLE should have "sub"-keywords, like >> >> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl > > This is equivalent (up to bikeshedding) to separate keywords. I’d like > the bikeshed painted with separate keywords, though, because that leaves > room for passing additional options to biblatex (to be added to the > \usepackage and/or \printbibliography commands). I agree. > I used up all the time I had today to understanding the code and > surrounding conceptual issues. However, I will try to integrate your > changes with my branch sometime in the next few days-week. Alright, I'll try to move to json.el, and possibly change to having org-citeproc generate Org markup in the meantime. Best, Richard
Hi, Aaron Ecay <aaronecay@gmail.com> writes: > I went round and round with myself about this, and concluded that we > ought to keep on working on the org-citeproc approach for now (drop > citeproc-java). But I do think someone eventually ought to reimplement > org-citeproc based on citeproc-js, to yield something that can be > distributed via npm. This will be less fool-proof than java, but better > than the Haskell experience for many users (such as Rasmus and me – far > from non-technical people!). You mention zotero as a third option – > it’s possible, but I think we’d be better served by a tool that focuses > solely on processing and is not so closely tied with database > management. I mostly agree. IMO a non-binary Haskell solution is a non-starter for an "official" solution. A binary version is fine: e.g. I'm more or less happy with git-annex. I'd prefer java over node-js, but I'm less hostile towards npm. Could there be an elisp wrapper around citeproc-js? Likely, org devs would have an easier time maintaining such a beast. > The first is whether the processor generates the in-text citations (you) > or whether it’s done in elisp (me). It’s not obvious which is superior. > The real test will come when more diverse citation types are implemented > (e.g. full citations in footnotes or numbers which reference a numbered > bibliography at the end of the document). IMO externalization is the top priority. After that I think elisp is superior as org-devs presumably would have an easier time maintaining this. >> This complicates things enough that probably custom citation modes >> [in Latex – AE] should be defined as Lisp functions, rather than via >> format strings...what do you think? > > I’d rather avoid it, since I think org->latex is going to be an important > usecase for many people. I see us eventually supporting two flavors of > latex output. The first should aim to generate a full set of biblatex > commands but with little user customizability. The second will rely on > just 2 citation commands (paren and non-paren), plus some elisp routines > for combining them into multicites etc. These two cite commands then can > be customized by the user. E.g. Natbib has primitives such as \citeauthor and \citeyear so arbitrarily complex biblatex citations can always be replicated. >> Also useful. This might take a while for me to figure out, as Pandoc >> does not seem to generate this markup when formatting a >> bibliography...maybe I'll see if they are willing to work on this >> upstream. > > I think we should not rely on pandoc to fix this for us. It makes it > harder to move away from Haskell if (when) we want to. +1 > I used up all the time I had today to understanding the code and > surrounding conceptual issues. However, I will try to integrate your > changes with my branch sometime in the next few days-week. Richard: do your FSF papers in order. Or do you plan to get them in order? —Rasmus -- Send from my Emacs
Hi,
Richard Lawrence <richard.lawrence@berkeley.edu> writes:
> Hi Eric and all,
>
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Wednesday, 1 Apr 2015 at 08:49, Andreas Leha wrote:
>>
>> [...]
>>
>>> I am a happy biblatex user for all my 'own' documents. But (as was
>>> mentioned previously) scientific journals that accept latex submissions
>>> will require bibtex and won't support biblatex. So, I'd say that one of
>>> the other methods (preferably bibtex) is still necessary.
>>
>> Ahhh, yes, I'd forgotten that journals expect bibtex. This is a key
>> requirement for me as well therefore.
>
> Can someone suggest how a parenthetical citation with common prefix and
> suffix data, like
>
> [(cite): For more on this topic, see:; @Work1 for a review; @Work2;
> and references therein.]
>
> should map to plain BibTeX? Maybe there is no general answer to this
> question, but what would a reasonable default be? Maybe this?
>
> (For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
> and references therein.)
>
> That is, just place the prefix and suffix data in the surrounding text,
> inserting commas after the part for each individual work, and wrapping
> the whole thing in parentheses?
>
To me that seems a reasonable thing to do. At least I would write it
probably in such a way.
Depending on the citation style ("author, year") I might add a comma
after the citation, so that it becomes
(For more on this topic, see: Max Mustermann, 2015, for a review,
The Internet Consortium, 2014, and references therein.)
compared to
(For more on this topic, see: Max Mustermann, 2015 for a review,
The Internet Consortium, 2014 and references therein.)
But:
- I am no native English speaker and comma placement in English
is very unclear to me
- my citation requirements are quite low, I guess...
Best,
Andreas
Rasmus <rasmus@gmx.us> writes:
> Richard: do your FSF papers in order. Or do you plan to get them in
> order?
I haven't done them yet (never had a reason to!) but I have no problems
with it and I'll get started on it.
Best,
Richard
Hi Aaron and all,
Richard Lawrence <richard.lawrence@berkeley.edu> writes:
> Alright, I'll try to move to json.el, and possibly change to having
> org-citeproc generate Org markup in the meantime.
Just a heads up: I've pushed some changes to my branch of Org to make
org-cite use json.el, and to add a basic Org format writer to
org-citeproc.
I have not made any other changes to org-cite to use the Org formatted
output from org-citeproc, though, as I believe doing this properly will
involve parsing the output and inserting it into Org's exporter's parse
tree (to accommodate the bibliography and note-based styles). I won't
have time to work on that this week, but I'll come back to it.
Best,
Richard
[-- Attachment #1: Type: text/plain, Size: 3584 bytes --] On Mon, Apr 6, 2015 at 2:51 PM, Richard Lawrence < richard.lawrence@berkeley.edu> wrote: > Hi Aaron and all, > > Richard Lawrence <richard.lawrence@berkeley.edu> writes: > > > Alright, I'll try to move to json.el, and possibly change to having > > org-citeproc generate Org markup in the meantime. > > Just a heads up: I've pushed some changes to my branch of Org to make > org-cite use json.el, and to add a basic Org format writer to > org-citeproc. > > I have not made any other changes to org-cite to use the Org formatted > output from org-citeproc, though, as I believe doing this properly will > involve parsing the output and inserting it into Org's exporter's parse > tree (to accommodate the bibliography and note-based styles). I won't > have time to work on that this week, but I'll come back to it. > > Best, > Richard > > Hi Richard et al, I'm wondering what kind of work is required to make use of org-cite and org-citeproc at present. In particular, I'm wondering what kinds of changes I'll need to make to my current setup, and whether it's worthwhile to use my ultra-slow coding skills to create whatever glue is still necessary. Here's my setup at present: I currently use Zotero for most of my bibliography management; it's relatively easy to get zotero to export a bibtex bibliography (cf. https://github.com/robintw/AutoZotBib), and I will switch to bibtex if absolutely necessary. I'd rather just keep using Zotero, though. I use zotxt-emacs to insert references in org files. I export my work to html and odt. I use this small bit of code to manage exports: ;; zotxt (org-add-link-type "zotero" (lambda (rest) (zotxt-select-key (substring rest 15))) (lambda (path desc format) (if (string-match "^@\\(.*\\)$" desc) (cond ((eq format 'latex) (format "\\cite{%s}" (match-string 1 desc))) ((eq format 'md) desc) ((eq format 'html) (deferred:$ (zotxt-get-item-bibliography-deferred `(:key , (substring path 15))) (deferred:nextc it (lambda (item) (plist-get item :citation-html))) (deferred:sync! it))) ((eq format 'odt) (deferred:$ (zotxt-get-item-deferred `(:key , (substring path 15)) :248bebf1-46ab-4067-9f93-ec3d2960d0cd) (deferred:nextc it (lambda (item) (plist-get item :248bebf1-46ab-4067-9f93-ec3d2960d0cd))) (deferred:sync! it))) (t nil) nil)))) currently this grabs a full html citation and pastes it into the html export, while for odt it produces strings of the form { | Herzig, 2006 | | |zotero://select/items/0_SKDIF737}, which Zotero can understand withthe aid of an RDF/ODF scan plugin. All of this is fine for my current purposes, but I would like to figure out a more flexible and enduring solution, so I'd like to try out org-cite and org-citeproc. But I'm not quite sure what's required, and whether there's support currently for odt and html export. Thanks very much for your help, Matt [-- Attachment #2: Type: text/html, Size: 5448 bytes --]
Hi Matt, Matt Price <moptop99@gmail.com> writes: > I'm wondering what kind of work is required to make use of org-cite and > org-citeproc at present. In particular, I'm wondering what kinds of changes > I'll need to make to my current setup, and whether it's worthwhile to use > my ultra-slow coding skills to create whatever glue is still necessary. At the moment, org-cite/org-citeproc has no way of talking to Zotero. So you'd need to manually export citation data from Zotero to a format that pandoc-citeproc understands, like BibTex. It sounds like zotxt and zotxt-emacs provide a lot of what's needed to glue org-cite together with Zotero; so one thing that would be helpful, if you're up for it, is hacking org-cite to pull bibliography data from Zotero in a format that can be passed to org-citeproc. I don't use Zotero myself, so this is something I'm unlikely to do anytime soon without some help. (Borrowing code from zotxt-emacs and putting it in org-cite is probably the way to go here, as I doubt that we want to make zotxt-emacs a dependency of org-cite.) > All of this is fine for my current purposes, but I would like to figure out > a more flexible and enduring solution, so I'd like to try out org-cite and > org-citeproc. But I'm not quite sure what's required, and whether there's > support currently for odt and html export. `Flexible and enduring' does not describe org-citeproc at the moment. :) I'd be very happy to have you test out org-citeproc and give feedback that will help improve it, but I can't recommend that you rely on it or switch to it for serious work any time soon. It is a working proof-of-concept, but only that. Still, there is support in org-cite/org-citeproc for both HTML and ODT export, and it handles quite a few of the common cases. So let me know if you're interested in trying it out. There are brief installation instructions in the README (https://github.com/wyleyr/org-citeproc); let me know if you need more than that. Best, Richard