summaryrefslogtreecommitdiff
path: root/doc/context/manuals/allkind/mkiv-publications.tex
diff options
context:
space:
mode:
Diffstat (limited to 'doc/context/manuals/allkind/mkiv-publications.tex')
-rw-r--r--doc/context/manuals/allkind/mkiv-publications.tex39
1 files changed, 31 insertions, 8 deletions
diff --git a/doc/context/manuals/allkind/mkiv-publications.tex b/doc/context/manuals/allkind/mkiv-publications.tex
index 9e2969277..f498fd622 100644
--- a/doc/context/manuals/allkind/mkiv-publications.tex
+++ b/doc/context/manuals/allkind/mkiv-publications.tex
@@ -426,6 +426,28 @@ but most publication|-|related commands accept optional arguments that denote th
dataset and references to entries can be prefixed with a dataset identifier.. More
about that later.
+Sometimes you want to check a database. One way of doing that is the following:
+
+\startbuffer
+\definebtxdataset[check]
+
+\usebtxdataset[check][mkiv-publications-check.bib]
+
+\showbtxdatasetcompleteness[check]
+\stopbuffer
+
+\typebuffer
+
+The database like like this:
+
+\typefile{mkiv-publications-check.bib}
+
+The completeness check shows (with green field names) the required fields and
+when one is missing this is indicated in red. In blue we show what gets
+inherited.
+
+\getbuffer
+
\stopchapter
\startchapter[title=Renderings]
@@ -1211,9 +1233,9 @@ suffix, you can do this:
\startchapter[title=Notes]
-The move from external \BIBTEX\ processing to internal processing has the advantage that
-we stay within the same run. In the traditional approach we had roughly the following
-steps:
+The move from external \BIBTEX\ processing to internal processing has the
+advantage that we stay within the same run. In the traditional approach we had
+roughly the following steps:
\startitemize[packed]
\startitem the first run information is collected and written to file \stopitem
@@ -1221,9 +1243,9 @@ steps:
\startitem successive runs use that data for references and producing lists \stopitem
\stopitemize
-In the \MKIV\ approach the bibliographic database is loaded in memory each run and
-processing also happens each run. On paper this looks less efficient but as \LUA\ is
-quite fast, in practice performance is much better.
+In the \MKIV\ approach the bibliographic database is loaded in memory each run
+and processing also happens each run. On paper this looks less efficient but as
+\LUA\ is quite fast, in practice performance is much better.
Probably most demanding is the treatment of authors as we have to analyze names,
split multiple authors and reassemble firstnames, vons, surnames and juniors.
@@ -1235,8 +1257,9 @@ typical one of these cases where using \LUAJITTEX\ saves quite time. On my
machine it took just over 100 seconds to get this done. Unfortunately not all
operating systems performed equally well: 32 bit versions worked fine, but 64 bit
\LINUX\ either crashed (stalled) the machine or ran out of memory rather fast,
-while \OSX\ and \WINDOWS\ performed fine. In practice you will never run into this,
-unless you produce massive amounts of bibliographic entries.
+while \MACOSX\ and \WINDOWS\ performed fine. In practice you will never run into
+this, unless you produce massive amounts of bibliographic entries. \LUAJIT\ has
+some benefits but also some drawbacks.
\stopchapter