User:Luigi.scarso/testpage
1 The database
The bibTEX format is rather popular in the TEX community and even with its shortcomings it will stay around for a while. Many publication websites can export and many tools are available to work with this database format. It is rather simple and looks a bit like Lua tables. Unfortunately the content can be polluted with non-standardized TEX commands which complicates pre- or postprocessing outside TEX . In that sense a bibTEX database is often not coded neutrally. Some limitations, like the use of commands to encode accented characters root in the ascii world and can be bypassed by using utf instead (as handled somewhat in LATEX through extensions such as bibtex8 ).
The normal way to deal with a bibliography is to refer to entries using a unique tag or key. When a list of entries is typeset, this reference can be used for linking purposes. The typeset list can be processed and sorted using the bibtex program that converts the database into something more TEX friendly (a .bbl file). I never used the program myself (nor bibliographies) so I will not go into too much detail here, if only because all I say can be wrong.
In ConTEXt we no longer use the bibtex program: we just use database files and deal with the necessary manipulations directly in ConTEXt . One or more such databases can be used and combined with additional entries defined within the document. We can have several such datasets active at the same time.
A bibTEX file looks like this:
@Article{sometag,
author = "An Author and Another One",
title = "A hopefully meaningful title",
journal = maps,
volume = "25",
number = "2",
pages = "5--9",
month = mar,
year = "2013",
ISSN = "1234-5678",
}
Normally a value is given between quotes (or curly brackets) but single words are also OK (there is no real benefit in not using quotes, so we advise to always use them). There can be many more fields and instead of strings one can use predefined shortcuts. The title for example quite often contains TEX macros. Some fields, like pages have funny characters such as the endash (typically as -- ) so we have a mixture of data and typesetting directives. If you are covering non--english references, you often need characters that are not in the ascii subset but ConTEXt is quite happy with utf . If your database file uses old-fashioned TEX accent commands then these will be internally converted automatically to utf . Commands (macros) are converted to an indirect call, which is quite robust.
The bibTEX files are loaded in memory as Lua table but can be converted to xml so that we can access them in a more flexible way, but that is a subject for specialists.
In the old MkII setup we have two kinds of entries: the ones that come from the bibTEX run and user supplied ones. We no longer rely on bibTEX output but we do still support the user supplied definitions. These were in fact prepared in a way that suits the processing of bibTEX generated entries. The next variant reflects the ConTEXt recoding of the old bibTEX output.
\startpublication[k=Hagen:Second,t=article,a={Hans Hagen},y=2013,s=HH01]
\artauthor[]{Hans}[H.]{}{Hagen}
\arttitle{Who knows more?}
\journal{MyJournal}
\pubyear{2013}
\month{8}
\volume{1}
\issue{3}
\issn{1234-5678}
\pages{123--126}
\stoppublication
The split \artauthor fields are collapsed into a single author field as we deal with the splitting later when it gets parsed in Lua . The \artauthor syntax is only kept around for backward compatibility with the previous use of bibTEX .
In the new setup we support these variants as well:
\startpublication[k=Hagen:Third,t=article]
\author{Hans Hagen}
\title{Who knows who?}
...
\stoppublication
and
\startpublication[tag=Hagen:Third,category=article]
\author{Hans Hagen}
\title{Who knows who?}
...
\stoppublication
and
\startpublication
\tag{Hagen:Third}
\category{article}
\author{Hans Hagen}
\title{Who knows who?}
...
\stoppublication
Because internally the entries are Lua tables, we also support loading of Lua based definitions:
return {
["Hagen:First"] = {
author = "Hans Hagen",
category = "article",
issn = "1234-5678",
issue = "3",
journal = "MyJournal",
month = "8",
pages = "123--126",
tag = "Hagen:First",
title = "Who knows nothing?",
volume = "1",
year = "2013",
},
}
Files set up like this can be loaded too. The following xml input is rather close to this, and is also accepted as input.
<?xml version="2.0" standalone="yes" ?> <bibtex> <entry tag="Hagen:First" category="article"> <field name="author">Hans Hagen</field> <field name="category">article</field> <field name="issn">1234-5678</field> <field name="issue">3</field> <field name="journal">MyJournal</field> <field name="month">8</field> <field name="pages">123--126</field> <field name="tag">Hagen:First</field> <field name="title">Who knows nothing?</field> <field name="volume">1</field> <field name="year">2013</field> </entry> </bibtex>
Todo: Add some remarks about loading EndNote and RIS formats, but first we need to complete the tag mapping (on Alan’s plate).
So the user has a rather wide choice of formatting style for bibliography database files.
You can load more data than you actually need. Only entries that are referred to explicitly through the \cite and \nocite commands will be shown in lists. We will cover these details later.
2 Commands in entries
One unfortunate aspect commonly found in bibTEX files is that they often contain TEX commands. Even worse is that there is no standard on what these commands can be and what they mean, at least not formally, as bibTEX is a program intended to be used with many variants of TEX style: plain, LATEX , and others. This means that we need to define our use of these typesetting commands. However, in most cases, they are just abbreviations or font switches and these are often known. Therefore, ConTEXt will try to resolve them before reporting an issue. In the log file there is a list of commands that has been seen in the loaded databases. For instance, loading tugboat.bib gives a long list of commands of which we show a small set here:
publications > start used btx commands publications > standard CONTEXT 1 known publications > standard ConTeXt 4 known publications > standard TeXLive 3 KNOWN publications > standard eTeX 1 known publications > standard hbox 6 known publications > standard sltt 1 unknown publications > stop used btxcommands
You can define unknown commands, or overload existing definitions in the following way:
\definebtxcommand\TUB {TUGboat}
\definebtxcommand\sltt{\tt}
\definebtxcommand\<#1>{\type{#1}}
Unknown commands do not stall processing, but their names are then typeset in a mono- spaced font so they probably stand out for proofreading. You can access the commands with \btxcommand{...} , as in:
commands like \btxcommand{MySpecialCommand} are handled in an indirect way
As this is an undefined command we get: “commands like MySpecialCommand are handled in an indirect way”.
??
3 Datasets
Normally in a document you will use only one bibliographic database, whether or not distributed over multiple files. Nevertheless we support multiple databases as well which is why we talk of datasets instead. A dataset is loaded with the \usebtxdataset command. Although currently it is not necessary to define a (default) dataset you can best do this because in the future we might provide more options. Here are some examples:
\definebtxdataset[standard] \usebtxdataset[standard][tugboat.bib] \usebtxdataset[standard][mtx-bibtex-output.xml] \usebtxdataset[standard][test-001-btx-standard.lua]
These three suffixes are understood by the loader. Here the dataset has the name standard and the three database files are merged, where later entries having the same tag overload previous ones. Definitions in the document source (coded in TEX speak) are also added, and they are saved for successive runs. This means that if you load and define entries, they will be known at a next run beforehand, so that references to them are independent of when loading and definitions take place.
In this document we use some example databases, so let’s load one of them now:
\definebtxdataset[example]
\usebtxdataset[example][mkiv-publications.bib]
You can ask for an overview of entries in a dataset with:
\showbtxdatasetfields[example]
this gives:
tagcategoryfieldsdemo-001bookauthor index title yeardemo-002bookcrossref index yeardemo-003bookauthor comment index title yeardemo-004bookauthor comment index title yeardemo-005bookauthor doi index pages serial title url year
You can set the current active dataset with
\setbtxdataset[standard]
but most publication-related commands accept optional arguments that denote the dataset and references to entries can be prefixed with a dataset identifier.. More about that later.
4 Renderings
A list of publications can be rendered at any place in the document. A database can be much larger than needed for a document. The same is true for the fields that make up an entry. Here is the list of fields that are currently handled, but of course there can be additional ones:
abstract , address , annotate , assignee , author , bibnumber , booktitle , chapter , comment , country , day , dayfiled , doi , edition , editor , eprint , howpublished , institution , isbn , issn , journal , key , keyword , keywords , language , lastchecked , month , monthfiled , names , nationality , note , notes , number , organization , pages , publisher , revision , school , series , size , title , type , url , volume , year , yearfiled
If you want to see what publications are in the database, the easiest way is to ask for a complete list:
\definebtxrendering [example] [dataset=example, method=local, alternative=apa] \placelistofpublications % \placebtxrendering [example] [criterium=all]
This gives:1 Hans Hagen and Ton Otten (1996). Typesetting education documents2 Luigi Scarso (2021). Designing high speed trains3 author (year). title pages p.
The rendering itself is somewhat complex to set up because we have not only many different standards but also many fields that can be set up. This means that there are several commands involved. Often there is a prescribed style to render bibliographic descriptions, for example apa . A rendering is setup and defined with:
And a list of such descriptions is generated with:
A dataset can have all kind of entries:
article , book , booklet , conference , inbook , incollection , inproceedings , manual , mastersthesis , misc , phdthesis , proceedings , techreport , unpublished
Each has its own rendering variant. To keep things simple we have their settings separated. However, these settings are shared for all rendering alternatives. In practice this is seldom a problem in a publication as only one rendering alternative will be active. If this be not sufficient, you can always group local settings in a setup and hook that into the specific rendering.
Examples of list variants are:
setupbtxlistvariant : artauthor no specific settings setupbtxlistvariant : author no specific settings setupbtxlistvariant : editor no specific settings
The exact rendering of list entries is determined by the alternative key and defaults to apa which uses definitions from publ-imp-apa.mkiv . If you look at that file you will see that each category has its own setup. You may also notice that additional tests are needed to make sure that empty fields don’t trigger separators and such.
There are a couple of accessors and helpers to get the job done. When you want to fetch a field from the current entry you use \btxfield . In most cases you want to make sure this field has a value, for instance because you don’t want fences or punctuation that belongs to a field.
\btxdoif {title} {
\bold{\btxfield{title}},
}
There are three test macros:
\btxdoifelse{fieldname}{action when found}{action when not found}
\btxdoif {fieldname}{action when found}
\btxdoifnot {fieldname} {action when not found}
An extra conditional is available for testing interactivity:
\btxdoifelseinteraction{action when true}{action when false}
In addition there is also a conditional \btxinteractive which is more efficient, although in practice efficiency is not so important here.
There are three commands to flush data:
\btxfield fetch a explicit field (e.g. year ) \btxdetail fetch a derived field (e.g. short ) \btxflush fetch a derived or explicit field
Normally you can use \btxfield or \btxflush as derived fields just like analyzed author fields are flushed in a special way.
You can improve readability by using setups, for instance:
\btxdoifelse {author} {
\btxsetup{btx:apa:author:yes}
} {
\btxsetup{btx:apa:author:nop}
}
Keep in mind that normally you don’t need to mess with definitions like this because standard rendering styles are provided. These styles use a few helpers that inject symbols but also take care of leading and trailing spaces:
\btxspace before after \btxperiod before. after \btxcomma before, after \btxlparent before (after \btxrparent before) after \btxlbracket before [after \btxrbracket before] after
So, the previous example setup can be rewritten as:
\btxdoif {title} {
\bold{\btxfield{title}}
\btxcomma
}
There is a special command for rendering a (combination) of authors:
\btxflushauthor{author}
\btxflushauthor{editor}
\btxflushauthor[inverted]{editor}
Instead of the last one you can also use:
\btxflushauthorinverted{editor}
You can use a (configurable) default or pass directives: Valid directives are
conversionrendering inverted the Frog jr, Kermit invertedshort the Frog jr, K normal Kermit, the Frog, jr normalshort K, the Frog, jr
5 Citations
Citations are references to bibliographic entries that normally show up in lists someplace in the document: at the end of a chapter, in an appendix, at the end of an article, etc. We discussed the rendering of these lists in the previous chapter. A citation is normally pretty short as its main purpose is to refer uniquely to a more detailed description. But, there are several ways to refer, which is why the citation subsystem is configurable and extensible. Just look at the following commands:
\cite[author][example::demo-003] \cite[authoryear][example::demo-003] \cite[authoryears][example::demo-003] \cite[author][example::demo-003,demo-004] \cite[authoryear][example::demo-003,demo-004] \cite[authoryears][example::demo-003,demo-004] \cite[author][example::demo-004,demo-003] \cite[authoryear][example::demo-004,demo-003] \cite[authoryears][example::demo-004,demo-003]
(Hans Hagen and Ton Otten)(Hans Hagen and Ton Otten (1996))(Hans Hagen and Ton Otten, 1996)(Hans Hagen and Ton Otten, Luigi Scarso)(Hans Hagen and Ton Otten (1996), Luigi Scarso (2021))(Hans Hagen and Ton Otten, 1996, Luigi Scarso, 2021)(Luigi Scarso, Hans Hagen and Ton Otten)(Luigi Scarso (2021), Hans Hagen and Ton Otten (1996))(Luigi Scarso, 2021, Hans Hagen and Ton Otten, 1996)
The first argument is optional.
You can tune the way a citation shows up:
\setupbtxcitevariant[author] [sorttype=author,color=darkyellow] \setupbtxcitevariant[authoryear] [sorttype=author,color=darkyellow] \setupbtxcitevariant[authoryears][sorttype=author,color=darkyellow]
\cite[author][example::demo-004,demo-003]
\cite[authoryear][example::demo-004,demo-003] \cite[authoryears][example::demo-004,demo-003]
Here we sort the authors and color the citation:
(Hans Hagen and Ton Otten, Luigi Scarso)(Hans Hagen and Ton Otten (1996), Luigi Scarso (2021))(Hans Hagen and Ton Otten, 1996, Luigi Scarso, 2021)
For reasons of backward compatibility the \cite command is a bit picky about spaces between the two arguments, of which the first is optional.
\citation[author] [example::demo-004,demo-003] \citation[authoryear] [example::demo-004,demo-003] \citation[authoryears][example::demo-004,demo-003]
There is a whole bunch of cite options and more can be easily defined.
keyrendering author (author) authornum [author [btx error 1]] authoryear (author (year)) authoryears (author, year) doi [todo: doi] key [demo-005] none num btx error 1 page pages serial [5] short [aut00] type [book] url [todo: url] year (year)
Because we are dealing with database input and because we generally need to manipulate entries, much of the work is delegated to Lua . This makes it easier to maintain and extend the code. Of course TEX still does the rendering. The typographic details are controlled by parameters but not all are used in all variants. As with most ConTEXt commands, it starts out with a general setup command:
On top of that we can define instances that inherit either from a given parent or from the topmost setup.
