LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional 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 >>]

Print Reply
Subject:
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.)

Hyper-linking is something bigger: one for a separate thread I suspect.

> 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

ATOM RSS1 RSS2