Minimal support for biblatex data annotations

[odneill]

Biblatex defines data annotations, which allow extra information to be added to fields i.e. adding corresponding author marks.

E.g.

@Article{
  author     = {Joe Doe and Mary Jane},
  author+an  = {1=corresponding; 2=highlight},
}

can be used to produce "Doe*, J. & Jane, M", given appropriate formatters for the various annotations.

Currently using \author+an in a .layout results in "Joe Doe and Mary Jane+an" rather than "1=corresponding; 2=highlight".

Minimal support (to access annotation during exports):

• Support in the .layout definitions to handle fields with special characters +:.

Full support would need a scheme for parsing and using this information for formatting in custom .layout files.

[koppor]

@odneill Thank you so much for posting the issue and providing a fix!

Seeing that you work with .layout files, may I ask for your take regarding koppor#392 😅

[odneill]

Hi @koppor, I'll be honest I currently only use layouts in one specific case, which is a bit of a hack anyway - filtering an existing .bib into a "cleaned" .bib with extra fields/ metadata removed. As such I don't have any experience with using the custom formatting/ awareness of the historic choices in the layout system.

From working on this PR I would definitely agree that an established templating engine would improve ease of use and stability. My fix here would break in the case of someone writing a layout which "looks like" a data annotation i.e. something like month=\month:year=\year would look up field month:year. I don't currently have a good solution to this which doesn't break existing layouts, other than relying on it being unlikely syntax.

At minimum in the current system, having a lookup function \lookup{author} as opposed to \author would make parsing more robust. This could be opt in for backwards compatibility, and revert my changes here so you would be required to use the lookup function for fields with special characters, like data annotations.

[koppor]

Hi @odneill. Oh, wow, maybe using JabRef as Java library would even better? This refs #110. Even though our data model is not that perfect, we aimed to have it "optimized" for some custom logic. -- And it is possible to write spaghetti script code with Java code (see https://github.com/koppor/github-contributors-list for an example).

The concrete use case with "filtering" can be achieved using the UI by the mass editing of fields. Unfortunately, the UI is not scriptable.

I think, your use case also might reference #160 😅

[odneill]

@koppor Thanks, all great references. #160 seems like exactly what I mean. I already use JabRef and it was just the quickest way I could get the result I wanted, and it's nice that export filters are scriptable through the CLI. I'm sure there are more elegant methods - always impressed by the rate at which new functionality is added here.