Tooling (CSL / arXiv / managers)

A .bib file does not live only inside LaTeX. Around it sits a broad ecosystem: CSL, which governs how citations look; the machinery that pulls bibliographic data automatically from a DOI or arXiv; and the reference managers that grow your .bib over time. This page surveys what happens before and after you write — how to gather, tidy, and emit references.

CSL and citeproc — the world outside biblatex

CSL (Citation Style Language) is an open, XML-based format for describing how citations and bibliographies look. Rules like “surname before given name,” “wrap the year in parentheses,” and “join later authors with an ampersand” are declared in a .csl style file. Each journal’s house style fits into a single such file.

CSL’s great strength is that it is engine-agnostic. Where a BibTeX .bst works only with BibTeX, and a biblatex style only inside LaTeX, CSL is tied to no typesetting system. The actual formatting is done by a citeproc processor: Zotero uses citeproc-js (the JavaScript implementation), while Word plugins and other tools use their own citeproc — all reading the same .csl. So one style file works in Zotero, in Word, and in Markdown alike.

The trove of styles is the Zotero Style Repository — over 8,500 styles (more than 10,000 across the wider community), from journals to conferences, all freely usable under Creative Commons (CC BY-SA). CSL is not Zotero-specific: a .csl you download there will, in most cases, work unchanged in any CSL-aware tool.

The tool that leans on CSL most is pandoc. Write your manuscript in Markdown, convert with --citeproc, and citation keys in the body like [@knuth1984] are replaced with formatted citations, with a reference list appended at the end. The point: you go straight from Markdown to PDF, Word, or HTML with references, without routing through LaTeX’s biblatex.

pandoc paper.md --citeproc \
  --bibliography=refs.bib \
  --csl=ieee.csl \
  -o paper.pdf

You simply hand --bibliography a .bib (or CSL-JSON / RIS) and --csl a style. Omit --csl and it defaults to Chicago author-date. --bibliography may be given more than once, so split .bib files are merged for you. In short, think of pandoc + CSL as the route that lets **even people who never write LaTeX reuse their existing .bib assets**.

biblatex / BibTeX vs CSL

They can take the same .bib as input, but the thing doing the formatting is different. The table below pins down who lives where, so you stop second-guessing “is this LaTeX, or not?”

Either way the input can be the same .bib. The modern stance, then, is to keep the bibliographic database as a shared asset and choose only the output route — LaTeX (biblatex) or CSL (pandoc).

Pulling entries in automatically (DOI, arXiv)

You rarely need to type .bib entries by hand. Most papers carry a DOI, and you can pull BibTeX straight from it. The mechanism is Crossref content negotiation: tell the DOI, via an HTTP header, that you want BibTeX, and the registration agency returns a BibTeX entry.

# DOI から BibTeX を取得（-L でリダイレクト追従）
curl -LH "Accept: application/x-bibtex" \
  "https://doi.org/10.1145/3186893" >> refs.bib

-L is essential. doi.org figures out which registration agency holds the metadata and redirects, so without following redirects you get nothing useful. If the command line feels fussy, paste a DOI into doi2bib.org, which offers the same mechanism on the web (it also accepts arXiv and PubMed IDs).

For an arXiv preprint, the “Export BibTeX citation” link on the right of the abstract page emits BibTeX directly. Crossref (and Google Scholar’s “Cite → BibTeX”) export BibTeX in the same spirit. Whatever the source, the typing effort is close to zero.

But beware: auto-generated entries are rough as-is. Common issues include inconsistent author names, proper nouns in titles being lower-cased (you must protect them with {...}), stray or duplicate fields, mangled math symbols, and confusing the arXiv version with the published one. After importing, give each entry a once-over and normalize the citation key to your own convention — that is part of the job.

Reference managers and auto-exported .bib

Once you reach dozens or hundreds of references, it is practical to handle them in a reference manager. The standard division of labor: collect and organize papers in the app, export a .bib from it, and hand that to LaTeX.

• Zotero — the free, open-source default. One-click capture from the browser, formatting via CSL (citeproc-js). LaTeX users add the Better BibTeX extension for stable citation keys and automatic .bib export.
• Better BibTeX (Zotero extension) — generates clash-free citation keys from patterns like auth.lower + shorttitle(3,3) + year, and keys are always “pinned,” so they never drift. Enable Keep updated on an export and changes to the library flow into the .bib automatically.
• JabRef — a manager that handles BibTeX/biblatex natively. It has no separate internal format and reads/writes .bib as-is. It can also fetch entries from an ID (DOI, arXiv, ISBN).
• BibDesk (macOS) — a BibTeX front-end for the Mac. It edits .bib directly and supports auto-filing of PDFs (AutoFile) and external database searches.
• Mendeley / Paperpile — Mendeley supports BibTeX export; Paperpile is strong on Google Docs integration and can export BibTeX too.

The practical flow is similar everywhere: **(1) manage references in the app → (2) export a .bib (ideally automatically) → (3) load it in LaTeX with \addbibresource{refs.bib} (biblatex) or \bibliography{refs} (BibTeX).** Set up auto-export (as Better BibTeX can) and the manuscript side treats the .bib as an always-current build artifact, with no manual syncing.

One caveat: stable citation keys are the lifeline of collaboration. If keys change on every export, every \cite{...} in the body breaks at once. That is exactly why Better BibTeX fixes keys — and even if you write the .bib by hand without a manager, deciding a key-naming convention up front pays off later.