LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Juergen Fenn <[log in to unmask]>
Sat, 5 May 2018 21:50:16 +0200
text/plain (57 lines)
I think there is another feature BibTeX really lacks, viz. a standard
style for author-title-year citations as a standard for the humanities.

But I wonder whether it is really worth the effort to change something
about BibTeX because I think nowadays it is supposed to be stable in the
first place. E.g., BibTeX has been implemented in many a library
catalogue as an exchange format for bibliographic data. And those who
rely on citation styles different from the standard styles and on UTF-8
have a much more powerful tool at hand: Biblatex.

Maybe it would be best not to change anything about BibTeX now and to
concentrate on Biblatex and Biber instead.


Am 05.05.18 um 00:36 Uhr schrieb Karl Berry:
> Hello LaTeX folk. Oren (Patashnik) has expressed a desire to do
> "whatever seems useful" (given that compatibility is paramount) with a
> future BibTeX release -- not that anything is going to happen quickly,
> but he wanted to start gathering information at this point.
> For instance, clearly it would be nice to have a url field in the base
> styles. But, what to do in the .bbl file? Assume \url{...} works? But
> there have been different versions over the years and they don't all
> accept the same thing, e.g., bare "#" and "%" in the url, not to mention
> \url{...} vs. \url|...|, etc. And it induces a new dependency (to load
> url/hyperrref/something) on the document, though maybe that is not a big
> deal. Or maybe use a new macro, \btxurl, whose definition is output by
> bibtex itself? That doesn't sound right.
> A doi field is another glaring candidate. But there there isn't even a
> commonly-available \doi command in the first place. So what to do? \btxdoi?
> Maybe BibTeX could provide a core file bibtex.sty which is (implicitly?,
> if available) loaded to define all such macros, probably mostly by
> loading other packages? Sounds fraught with possible problems, but I
> guess it's the most general solution.
> Another idea is to add new entry types. That at least doesn't have the
> same compatibility issues as fields, but maybe isn't that interesting, either.
> Another "modern" idea is to support Unicode sorting, but having core
> bibtex depend on ICU does not sound good, nor does reimplementing the
> sorting algorithm. (And there is bibtexu for people who are gluttons for
> such punishment.) People can already put UTF-8 characters in their .bib
> files if they want to, I believe, and they just get output literally.
> Overall, it somewhat seems to us that although bibtex has zillions of
> limitations and deficiencies, they have already been worked around, one
> way or another (e.g., using biblatex). So imposing fixes in the core
> code may be a solution that's worse than a problem, meaning the best
> thing to do is ... nothing. Which doesn't sound right either :).
> Reactions, ideas? --thanks, karl.