JabRef has an interface for specifying details about a pdf file of the current entry, which looks like this:

Screenshot from JabRef

This results in the following line in the bib file:

  file         = {This is a copy downloaded from foo.com:subdirectory\\foo.pdf:PDF},

How could I embed, say, the first page of a pdf file specified like this into my document as an image file?

(Backslashes are escaped to \\, colons to \:, and semicolons to \;, in the description as well as in the file path.)

I managed to access the contents of the file field with \citefield (or \thefield when I’m in the respective bib entry), but the field still contains the description and the file type. I tried some fiddling around with xstrings and answers from here, but without any mentionable success.

Here’s a MWE as a basis:


% Just to clarify the setup:

\usepackage[backend = biber]{biblatex}


  author       = {Author},
  journaltitle = {Journal},
  title        = {Foo},
  year         = {2016},
  file         = {This is a copy downloaded from foo.com:subdirectory\\foo.pdf:PDF},


% To make sure it’ll compile with images as well:


Use case:

Eventually, I want to use the solution to this problem to produce a bibliography including a reproduction of the nth page of each entry’s file (because the first page of the pdf isn’t always the first page of the article). So the relevant first page would need to be specified somewhere as well, e.g. in the usera field. Currently, I’m printing the pages by manually adding an \includegraphics to each addendum field.

A final solution might be assigning an automatic value to all addendum fields, which would be something like:


Side question:

Is JabRef compyling with the biblatex database standards? The documentation says:

file field (verbatim)

A local link to a pdf or other version of the work. Not used by the standard bibliography styles.

So shouldn’t that field only include the link and no description or anything else? In other words, their way of documenting the file seems rather unhandy for anything other than JabRef’s own file management.

  • 2
    That JabRef format is unfortunate for several reasons. The fact that you can give (presumably) arbitrary comments for the file makes automatic parsing a bit harder (we have to match for a colon, but not just for any colon, because the description might contain a colon - but then (on Windows at least) the file path may contain a colon if you go for absolute paths or maybe none, if you go for relative paths as you did). The fact that JabRef escapes `` makes some backwards-escaping necessary (what else does it escape?). ...
    – moewe
    Sep 11, 2016 at 16:30
  • 2
    ... If we had just a verbatim field that held the path (relative or absolute) and only that things would be a whole lot easier. That said, the file field is probably far from anything that could be considered "standard" (next to no (?) style uses it by default), so we probably can't blame JabRef.
    – moewe
    Sep 11, 2016 at 16:30
  • JabRef escapes semicolons in the description (and file path) with \\;. Thus I would suggest to first replace this expression and then split the text by the semicolon. Not sure how to do this in tex though. (btw, besides the semicolon also commata and backslashes are escaped) Sep 11, 2016 at 17:26
  • True, backslashes are escaped to \\, colons to \:, and semicolons to \; – in the description as well as in the file path, so parsing should be (logically) possible.
    – doncherry
    Sep 11, 2016 at 19:11
  • 1
    The longer I think about it, the more reasonable it seems to me to ask the JabRef people to export just the verbatim bare path to the file field (with no escaping of special chars and no additional comment, if they insist on the comment, they can stuff that into a new field filecomment).
    – moewe
    Sep 15, 2016 at 7:54


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.