LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML 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:
Jonathan Fine <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sun, 6 May 2018 12:17:04 +0100
Content-Type:
multipart/alternative
Parts/Attachments:
text/plain (3757 bytes) , text/html (5 kB)
Juergen points out that changing bibtex mind break things. I'd like to ask,
is this the right place for the present discussion?

According to https://www.latex-project.org/latex3/code/, the present list
"is intended solely for discussing ideas and concepts for future versions
of LaTeX".

According to http://tug.org/bibtex/, the mailing list for [bibtex] bugs and
discussion is at http://tug.org/pipermail/biblio/

There are github repositories for biber and biblatex.
https://github.com/plk/biblatex
https://github.com/plk/biber

I think putting the current source for bibtex up on github would be a good
first step for Oren being able to do the right thing for bibtex. And it
might provide a better place for carrying out the present discussion.

-- 
Jonathan





On Sat, May 5, 2018 at 8:50 PM, Juergen Fenn <[log in to unmask]> wrote:

> 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.
>
> Regards,
> Jürgen.
>
> 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.
> >
>


ATOM RSS1 RSS2