At 2021-08-02T19:22:05+0200, Tadziu Hoffmann wrote: > > > Why does refer(1) have no database field for "edition"? > > > The lacuna isn't in refer(1), but in the macro packages using it. > > Any %c, where c is an alphabetic character, can be used to create > > a field refer(1) understands. It is up to macro writers to work > > out the the formatting and placement within a refer(1) citation or > > bibliography entry. [...] > Sticking it onto the end of the title field is ugly, because > one might like the title to be printed in italics, whereas the > edition is "meta information" and should therefore perhaps be > in the regular font. Making the macro parse the content of a > field to extract this kind of information is also unappealing, > because that is the whole purpose of having different fields > in the first place.
I just encountered this very problem in writing an "Examples" section
for refer(1), a page so dense it has a reputation for discouraging
people from picking up the tool. Because I had the temerity to use an
editioned work for my example, I got rewarded with the edition in
italics (as well as the commas bracketing the title, which I think is a
solvable groff ms(7) bug).
> There is also no field for "type" (i.e., article, book, etc.), so
> refer has to infer this information from the presence/absence of other
> fields...
At a glance, the only free _capital_ letters are F, H, M, and U, if we
keep the existing preservation of X, Y, and Z for user extensions.
But I don't see anything calling strcasecmp() or {is,to}{upper,lower}()
in src/preproc/refer or any of the *bib utilities, so it seems we have
26 letters of space for expansion into lowercase.
It's the GNU thing to do!
Regards,
Branden
signature.asc
Description: PGP signature
