## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

 Subject: Re: bibtex futures: url, doi, ? From: Joseph Wright <[log in to unmask]> Reply To: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Sat, 5 May 2018 08:16:57 +0100 Content-Type: text/plain Parts/Attachments: text/plain (97 lines)
On 04/05/2018 23:36, Karl Berry wrote:
> 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.

All sounds good :)

I think it's worth noting up-front that almost all users will get an
update to BibTeX only as part of their TeX system. As such, changes in
LaTeX macro provision *now* can almost certainly be taken as applying to
anyone using an updated BibTeX. Of course one can imagine 'What happens
if a user has a new .bst file but an older LaTeX distro', but this is
pretty unlikely.

> 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.

There is always the @preamble approach of \providecommand*{\url}[1]{...}
for some suitable fall-back definition. (Could just be
\texttt{\detokenize{#1}}, given that LaTeX now requires e-TeX anyway.)

Taking a quick look at the url package, I notice that it can happily be
loaded even if \url is already defined (it uses \def not \newcommand).
As such, one possibility would be to ask the team to add a form of \url
to the kernel (which could of course be backed out by latexrelease). Of
course this doesn't address existing installations, but it's pretty
unlikely (as noted above).

(I suspect any change here will need discussion by the team: I'm just
flagging up that it's a not-unreasonable suggestion in 2018.)

> 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?

There is a very short doi package on CTAN: it does use \newcommand so is
slightly more tricky. The code there is LPPL by Heiko Oberdiek, so I
would imagine that a change to use \def, and thus letting the kernel
provide \doi, would be viable (taking the same tack as for \url).

I guess my question with both of these ideas is what impact it has on
existing documents. If people have URL/DOI data in their .bib files, it
will 'magically' appear following such a change. For biblatex and some
natbib styles, the approach taken is to have a switching mechanism to
control that. 'Out of the box' BibTeX doesn't really do that, so there
is an implication. On the other hand, the vanilla BibTeX styles are
probably not used directly in that many publications: there are 100s of
.bst files for a reason. So perhaps this is not really a significant
issue: just needs documenting.

> 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.

As Boris says, any change here wants to fit in with natbib (and
biblatex) if at all possible: the fields url and doi are well-established.

BTW, any changes here probably should be covered in 'Tame the BeaST', if
possible.

> 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.

I'd avoid this, certainly the sorting part. Sorting is *complicated*,
and a big reason that Biber is written in Perl not (say) Lua: there are
*lots* of subtleties to Unicode sorting.

Using UTF-8 in BibTeX files is 'interesting': you are fine provided
BibTeX just passes the bytes through. Issues start when any BibTeX
functions get applied to material, most obviously change.case\$. As far
as I know, BibTeXu is not really production-usable. (Even case changing
is non-trivial for Unicode, though it is more tractable.)

Speaking personally, I've never had an issue with BibTeX + Unicode, but
I do physical sciences, and so basically don't have to manipulate things
like article titles ...

> 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 :).

Largely true :)

Joseph