5

Some biblatex fields are of type 'literal' and some are of type 'string'. What is the difference between the two types?

Given that 'string' is used for the ID, it would make sense if a string must not have spaces. Is that right? Are there any other restrictions?

Relatedly, are there any restrictions other than no spaces on IDs when using biblatex and/or biber?

  • 2
    Ad 1: Actually, 'fields' are: literal, range, integer, ... (see section 2.2 in general). Fields are distinguished from 'name' and 'literal' lists. These are all used in the basic data model of biblatex for the entry fields. I believe 'string' is used in a generic 'computer science' sense, and means only something like 'a sequence of characters' (like a constant or a variable); it can have spaces. Thus, fields are strings in this sense. Ad 2: yes and no. Ad 3 & 4: Although an entrykey is a string, it cannot have spaces; generally try to stick to plain ASCII, & generally avoid special charcters. – jon May 7 '15 at 21:22
  • @jon Thanks. I was confused by the manual saying things like 'entrykey field (string)'. – twsh May 7 '15 at 21:33
  • 2
    For example, avoid especially @, #, $, %, &, {, }, ", \ , , -- and probably a whole host of other special characters. (I hope the reason is obvious.) Also, it is probably better to use an entry key like godel1931 over gödel1931 -- in BibTeX, it might be necessary to do so. – jon May 7 '15 at 21:37
  • Yeah, I don't think "string" is ever explained, but fields and lists are. – jon May 7 '15 at 21:38
  • What all those "string" fields seem to have in common is that they are produced by the back-end and (in most cases) not intended to be printed in a document. You don't even have control over the majority of those string fields. When it comes to output that is printed, the documentation uses "literal". (Which makes me think that Biber will probably choke on TeX commands being used in "string" fields, but will happily accept them in "literal" fields. See also here.) – moewe May 17 '15 at 16:16
4

A literal field can normally hold text as you would write it in your .tex document. %s are dangerous, but most of everything else should go through without a problem. The documentation is indeed quite tight-lipped about what a 'string' field is. Of the dozen or so fields marked as 'string' in the biblatex documentation only a few are relevant for input in .bib files and even these are special in one way or another. Normally you would not want to print the contents of any of these fields.

  • presort: Since it is used for sorting by the backend it should ideally not contain any fancy stuff like macros and command sequences (they are accepted, but simply treated as a string).
  • entrykey (and by extension ids as well as clonesourcekey, though ids is slightly less restrictive when it comes to round brackets): The possible value for entrykey is on the one hand restricted by the backend and on the other hand by the TeX engine in use. The backend imposes restrictions so that a .bib entry with the respective entrykey may be properly parsed.
    • Biber forbids " # % ' ( ) , = { } (see Using BibTeX keys containing parentheses with Biber, also interesting What characters are allowed to use as delimiters for BibTeX keys?). A space is also forbidden.
    • The TeX/LaTeX side also forbids certain characters so that the entry may be processed on the TeX side. biblatex sometimes needs to build control sequence names from the entrykey (with \csname...\endcsname), so they can't contain unexpandable control sequences. An entrykey should not contain active characters. For pdfLaTeX that means non-ASCII chars such as ä, ö, ß, é are out, XeLaTeX and LuaLaTeX are fine with non-ASCII chars, though.
  • entrytype: Naturally the standard entry types restrict themselves to a-z only. With Biber you could define new types, the restrictions should be similar to those for entrykey.

All other strings are produced by the backend itself and either contain one value of a pre-defined list (dateunspecified) or some sort of hash (hash, namehash, fullhash, sortinithash). You can expect the hashes to return alphanumerical values.

A few fields marked as 'literal' are probably more akin to 'string': labeltitlesource, labelnamesource and extradatescope just return the name of a field. labeldatesource is very similar, but may also contain a literal expression (so I would not classify labeldatesource as string).

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.