Bug 371558

Summary:	Dynamic crossref resolution and mapping
Product:	[Applications] KBibTeX	Reporter:	Juergen Spitzmueller <juergen>
Component:	User interface	Assignee:	Thomas Fischer <fischer>
Status:	CONFIRMED ---
Severity:	wishlist	CC:	bugs.kde.org, vini.ipsmaker
Priority:	NOR
Version First Reported In:	git (master)
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Implement dynamic crossref resolution and mapping

Description Juergen Spitzmueller 2016-10-24 07:59:01 UTC

Created attachment 101735 [details]
Implement dynamic crossref resolution and mapping

(Transfered from https://gna.org/bugs/?20407, since GNA does not seem to get attention anymore)

Currently, the crossref resolution is hardcoded to the "crossref" field. However, biblatex also has the field "xdata" which is used in a similar way (note that biblatex's xref field must not be resolved, since it does not inherit fields from the target.). Furthermore, biblatex does not do a 1:1-mapping, but maps fields more cleverly (author > bookauthor etc.).

The attached patch (against branch/0.6) implements this function.

* It dynamically resolves xdata entries (also multiple and nested ones)

* It implements proper crossref field mapping (via the kbstyle file; the syntax should be self-explaining, but is also documented in the source).

I think this patch is a significant improvement for biblatex users.

The patch is the last version I posted over at GNA. I have tested it now in real work for several weeks.

Comment 1 Thomas Fischer 2016-12-11 20:32:14 UTC

Right now, I am prioritizing bugs blocking the release of 0.6. Thus, I have to postpone this bug report for now ...

Comment 2 Juergen Spitzmueller 2017-08-31 16:41:24 UTC

Time to reconsider?

Comment 3 Juergen Spitzmueller 2018-01-20 17:42:23 UTC

There seems to be no interest in this, but for the record, a working implementation (including proper support for XData fields) can be found at https://github.com/jspitz/kbibtex

Note that this depends on a reversion of the hardcoding of bibtex field information done upstream (in other words, I have re-introduced the *.kbstyle files. I think with hardcoded fields, proper biblatex support can never be fully achieved, since biblatex itself allows for adding new fields for specific purposes, a feature that is often used by specific biblatex styles; so we need the possibility to add custom styles in the bibtex editor)