On Mon, Apr 25, 2011 at 9:51 AM, Jürgen Spitzmüller <sp...@lyx.org> wrote:
> Johannes Wilm wrote: > > > No, vice versa. A proper biblatex implementation will have to set the > > > correct > > > option depending on the selected processor. > > > > you can do that as long as biblatex still supports the bibtex executable. > > As I understand it, this will not be much longer. > > Well, then the default processor will be biber if biblatex is selected. No > big > issue either. > Yes, I know it's doable. It's just one of those things that would be very hard to do if one tries to create some kind of universal bibliography nsupport that can be completely controlled from scripts for any new bibliography system and doesn't touch any of the main codebase. > > > > Why? You still can use the current elements. You set a bibtex inset (as > > > now), > > > and it will just be output as preamble element in case biblatex is > > > selected. > > > The user will not need to notice this. The current bibtex dialog can > very > > > well > > > capture this. > > > > Not really. lets look at hwo things are specified int he two systems: > > > > 1. natbib: > > > > per document: > > -- citation style > > > > per bibliography: > > -- bibliography style > > -- bibliography database file > > No, natbib supports only one style per document, AFAIK. So the style should > rather go to the document dialog, both with biblatex and other approaches. > > That's not what the natbib documentation seems to say (page 17). It says that the bibliography style has to be specified for each bibliography individually. > > 2. biblatex > > > > per document: > > -- citation style > > -- bibliography style > > -- bibliography database file > > > > per bibliography: > > -- what section of the file the bibliography is supposed to be for > > (chapter, section, whole thing, etc.) > > We also have this now with bibtopic support. > > Ok, some parts of the gui for bibtopic support may be reusable then. But the bibtex-commands involved are different and the latex-commands are different and the gui will have to give different options. So in the end I really don't think it makes sense to try to mix the two. At any rate, at least 90% of the bibliography gui stuff will have to be completely redone for biblatex. It may be possible to create a system whereby all this can be controlled through a completely user configurable. That would likely have to be a system with xml-files specifying the gui and javascript (or python or so) to make ti interact with the rest of the interface. It just seems like a bigger project than simply creating another bibliography engine AND then some more changes to the core files. > > This is very rough and not very precise. So basically when you click on a > > bibliography in a file that is natbib based, it should ask you for what > > database file it is supposed to use. When you do the same in a biblatex > > based document it should ask you for what section the bibliography is > > supposed to cover. You cannot just have it open the natbib-based dialog > and > > then do some trickery to write the bibliography database file in the > header > > in the end, because biblatex uses the same bibliography databases for all > > its bibliographies. > > It is no problem to "collect" all these databases for the header command > and > specify them in place for the local \printbibliography command. We have a > list > of bibliography files internally, and use the information we need in > different > contexts. We do similar things in many other places already. > > > Say you have a document with 10-15 different > > bibliographies. That's whne things can start to get confusing if the gui > is > > just a hack that isn't really designed for the system at hand. > > It will not be confusing if it's designed well. > > Jürgen > -- Johannes Wilm http://www.johanneswilm.org tel: +1 (520) 399 8880
