2

Its possible to omit url by

url=false

How to omit address?

I tried address=false but its not that.

Just found:

\DeclareSourcemap{
  \maps[datatype=bibtex, overwrite]{
    \map{
      \step[fieldset=address, null]
      \step[fieldset=editor, null]
    }
  }
}
2
  • url=no should not work. The option is a boolean option and accepts the values true and false. The \DeclareSourcemap is pretty much what I would use, but you need to keep in mind that address is an alias for location, so you probably want to clear both address and location.
    – moewe
    May 21, 2019 at 11:27

1 Answer 1

5

At least with the standard styles

url=no,

is not valid and will produce an error along the lines of

! Package etoolbox Error: Invalid boolean value 'no'.

url is a boolean option and can only take the values true or false (it can also appear without a value, which is equivalent to passing the value true).

Contrary to a belief held by some that pops up from time to time in various LaTeX forums and also on this site, this does not work for all fields. In fact only url, isbn (and with it issn and isrn), eprint and the related fields can be suppressed in this way. All other fields need to be gotten rid of with different methods.


There are two things to keep in mind when dealing with address.

  1. address is actually only a convenience alias for backwards compatibility with BibTeX. The field is remapped to the field location by Biber. Internally biblatex only knows location and not address.

  2. biblatex distinguishes three types of fields. Name lists, lists and (proper) fields. If you want to clear a 'field' with \clear... you need to know its type and need to use the corresponding \clear... command (\clearfield, \clearlist, \clearname). location is a list. You can find out the type of each field known to biblatex by consulting the biblatex documentation, specifically §2.2 Entry Fields.

There are several ways to get rid of a field.


My preferred way to completely get rid of address/location would be via a Biber sourcemap. Sourcemaps are executed before the field aliases are applied, so before address is remapped to location. Hence, we need to to null both address and location to make sure the address/location is gone.

\DeclareSourcemap{
  \maps[datatype=bibtex, overwrite]{
    \map{
      \step[fieldset=address, null]
      \step[fieldset=location, null]
    }
  }
}

This method completely removes all traces of the field. The field will not be used by Biber to calculate any of the advanced features like name uniqueness, label... fields etc. and it will not be passed on to biblatex.


A slightly less pretty method to remove location would involve

\DeclareListInputHandler{location}{\def\NewValue{}}

Biber will still see the field and might take it into account for its calculations, but biblatex will simply ignore it.


Finally, you can selectively suppress the fields in citations or the bibliography with

 \AtEveryCitekey{\clearlist{location}}
 \AtEveryBibitem{\clearlist{location}}

That way the data has been processed by Biber and could have been used for label and uniqueness calculations; it is also in principle known to biblatex, but you tell it to forget about it for the time being.


In general I would say it is good advice to ignore a field as early as possible (especially if we are talking about name or date fields), but for most intents and purposes involving location/address the three methods will give the same results.

3
  • Sir, my mistake saying url=no, I took that from my mind without checking code. I should have said url=false. Updated question. Although, I will took the opportunity to ask, will there be any disadvantage in having yes/nofunctioning as true/false, or even 1/0?
    – KcFnMi
    May 23, 2019 at 13:12
  • @KcFnMi Well, the only real disadvantage that I could think about is that someone has to do the work to make yes/no or 1/0 work. Currently biblatex just delegates that work to etoolbox and need not do any of the work to pre-process other truthy or falsy values. One might also try to argue that more values could be more confusing, but that probably does not hold a lot of water.
    – moewe
    May 23, 2019 at 15:28
  • It has not been implemented because no one has asked for it yet and if someone were to ask for it at github.com/plk/biblatex/issues now I would probably not be too keen on it, since true/false is established, works well enough and I see no compelling reason why adding something like yes/no would bring a huge benefit. But if enough people say it is needed we can always look into it.
    – moewe
    May 23, 2019 at 15:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .