List of Figures[link]

List of Tables[link]

List of Examples[link]

If an example shows the icon 📥^🖹 then you can click on that icon to try downloading the example source code from a location relative to this document. You can also try using:

〉_
texdoc -l datatool-user-example〈nnn〉

1. Introduction[link]

The following packages are provided by the datatool bundle:

• •datatool-base This is the underlying package automatically loaded by all the other listed packages, but may be loaded without the other packages if only the base functions are required. The datatool-base package may be used to:
  • –Determine whether an argument is an integer, a real number, currency or a string. Locale dependent number settings are supported (such as a comma as a decimal character and a full stop as a number group character). As from version 3.0, scientific notation is also supported.
  • –Convert locale dependent numbers or currency to plain number format, enabling arithmetic to be performed on elements of the database.
  • –Names can be converted to initials.
  • –Determine if strings are all upper or lower case.
  • –Perform string comparisons (both case sensitive and case insensitive).
  See §2.

• •datatool

  Main package providing database support. Automatically loads datatool-base. This package can be used to:

  • –Create or load databases.
  • –Sort rows of a database (either numerically or alphabetically, ascending or descending).
  • –Perform repetitive operations on each row of a database (e.g. mail merging). Conditions may be imposed to exclude rows.
  Database commands are described in §3.

• •datagidx

  The datagidx package (see §8) can be used to generate indexes or glossaries as an alternative to packages such as glossaries. Note that datagidx is far more limited than glossaries and doesn’t provide any localisation support. See §8.

• •datapie

  The datapie package can be used to convert a database into a pie chart:

  • –Segments can be separated from the rest of the chart to make them stand out.
  • –Colour/grey scale options.
  • –Predefined segment colours can be changed.
  • –Hooks provided to add extra information to the chart
  See §4.

• •dataplot

  The dataplot package can be used to convert a database into a two dimensional plot using markers and/or lines. Three dimensional plots are currently not supported. See §6.

• •databar

  The databar package can be used to convert a database into a bar chart:

  • –Colour/grey scale options.
  • –Predefined bar colours can be changed.
  • –Hooks provided to add extra information to the chart
  See §5.

• •databib

  The databib package can be used to convert a BibTeX database into a datatool database. See §7.

• •person

  The person package can be used to reference people by the appropriate gender pronouns. Automatically loads datatool. See §9.

The code providing the mathematical functions have some limitations. These limitations will therefore also be present in the various packages provided with datatool, according to the underlying package (fp or pgfmath) or LaTeX3 kernel commands or Lua code used. As from version 3.0, the new default is lua, if \directlua is defined, or l3fp otherwise. To avoid repeated parsing, some functions, such as the aggregate functions (§3.13) or charts (§§4, 6 & 5), will use LaTeX3 commands regardless of the math option.

1.1. Rollback[link]

Version 3.0 is a major new version where many commands have been rewritten to use LaTeX3 macros. Additionally, some packages, such as xkeyval and substr are no longer loaded. If you experience any backward-compatibility problems with the new version, you can rollback to the previous version (2.32):

🖹
\usepackage{datatool}[=v2.32]

1.2. LaTeX3[link]

The LaTeX kernel has changed significantly since datatool was first released in 2007. There is now improved support for UTF-8 and many of the commands provided by datatool now have much better LaTeX3 alternatives. You may find some tasks more efficient if you use LaTeX3 commands directly. However, LaTeX3 commands are intended for internal use within the definitions of document commands rather than explicit use in the document.

LaTeX3 syntax must first be switched on (\ExplSyntaxOn) before defining commands that use them and then switched off (\ExplSyntaxOff) afterwards. Spaces are ignored, so you need to use ~ if an actual space is required. Further information can be found in the interface3.pdf document:

〉_
texdoc interface3

1.2.1. Regular Expressions[link]

🖹
\documentclass{article}
\ExplSyntaxOn
\NewDocumentCommand{\testreplace} { m }
{
  \regex_replace_all:nnN 
   { \c{emph} \cB\{ (\w+) \cE\} }
   { \c{textbf} { \c{text_uppercase:n}{ \1 } } }
   #1
}
\ExplSyntaxOff
\begin{document}
\newcommand{\teststring}{The duck said \emph{boo} to the goose.}
Original: \teststring

\testreplace{\teststring}
Replaced: \teststring
\end{document}

1.2.2. Comma-Separated Lists[link]

🖹
\documentclass{article}
\ExplSyntaxOn
\clist_new:N \l_my_clist
\NewDocumentCommand \createmylist { m }
{
  \clist_set:Nn \l_my_clist { #1 }
}
\NewDocumentCommand \mylistelement { m }
{
  \clist_item:Nn \l_my_clist { #1 }
}
\NewDocumentCommand \reversemylist { }
{
  \clist_reverse:N \l_my_clist
}
\NewDocumentCommand \displaymylist { }
{
  \clist_use:Nnnn \l_my_clist {~and~ } { ,~ } { ,~and~}
}
\ExplSyntaxOff
\begin{document}
\createmylist{ant,duck,goose,zebra}
\displaymylist

Second element: \mylistelement{2}.

\reversemylist
\displaymylist

Second element: \mylistelement{2}.
\end{document}

1.2.3. Calculations[link]

🖹
\documentclass{article}
\ExplSyntaxOn
\newcommand{\myfunc} [3]
{
  \fp_to_decimal:n{ #1 + 0.5 * sqrt(#2) / (#3) }
}
\ExplSyntaxOff
\newcommand{\numA}{1023.5}
\newcommand{\numB}{54.75000}
\newcommand{\numC}{-20648.68}
\begin{document}
$ \numA+\frac{\sqrt{\numB}}{2\times\numC} = 
\myfunc{\numA}{\numB}{\numC} $
\end{document}

🖹
\newcommand{\myfunc}[3]{% 
  \directlua{tex.print(#1+0.5*math.sqrt(#2)/(#3))}% 
}

2. Base Commands (datatool-base package)[link]

The datatool-base package may be loaded on its own, without the datatool package, if no database commands (see §3) are required. Available package options for datatool-base are listed below.

2.1. datatool-base Options[link]

Options can be passed through the package option list in the usual way. Some options may also be later set with:

🔎
! Dimension too large

The auto-reformat-types does not switch on the corresponding auto-reformat numeric option or auto-reformat datetime option. It simply establishes which data types should be affected when the applicable option is on.

For example:

\DTLsetup{
 auto-reformat-types={decimal,si,datetime},
 numeric={auto-reformat},
 datetime={parse=auto-reformat}
}

2.2. Data Types[link]

The datatool-base package recognises the following data types:

Integers

An integer is a sequence of digits, optionally groups of three digits may be separated by the number group character. The default number group character is a comma (,) but may be changed using \DTLsetnumberchars. Examples: 1,234 (which has the default number group character) and 1234 (which is also a plain number) but not 1234.0 (which is a decimal). A double sign (such as ++1234 or -+1234) isn’t permitted and will be treated as a string.

If a whole number is represented in scientific notation (for example, 1e+4 instead of 1000) then it will be identified as a decimal not an integer. Otherwise, a large integer will be considered a string (otherwise it will trip TeX’s integer limit).

Real Numbers (Decimals)

A real number is a sequence of digits as per integers followed by the decimal character followed by one or more digits. The number group character is only recognised before the decimal character. The decimal character is a full stop “decimal point” by default. The number group and decimal characters may be changed using \DTLsetnumberchars. Examples: 1,234.0 (which has the default number group character and decimal character), 1234.0 (which is also a plain number) but not 1234 (which is an integer). A double sign (such as ++1234.0 or -+1234.0) isn’t permitted and will be treated as a string.

As from version 3.0, scientific notation, such as 2.5e+10 or 1E-5 is supported. Note that the locale symbols aren’t supported when parsing for scientific notation. The format should be 〈mantissa〉E〈exponent〉 or 〈mantissa〉e〈exponent〉. A space may occur between the mantissa and the E/e. The exponent must be an integer. The mantissa may include a decimal point. If the auto-reformat setting is on, parsed scientific notation will have the value encapsulated with \DTLscinum.

Currency

The parser recognises currency values if provided in one of the following forms: \DTLcurrency{〈num〉}, \DTLfmtcurrency{〈sym〉}{〈num〉} \DTLfmtcurr{〈currency-code〉}{〈num〉} or 〈sym〉〈num〉 where 〈sym〉 is a recognised currency symbol (identified with \DTLnewcurrencysymbol) and 〈num〉 is an integer or decimal using the current number group character and decimal character (not scientific notation). The sign may occur before the currency symbol. Some regional localisation files will also recognise currency where the symbol is prefixed with the region’s code.

Examples: $1,234.56 and \pounds1234 (which both have a recognised currency symbol) and \DTLfmtcurrency{£}1,234 or \DTLcurrency{1,234.00} (which both use known currency formatting commands) but not “1,234 USD” (which doesn’t fit the recognised format). Both -\pounds1234 and \pounds-1234 are recognised as a currency with a negative numeric value.

Additionally, \DTLfmtcurr{GBP}1,234 will also be recognised as currency (although it requires the datatool-GB.ldf region file to be loaded in order to correctly format the value). If datatool-GB.ldf has been loaded, then GB£1,234 will also be recognised. However, if, say, datatool-IE.ldf has been loaded, then IE€1,234 won’t be recognised as that region doesn’t support a currency prefix. See §2.6.

Temporal Values (Dates and Times)

New to version 3.0 and still experimental. ISO dates and times can be parsed (if enabled with parse) and converted into a numerical form so that they can be treated as numbers.

🛈

If temporal parsing is off or the format is unsupported, dates and times will be treated as strings. Regional formats can only be supported if they have been defined in a loaded region file. See §2.3.

There are three temporal types:

1.Dates are in the form 〈YYYY〉-〈MM〉-〈DD〉 where 〈YYYY〉 is the year, 〈MM〉 is the two digit month and 〈DD〉 is the two digit day. The numeric value is the integer JDN. 2.Times are in the form 〈hh〉:〈mm〉:〈ss〉 or 〈hh〉:〈mm〉 where 〈hh〉 is the two digit 24 hour, 〈mm〉 is the two digit minute, and 〈ss〉 is the two digit second (“00” if omitted). The numeric value is the JF. 3.Timestamps include both a date and time. If the time zone is missing, UTC+0 is assumed. Recognised formats:

〈YYYY〉-〈MM〉-〈DD〉T〈hh〉:〈mm〉:〈ss〉〈TZh〉:〈TZm〉
〈YYYY〉-〈MM〉-〈DD〉T〈hh〉:〈mm〉:〈ss〉Z
〈YYYY〉-〈MM〉-〈DD〉T〈hh〉:〈mm〉:〈ss〉

Where 〈TZh〉 is the time zone hour and 〈TZm〉 is the time zone minute. A space may also be used instead of “T” as the separator between the date and time. The corresponding numeric value is the JD, which is the integer JDN plus the fractional JF.

Strings

Any non-blank content that doesn’t belong to the above types is considered to be a string. See §2.8.

Unknown

Blank values are classified as an unknown type. This may be the result of an empty element in a CSV list or file.

Null

Values that are missing (not simply empty) are considered null values. This is similar in concept to \c_novalue_tl but uses a different internal marker. See §3.10 for further details.

2.2.1. Numeric Options[link]

The options listed here govern parsing and formatting of localised integers, decimals and currency. The options may be passed in the value of the numeric option. For example:

🖹
\DTLsetup{
  numeric={
    auto-reformat,
    region-currency-prefix=smallcaps
  }
}

If auto-reformat-types includes the keyword integer, then any integers will be reformatted according to the current localisation settings. If auto-reformat-types includes the keyword decimal, then any decimals not in scientific notation will be reformatted according to the current localisation settings.

If auto-reformat-types includes the keyword si, then any scientific notation, will be have the string part set to

If auto-reformat-types includes the keyword currency, then currency will be reformatted to use \DTLfmtcurr, if the associated currency code can be determined, or to \DTLfmtcurrency otherwise.

\DTLsetdefaultcurrency{〈currency-code〉}
\DTLsetup{region-currency=false}

2.2.2. Parsing Locale-Formatted Numbers and Currency Values[link]

Formatted numbers can be parsed provided the appropriate number group character and decimal character have been set with \DTLsetnumberchars and the currency symbol has been declared with \DTLdefcurrency (typically by loading a region file via locales or the document language support). If you want to format a plain number, you can use \DTLdecimaltolocale or \DTLdecimaltocurrency, described in §2.3, or use siunitx.

A warning is issued if the data type is a string rather than a numeric value and the value will be treated as zero. An empty 〈num〉 is also treated as zero. No trimming is performed on 〈num〉.

For example:

🖹
\DTLconverttodecimal{\$1,234.50}{\myNum}

2.2.3. Datum Commands[link]

Instead of repeatedly parsing the same content, you may prefer to parse it once and store the information for later use. This can be done with the following command:

In both cases, the parsed data is stored in the control sequence 〈cs〉 (a datum control sequence) in a form that includes the original value (or expanded value in the case of \DTLxparse), the data type, the numerical value (if one of the numerical types), and the currency symbol (if applicable).

The “string value”, which is the content that 〈cs〉 will expand to, may be automatically reformatted if an applicable setting is in effect (such as numeric={auto-reformat}).

The datum item format is particularly useful with databases (see §3) that have numeric data which needs to be converted into plain numbers for arithmetic computations (such as aggregates) or plotting. If store-datum is enabled before creating the database, each value will be stored as a datum item. If you then assign a placeholder command to the value, for example with \DTLmapgetvalues, then that command will be a datum control sequence in the same format as that obtained with \DTLparse.

The component parts can then be extracted using the following expandable commands, where 〈cs〉 is the datum control sequence.

For example:

🖹
\DTLparse\mydatum{1,234.0}
Data type: \DTLdatumtype{\mydatum}.

Note that the data type is actually stored as a LaTeX3 integer constant, but \DTLdatumtype will convert the constant value to an integer denotation. If you want the actual constant, use:

🖹
\exp_args:NV \datatool_datum_type:Nnnnn 〈cs〉

For debugging purposes, you may find it easier to have a textual representation of the data type so that you don’t have to lookup what the numeric value represents. You can do this with:

You may also “show” the component parts in the console and transcript:

Instead of parsing an existing value, you can define a new datum control sequence using one of the commands below. Only \DTLsetfpdatum performs any parsing.

Datum control sequences may be used in commands that expect a formatted number, such as \DTLadd, as demonstrated in

🖹
\usepackage{datatool-base}
\usepackage{siunitx}
\DTLparse{\numA}{23,452}
\DTLparse{\numB}{45.0}
\DTLparse{\numC}{\pounds 24.50}
\DTLsetfpdatum{\numD}{\num{1.5e-4}}{1.5e-4}
\begin{document}
Original value: \DTLusedatum{\numC} or \numC.
Numeric value: \DTLdatumvalue{\numC}.
Currency: \DTLdatumcurrency{\numC}.
Data type: \number\DTLdatumtype{\numC}.

\DTLadd{\result}{\numA}{\numB}
$\numA + \numB = \result$

\DTLaddall{\result}{\numA,\numB,\numC}
$\numA + \numB + \numC = \result$

\dtladd{\result}{\DTLdatumvalue{\numA}}{\DTLdatumvalue{\numB}}
$\DTLdatumvalue{\numA} + \DTLdatumvalue{\numB} = \result$

\dtladdall{\result}
{\DTLdatumvalue{\numA},\DTLdatumvalue{\numB},\DTLdatumvalue{\numC}}
$\DTLdatumvalue{\numA} + \DTLdatumvalue{\numB}
 + \DTLdatumvalue{\numC} = \result$

\DTLxsetdecimaldatum{\total}{\num{\result}}{\result}
Total: \total.

\dtlmul{\result}{20}{\DTLdatumvalue{\numD}}
$20 \times \numD = \result$

\end{document}

2.2.4. Datum Items (Advanced)[link]

If you have the expansion text from a datum control sequence (a datum item), that text will be in the form:

〈marker-cs〉{〈string〉}{〈value〉}{〈currency〉}{〈type〉}

Decimals may have the 〈value〉 part stored as:

Temporal data types may have the 〈value〉 part stored as:

The date/time stamp can be extracted with:

To allow for new data types introduced in a later version, you can check for the current maximum allowed value with:

2.2.4.1. Datum Components[link]

It’s possible to pick out the desired component using an 〈n〉 of 〈m〉 style of command. However, the following commands are provided as it’s more obvious from the command name which element is required. Note that these require LaTeX3 syntax enabled:

2.2.4.2. Datum Tests for Equality[link]

If you want to test if a datum control sequence is equal to a string, then you can’t simply use \tl_if_eq:NnTF or \ifdefstring as the datum markup will prevent a match. Commands such as \DTLifstringeq expand the arguments which will remove the datum markup, but the following commands take the data type into account.

If both arguments have a numeric type then they will be compared numerically and by the currency symbol. If both are ordinary token lists without the datum markup then they will be compared using a normal token list comparison. If one has the datum format and the other doesn’t, then a string comparison is used.

🖹
\DTLparse{\Fruit}{Pear}
\DTLparse{\Price}{\$1.50}
\DTLparse{\Quantity}{10}

🖹
\DTLsetcurrencydatum{\OtherPrice}{1 dollar 50\textcent}{1.5}{\$}

🖹
\DTLsetdecimaldatum{\OtherQuantity}{10.00}{10.0}

🖹
\newcommand{\test}[3]{#1=#2 (\texttt{\string#3}) ?
  #3{#1}{#2}{true}{false}.\par}

🖹
\ExplSyntaxOn

🖹
\test \Fruit {Pear} \tl_if_eq:NnTF
\test \Fruit {Pear} \tl_if_eq:enTF
\test \Fruit {Pear} \datatool_if_value_eq:NnTF

🖹
\test \Price {\$1.50} \tl_if_eq:NnTF
\test \Price {\$1.50} \tl_if_eq:enTF
\test \Price {\$1.50} \datatool_if_value_eq:NnTF
\test \Price {\$1.5} \datatool_if_value_eq:NnTF

🖹
\test \Price \OtherPrice \tl_if_eq:NNTF
\test \Price \OtherPrice \datatool_if_value_eq:NNTF

🖹
\test \Quantity {10} \tl_if_eq:NnTF
\test \Quantity {10} \tl_if_eq:enTF
\test \Quantity {10} \datatool_if_value_eq:NnTF
\test \Quantity {10.00} \datatool_if_value_eq:NnTF
\test \Quantity \OtherQuantity \tl_if_eq:NNTF
\test \Quantity \OtherQuantity \datatool_if_value_eq:NNTF

2.2.4.3. Conversion to Floating Point[link]

If you need to set an l3fp variable to a value that may be a datum control sequence or datum item or may not yet be parsed, you can use:

🖹
\usepackage{datatool-base}
\usepackage{siunitx}
\DTLparse{\numA}{1,500.0}
\DTLsetfpdatum{\numB}{\num{1.5e-4}}{1.5e-4}
\begin{document}
A = \numA \space (value: \DTLdatumvalue\numA).
B = \numB \space (value: \DTLdatumvalue\numB).

\ExplSyntaxOn
\datatool_set_fp:Nn \l_tmpa_fp { \numA }
\datatool_set_fp:Nn \l_tmpb_fp { \numB }
\fp_to_tl:N \l_tmpa_fp \c_space_tl
 \texttimes \c_space_tl
\fp_to_tl:N \l_tmpb_fp \c_space_tl = \c_space_tl
\fp_eval:n { \l_tmpa_fp * \l_tmpb_fp }
\ExplSyntaxOff
\end{document}

2.3. Localisation[link]

The datatool-base package (v3.0+) loads the tracklang package, which attempts to determine the document localisation settings. No actual localisation is provided by tracklang, but it enables support to be easily added and maintained independently from a package (that uses the tracklang interface) with ldf files that have a particular naming scheme.

This means that by adding a file called datatool-〈locale〉.ldf to TeX’s path, the file can automatically be loaded by datatool-base without any adjustments to the datatool-base code. There is a search order for 〈locale〉 to allow for fine grained support. See the tracklang documentation for further details or the “Locale Sensitive Files” section of Using tracklang in Packages with Localisation Features.

The tracklang package has limitations, but you may be able to supply the language identifier as a document class option, for example:

🖹
\documentclass[british]{article}

🖹
\usepackage[british]{babel}
\usepackage{datatool-base}

🖹
\usepackage[locales=en-GB]{datatool-base}

Note that this option will have an effect on packages that are subsequently loaded that also use tracklang. Likewise, if you have already loaded a package that uses tracklang (such as datetime2) then the tracked locales from that will be picked up. For example:

🖹
\usepackage[en-GB]{datetime2}
\usepackage{datatool-base}

For some packages (such as databib and person), the localisation support just relates to translating fixed text and the corresponding filename may simply have 〈locale〉 as the tracklang root language label. So regardless of whether you have used locales=en-GB or locales=en-US, the person package will require the file person-english.ldf (provided with datatool-english).

However, settings such as the currency symbol are specific to a region not a language. So locales=en-GB would need the default currency switched to GBP whereas locales=en-IE would need the default currency switched to EUR and locales=en-ZA would need the default currency switched to ZAR.

Therefore, localisation support for datatool-base (and its supplementary packages) is split into two parts: the language file datatool-〈language〉.ldf (for example, datatool-english.ldf) which deals with the orthography, translations of fixed text, and other language-specific code, and the region file datatool-〈region〉.ldf (for example, datatool-GB.ldf) which deals with language-independent region code. You will need both files for full support but partial support can be obtained if one is missing.

The region files are fairly straightforward (albeit time-consuming) to create. They are therefore all bundled together in a single distribution datatool-regions which needs to be installed in addition to installing datatool. See §2.3.4 for further details.

Locale-sensitive commands that relate to regions may all be reset back to their original definitions with:

The language files are more complicated and require knowledge of someone familiar with the language. Each language bundle should therefore be developed independently by a maintainer fluent in the language and it will need to be installed in addition to installing datatool. At the time of writing, only datatool-english is available, but you can copy and adapt it as appropriate. (Don’t add me as author or maintainer of your contribution.) The datatool-english bundle includes limited support for Old English (Anglo-Saxon) for Latin and Runic scripts, which may be used as examples for extended Latin or non-Latin languages. See §2.3.5 for further details.

Locale-sensitive commands that relate to language may all be reset back to their original definitions with:

🖹
\usepackage[locales=en-CA]{datatool-base}
\begin{document}
Default currency: \DTLCurrencyCode.

\newcommand{\mylist}{elk,élite,elephant}
\DTLsortwordlist{\mylist}{\DTLsortletterhandler}
Sorted list: \DTLformatlist{\mylist}.
\end{document}

🖹
\usepackage{babel}
\babelprovide{canadianfrench}
\usepackage{datatool-base}
\begin{document}
Default currency: \DTLCurrencyCode.

\newcommand{\mylist}{elk,élite,elephant}
\DTLsortwordlist{\mylist}{\DTLsortletterhandler}
Sorted list: \DTLformatlist{\mylist}.
\end{document}

Localisation files may provide options. These are define with: \datatoollocaledefinekeys:nn This is simply a shortcut that uses \keys_define:nn. The 〈module〉 should be the applicable language code (for example, “en”) or region code (for example, “GB”) or tag (for example, “en-CA” or “fr-CA”), depending on what kind of support the file provides. Sub-modules may also be specified.

These options can be set in the document with:

For example, with datatool-GB.ldf the parent module is “GB” and there are no sub-modules. To switch number style:

🖹
\DTLsetLocaleOptions{GB}{number-style=education}

🖹
\DTLsetLocaleOptions{CA,GB}{currency-symbol-prefix}

The databib-english.ldf has parent module “en” and sub-module “databib”. To switch the way month names are abbreviated for the abbrv style:

🖹
\DTLsetLocaleOptions[en]{databib}{short-month-style=dotless}

🖹
\DTLsetLocaleOptions{en/databib}{short-month-style=dotless}

The unstarred form uses: \datatoolsetlocaleoptions:nn This iterates over each module and sets the provided options using \keys_set:nn, which will trigger an error for unknown options.

The starred form uses: \datatoolsetlocaleoptions:nn This iterates over each module and sets the provided options using \keys_set_known:nn, which won’t trigger an error for unknown options.

If you want to directly use the l3keys functions, the module path should be prefixed with “datatool / locale /”.

2.3.1. Encoding[link]

In recent years, the LaTeX kernel has provided significant improvements to UTF-8 support for pdfLaTeX. (The newer engines, XeLaTeX and LuaLaTeX are natively UTF-8.) In particular, even if you don’t load inputenc, the document is now assumed to be UTF-8 (whereas in the past the default encoding was ASCII).

To assist localisation files, the datatool-base package provides both a string (detokenized) variable and corresponding token list variables that expand to common symbols (mostly currency) that are included in Unicode and may be of use with localisation. These variables are first defined to expand to an approximate ASCII representation, but then will be redefined if the relevant datatool-〈encoding〉.ldf file is found. This means that unsupported encodings will fallback on ASCII values. There is limited support for ISO-8859-1 (cent, pound, currency and yen).

For example, datatool-GB.ldf defines the GBP currency as follows:

\datatool_def_currency:nnnV
 { \datatoolGBcurrencyfmt }
 { GBP }
 { \pounds }
 \l_datatool_pound_tl

If any of the currency symbols are available in the current encoding, they will be added to the currency signs regular expression variable:

2.3.2. Numerical[link]

Non locale-sensitive numeric commands (such as \dtladd) require plain numbers with a period/full stop decimal point (.) and no number group character or currency symbol.

Numeric commands for formatted numbers (such as \DTLadd) parse their values for the currency symbol, decimal character and number group character. The number group character is only used in integers and before the decimal character in decimal and currency values. The decimal character is only relevant to decimal numbers and currency values.

With LaTeX3 syntax enabled, the following may be used instead.

For more complex parsing requirements, regular expressions can be provided to match the number group character and decimal character sub-groups:

The following are just shortcuts that use one of the above.

The region file should register the currency code with:

The prefix command may either expand to nothing or to:

Region files should provide a hook called

Similarly, a hook to set the current number group character and decimal character:

If you simply want to typeset plain numbers as formatted numbers then consider using siunitx instead. However you can use the following, which picks up the above settings.

If the supplied value is not a plain number then a warning will occur and the result will be a string. This is to allow for databases that contain missing value markup, such as “N/A” or \textemdash.

For example

🖹
\documentclass{article}
\usepackage[en-GB]{datatool-base}
\begin{document}
\DTLdecimaltocurrency{1234.5672}{\result}% parse number
Result: \result.
Value: \DTLdatumvalue{\result}.
\end{document}

2.3.3. Lexicographical[link]

The commands described in this section are used by string sorting and initial letter commands to enable locale-sensitive functions to be used, if available.

The handler definition will usually depend on the encoding. For example, datatool-english-utf8.ldf defines \DTLenLocaleHandler and the following is added (indirectly) to the language hook (see §2.3.5):

\let\DTLCurrentLocaleWordHandler\DTLenLocaleHandler

For example

As with the English handler, the punctuation characters can be adjusted to ensure that they are placed before “A”. This means that the final uppercase letters “Þ”, “Æ” and “Ö” can be reassigned to the character positions after “Z” and the lowercase “þ”, “æ” and “ö” can be reassigned to the character positions after “z” (similar to datatool-ang-Latn.ldf). The other characters need to be positioned between Basic Latin characters. For example, “Á” needs to be between “A” and “B”. This can be achieved by replacing uppercase “Á” with “A” followed by the control character 0x7F (which is the final ASCII character). Similarly lowercase “á” is replaced by “a” followed by 0x7F and so on.

The language code for Icelandic is “is” so it will be used in the command names. Remember that \l_datatool_current_language_tl will need to be redefined to match. (Alternatively, “isl” or “ice” could also be used but the important thing is to be consistent in the event that a region file tries searching for a command name to determine if it’s supported for the current language.)

🖹
\ExplSyntaxOn
\newcommand {\DTLisLocaleHandler} [ 1 ]
{
  \regex_replace_case_all:nN
  {
    { Á } { A\cL\x{7f} } { á } { a\cL\x{7f} }
    { Ð } { D\cL\x{7f} } { ð } { d\cL\x{7f} }
    { É } { E\cL\x{7f} } { é } { e\cL\x{7f} }
    { Í } { I\cL\x{7f} } { í } { i\cL\x{7f} }
    { Ó } { O\cL\x{7f} } { ó } { o\cL\x{7f} }
    { Ú } { U\cL\x{7f} } { ú } { u\cL\x{7f} }
    { Ý } { Y\cL\x{7f} } { ý } { y\cL\x{7f} }
    { Þ } { \cL\x{5b} } { þ } { \cL\x{7b} }
    { Æ } { \cL\x{5c} } { æ } { \cL\x{7c} }
    { Ö } { \cL\x{5d} } { ö } { \cL\x{7d} }
% currency signs and punctuation
% […]
  }
  #1
}
\ExplSyntaxOff

For example, the string “az” will be unchanged and has the byte sequence 0x61 0x7A. Whereas the string “áa” will be converted by the above Icelandic handler to the byte sequence 0x61 0x7F 0x61. Since 0x7A is less than 0x7F, “az” comes before “áa”. With the English handler, “áa” will be converted to “aa” which has the byte sequence 0x61 0x61. Since 0x61 is less than 0x7A, “áa” would come before “az”.

Note the use of \cL to ensure that the replacement characters have a letter category code (even though they’re not actually letters). This will allow the process to be reversed without changing punctuation characters that were originally present in the sort string (see Example 12).

The language hook (see §2.3.5) then needs to set the locale handler:

🖹
\let\DTLCurrentLocaleWordHandler\DTLisLocaleHandler

Example 10 uses the above to sort a list of words:

🖹
\newcommand{\mylist}{bókstafinn, vera, eða, ég, býsna, 
þú, vakna, epli, bragðs, aldar, bað, bolli, ýmist, af,
óáreiðanleg, bær, dalur, ör, þorn, þau, október, esja, 
öngull, dæmi, að, yfir, öðrum, orð, detta, áhrif, yngri, 
óvinur, ætlað}

\DTLsortwordlist{\mylist}{\DTLsortletterhandler}
Sorted list: \DTLformatlist{\mylist}.

For example, datatool-english.ldf sets 〈cs〉 to the sort value as this ensures that any supported accented characters and ligatures will have already been converted to Basic Latin characters.

However datatool-ang-Latn.ldf and datatool-ang-Runr.ldf can’t do this as the construction of the sort value means that the characters in the sort value may be significantly different from the actual letters. In this case, the original value must be used instead, but it’s needs some processing to map extended characters to their equivalent sort group. For example, “Ǽ” needs to be mapped to “Æ”. Additionally, the actual value is likely to need pre-processing with \datatool_sort_preprocess:Nn.

This command is intended for use with sorting functions to obtain the letter group, so the actual letter returned may not be the initial letter. For example, if the word starts with the ligature “Æ” then the localisation may return “A” rather than “Æ”.

For example, datatool-english.ldf defines:

\newcommand{\DTLenLocaleGetInitialLetter}[2]{
  \datatool_get_first_letter:nN { #1 } #2
  \DTLenLocaleHandler #2
  \int_compare:nNnT { \tl_count:N #2 } > { \c_one_int }
   {
     \exp_args:NV \datatool_get_first_letter:nN #2 #2
   }
}

\let\DTLCurrentLocaleGetInitialLetter
 \DTLenLocaleGetInitialLetter

🖹
\newcommand{\DTLdutchLocaleGetInitialLetter}[2]{
  \tl_clear:N #2
  \text_map_inline:nn { #1 }
  {
    \tl_if_empty:NTF #2
     {
       \datatool_if_letter:nT { ##1 }
        {
          \tl_set:Nn #2 { ##1 }
          \tl_if_in:nnF { Ii }  ##1  { \text_map_break: }
        }
     }
     {
       \tl_if_in:nnT { Jj } { ##1 }
        {
          \tl_put_right:Nn #2 { ##1 }
        }
       \text_map_break:
     }
  }
}

\let\DTLCurrentLocaleGetInitialLetter
 \DTLdutchLocaleGetInitialLetter

🖹
IJsselmeer: \DTLinitials{IJsselmeer}
Industrieel: \DTLinitials{Industrieel}
``IJsselmeer'': \DTLinitials{``IJsselmeer''}
``Industrieel'': \DTLinitials{``Industrieel''}

Remember that \DTLCurrentLocaleGetInitialLetter is also used to obtain the letter group (but not the non-letter group) from sort values with \DTLsortwordlist.

The content used to obtain the group letter may be either the original (“actual”) string or the sort value. This is determined by \DTLCurrentLocaleGetGroupString. For example, datatool-english.ldf uses the sort value, since all the extended characters are mapped to Basic Latin letters. In this case, we have some awkward control characters which will mess up the letter group.

There are two ways of dealing with this. The first method is the case used by datatool-ang-Latn.ldf which defines \DTLangLatnLocaleGetGroupString. That starts with the actual value and processes it with \datatool_sort_preprocess:Nn and then replaces any leading accented character with the unaccented letter.

The second method is used here. This starts with the sort value and reverses the mapping applied by the handler. In this case, a localisation file that provides \DTLisLocaleHandler would also need to provide a way of reversing the substitutions for the letter groups. Since the replacement (non-alphabetic) characters are assigned the letter category code, this makes them easier to distinguish from actual punctuation characters.

🖹
\newcommand{\DTLisLocaleGetGroupString}[3]{
  \tl_set:Nn #3 { #2 }
  \regex_replace_case_once:nN
   {
     { A\cL\x{7f} } { Á } { a\cL\x{7f} } { á }
     { D\cL\x{7f} } { Ð } { d\cL\x{7f} } { ð }
     { E\cL\x{7f} } { É } { e\cL\x{7f} } { é }
     { I\cL\x{7f} } { Í } { i\cL\x{7f} } { í }
     { O\cL\x{7f} } { Ó } { o\cL\x{7f} } { ó }
     { U\cL\x{7f} } { Ú } { u\cL\x{7f} } { ú }
     { Y\cL\x{7f} } { Ý } { y\cL\x{7f} } { ý }
     { \cL\x{5b} } { Þ } { \cL\x{7b} } { þ }
     { \cL\x{5c} } { Æ } { \cL\x{7c} } { æ }
     { \cL\x{5d} } { Ö } { \cL\x{7d} } { ö }
   } #3
}

Suppose that this has been implemented via a language hook (see §2.3.5):

\let\DTLCurrentLocaleGetInitialLetter
 \DTLisLocaleGetInitialLetter

🖹
\DTLsortwordlist{\mylist}{\DTLsortletterhandler}
\renewcommand{\DTLlistformatitem}[1]{#1 (\DTLsortedletter{#1})}
Sorted list: \DTLformatlist{\mylist}.

For the Icelandic word sort handler in Example 10, the 〈character〉 will always be the double-quote " because of the final substitution case in the regular expression. For the handler provided in datatool-english-utf8.ldf (see §2.3.5), the character will either be a double-quote " or a literal dollar $ (with category code other).

2.3.4. Adding New Region Support[link]

The language-independent region files are all bundled together in a single distribution datatool-regions which is separate from the core datatool distribution and available on GitHub (https://github.com/nlct/datatool-regions). There are currently only a limited number of regions supported but more can be added via a pull request and only the datatool-regions collection need be uploaded, without the extra overhead of producing a new version of datatool.

The region file deals with setting the default currency, number group character and decimal character, and also the numeric date formats for use with parse=region or parse=iso+region. Note that any date formats that have textual parts (such as month names) should be dealt with by the language support.

A more specific datatool-〈lang〉-〈region〉.ldf file may be used to override any of these settings but that file should be provided with the corresponding language support (see §2.3.5). For example, datatool-english provides datatool-en-CA.ldf to set the number group character and decimal character since it varies according to the language for that region.

2.3.5. Adding New Language Support[link]

The datatool-english package (distributed separately) may be used as an example. (The datatool-english bundle includes databib-english.ldf to provide localisation support for the databib package, and person-english.ldf to provide localisation support for the person package, see §§7.11 & 9.7.3 for further details.)

The datatool-english bundle also includes limited support for Old English (Anglo-Saxon) for Latin and Runic scripts, which may be used as examples for extended Latin or non-Latin languages.

The language file should be called datatool-〈language〉.ldf where 〈language〉 is the root language label (tracklang label). Using the root language label ensures that it’s the last in tracklang’s file search list, which means that it can be overridden by a more specific label, if required. So in the event that there is some particular language setting that is specific to a particular region, a language module may also include a file named datatool-〈lang〉-〈region〉.ldf where 〈lang〉 is the language code (such as “fr”) and 〈region〉 is the region code (such as “CA”).. For example:

🖹
\TrackLangProvidesResource{fr-CA}
\TrackLangRequireResource{french}
\ExplSyntaxOn
\newcommand\datatoolfrCASetNumberChars
{
 \bool_if:NT \l_datatool_region_set_numberchars_bool
  
    \DTLsetnumberchars{.}{,}% number group and decimal symbol
 
  
}
\newcommand\DTLfrCALocaleHook
{
 \datatoolfrCASetNumberChars
}
\ExplSyntaxOff
\TrackLangAddToCaptions{\DTLfrCALocaleHook}

In the case of datatool-english, the root language label is “english” (even if the language has been specified using a dialect label, such as “british”) so the filename is datatool-english.ldf. The file needs to identify itself (analogous to \ProvidesPackage for packages):

\TrackLangProvidesResource{〈language〉}[〈yyyy〉/〈mm〉/〈dd〉 v〈version〉]

The datatool-english bundle includes (limited) support for ISO-8859-1 (Latin-1) and ASCII in addition to UTF-8. The encoding support is provided in the files datatool-english-latin1.ldf, datatool-english-ascii.ldf and datatool-english-utf8.ldf. The following code will input the appropriate file or fallback on the ASCII file if the encoding isn’t supported:

\TrackLangRequestResource{english-\TrackLangEncodingName}
{
  \TrackLangRequireResource{english-ascii}
}

Compare this with the Anglo-Saxon support. The root language label is “anglosaxon” so there is a file called datatool-anglosaxon.ldf but because there are two different scripts to cater for, it just ensures that the appropriate file is loaded.

\TrackLangProvidesResource{anglosaxon}
\TrackLangRequestResource
 {ang-\CurrentTrackedDialectScript-\TrackLangEncodingName}
{% 
 \PackageWarning{datatool-anglosaxon}% 
  {% 
    No support for `anglosaxon' with script
    `\CurrentTrackedDialectScript'
    and encoding `\TrackLangEncodingName'% 
  }% 
}

For example, a package may provide a command called, say \runic, which expects Latin characters in the argument but the font encoding ensures that those characters appear as runes in the PDF. In this case, the source is Latin and so “ang-Latn” is needed when specifying the locale.

If, however, the source code actually contains characters from the Runic Unicode block (with an appropriate font that supports those characters), the source is Runic and so “ang-Runr” is needed when specifying the locale.

The files datatool-ang-Latn.ldf and datatool-ang-Runr.ldf are similar to datatool-english.ldf but, in these cases, there’s no fallback to ASCII as it doesn’t cover all characters from the Latin script and doesn’t cover any for the Runic script. Instead, if the encoding isn’t supported, then no localisation can be provided. For example, datatool-ang-Latn.ldf starts with:

\TrackLangProvidesResource{ang-Latn}
\TrackLangRequestResource{ang-Latn-\TrackLangEncodingName}
{% 
  \PackageWarning{datatool-ang-Latn}% 
   {% 
     No support for `anglosaxon' with script `Latn'
     and encoding `\TrackLangEncodingName'.% 
   }% 
  \endinput
}

For both the English and Old English support, we will be using some LaTeX3 syntax, so the appropriate category codes must be changed:

\ExplSyntaxOn

The definition of \DTLenLocaleGetGroupString ensures that the letter group is obtained from the sort value rather than the actual value:

\newcommand\DTLenLocaleGetGroupString[3]
{
 \tl_set:Nn #3 { #2 }
}

This conveniently works for English, which just maps extended characters to Basic Latin letters (A–Z, a–z), but will cause a problem for Anglo-Saxon, both Latin and Runic. In the case of datatool-ang-Latn.ldf, the extended characters Ƿ (wynn), Ð (eth), Æ (AE-ligature), Þ (thorn) are converted to the character codes following “Z” and, similarly, the lowercase ƿ, ð, æ, þ are converted to the character codes following “z”. This means that if the sort value is used to obtain the letter group, then these extended characters will be assigned to the non-letter group.

Therefore, it’s necessary to use the actual value rather than the sort value, but some additional processing is required to ensure that characters with diacritics are placed in the same group as the unaccented character. For example, “Ǽ” needs to be mapped to “Æ”. This is performed by a low-level function that performs a regular expression substitution.

Note that this doesn’t take into account a sort handler that strips content, such as the letter handler functions that remove spaces and hyphens. This will cause a problem for any words that start with a hyphen. Since the handler function \DTLangLatnLocaleHandler inserts a double-quote character in front of any punctuation, it’s possible to check if the actual value starts with a hyphen and if the sort value starts with a double-quote then the hyphen likely wasn’t stripped so it can be removed. This is done as follows:

\newcommand \DTLangLatnLocaleGetGroupString { 3 }
 {
   \tl_set:Nn #3 { #1 }
   \datatool_angLatn_process_letter_group:N #3
   \bool_lazy_and:nnT
     { \tl_if_head_eq_charcode_p:nN { #1 } - }
     { \bool_not_p:n { \tl_if_head_eq_charcode_p:nN { #2 } " } }
    {
      \exp_args:NNe \tl_set:Nn #3 { \tl_tail:N #3 }
    }
 }

In the case of datatool-ang-Runr.ldf there are no hyphens to worry about so it’s far simpler to just assign the token list variable to the actual value. Any further processing is down to whether or not the sort handler considers multiple runes to be considered equivalent for sorting purposes.

For both English and the two different scripts of Old English, the support for \DTLCurrentLocaleGetInitialLetter is the same as the default definition provided by datatool-base. For example, datatool-english.ldf defines:

\newcommand \DTLenLocaleGetInitialLetter [ 2 ]
 {
   \datatool_get_first_letter:nN { #1 } #2
 }

The only other support provided by datatool-ang-Latn.ldf and datatool-ang-Runr.ldf is to redefine \DTLandname to use the Tironian et.

Returning to datatool-english.ldf, support is provided to produce textual labels for the non-letter group, number group, currency group and temporal group commands:

\newcommand \DTLenSetLetterGroups
 {
  \renewcommand \dtllettergroup [ 1 ]
    { \text_titlecase_first:n { ##1 } }
  \renewcommand \dtlnonlettergroup [ 1 ] { Symbols }
  \renewcommand \dtlnumbergroup [ 1 ] { Numbers }
  \renewcommand \dtlcurrencygroup [ 2 ] { Currency }
  \renewcommand \dtldatetimegroup [ 1 ] { Timestamps }
  \renewcommand \dtldategroup [ 1 ] { Dates }
  \renewcommand \dtltimegroup [ 1 ] { Times }
 }

(Some of the supplementary packages have additional fixed-text commands, but they are dealt with in their own ldf files.) An intermediate command is defined to set \DTLandname:

\newcommand \DTLenSetAndName
 {
  \renewcommand \DTLandname { and }
 }

\datatool_locale_define_keys:nn { en }
 {
    and .choice:,
    and / word .code:n =
     {
      \renewcommand \DTLenSetAndName
       {
         \renewcommand \DTLandname { and }
       }
      \tl_if_eq:NnT \l_datatool_current_language_tl { en }
       { \DTLenSetAndName }
     } ,
    and / amp .code:n =
     {
      \renewcommand \DTLenSetAndName
       {
         \renewcommand \DTLandname { \& }
       }
      \tl_if_eq:NnT \l_datatool_current_language_tl { en }
       { \DTLenSetAndName }
     } ,
 }

\newcommand \DTLenTranslations
 {
  \DTLenSetAndName
  \renewcommand \DTLdatatypeunsetname { unset }
  \renewcommand \DTLdatatypestringname { string }
  \renewcommand \DTLdatatypeintegername { integer }
  \renewcommand \DTLdatatypedecimalname { decimal }
  \renewcommand \DTLdatatypecurrencyname { currency }
  \renewcommand \DTLdatatypedatetimename { date-time }
  \renewcommand \DTLdatatypedatename { date }
  \renewcommand \DTLdatatypetimename { time }
  \renewcommand \DTLdatatypeinvalidname { invalid }
 }

After that comes the support for date and time formatting, but it’s still experimental.

As with the region datatool-GB.ldf file, describe in §2.3.4, a single intermediate command is defined that will be added to the captions hook:

\newcommand \DTLenLocaleHook
 {
  \renewcommand
    \DTLCurrentLocaleWordHandler
    { \DTLenLocaleHandler }
  \renewcommand
    \DTLCurrentLocaleGetInitialLetter
    { \DTLenLocaleGetInitialLetter }
  \renewcommand
    \DTLCurrentLocaleGetGroupString
    { \DTLenLocaleGetGroupString }
  \DTLenSetLetterGroups
% date and time assignments
% […]
  \tl_set:Nn \l_datatool_current_language_tl { en }
% Fixed text command:
  \DTLenTranslations
}
\ExplSyntaxOff
\TrackLangAddToCaptions{\DTLenLocaleHook}

Note that each language file should ensure that the caption hook sets the token list variable:

\tl_set:Nn \l_datatool_current_language_tl { angLatn }

\tl_set:Nn \l_datatool_current_language_tl { angRunr }

The locale handlers are provided in the encoding files. For example, \DTLenLocaleHandler is provided in datatool-english-utf8.ldf, datatool-english-latin1.ldf and datatool-english-ascii.ldf. This is used to convert strings into byte sequences for lexicographical comparisons. For example, datatool-english-utf8.ldf replaces common extended Latin characters into the nearest ASCII equivalent, suitable for English ordering. This can conveniently be done with regular expression replacement.

\cs_new:Npn \DTLenLocaleHandler #1
{
  \regex_replace_case_all:nN
  { 
% alphabetical cases
% [ … ]
    { (\ur{l_datatool_currencysigns_regex}) } { \cO\x{24}\1 }
    { ’ } { \cO"' }
    { ‘ } { \cO"` }
    { (“|”) } { \cO"\cO" }
    { (—|–) } { \cO"- }
    { ([[:punct:]]+) } { \cO"\1 }
  } 
  #1
}

In the case of a non-Latin script, such as Runic, the conversion simply ensures that the characters follow the appropriate order when the character codes are compared. For example, datatool-ang-Runr.ldf provides two different ways of ordering the runes. The first mostly follows the order in the Runic Unicode block. So feoh (U+16A0) is mapped to character code 31, Runic V (U+16A1) is mapped to character code 32, etc. The second follows the Old English rune poem order (fuþorc) so feoh (U+16A0) is mapped to character code 31, ur (U+16A2) is mapped to character code 32, thorn (U+16A6) is mapped to character code 33, etc.

2.4. Conditionals[link]

There are two types of conditional commands provided by datatool-base: those with {〈true〉}{〈false〉} arguments (such as \DTLifint) or case arguments (such as \DTLifcasedatatype) and those that are designed to be used in the conditional part of \ifthenelse (provided by the ifthen package). The first type have command names that start “DTLif” or “dtlif” and are described in §2.4.1, and the second type have command names starting “DTLis” and are described in §2.4.2.

2.4.1. If-Else or Case Conditionals[link]

The robust commands listed in §2.4.1.2, such as \DTLifstringeq, treat their arguments as strings. For example, \DTLifstringlt is a test if one string is lexicographical less than another.

The robust numeric “DTLif” commands listed in §2.4.1.3, such as \DTLifnumeq, expect formatted numbers or datum control sequences in the numeric arguments. If you know that all your values are plain numbers, the “dtlif” listed in §2.4.1.4 commands are quicker.

Numeric commands listed in §2.4.1.4, such as \dtlifnumeq, don’t parse for the current decimal character and number group character or for a currency symbol. They require a plain number, either a bare integer (such as 12345) or a number with a decimal point (such as 1234.5). These commands are listed as being provided by datatool-base, but are actually defined in the maths processor file datatool-〈processor〉.def corresponding to the value of the math package option. With math=l3fp or math=lua, these commands are expandable but with math=fp or math=pgfmath they are robust. Note that the fp package doesn’t support scientific notation.

The multi-type robust commands listed in §2.4.1.5, such as \DTLifeq, parse the arguments to determine the data type and then use the corresponding command from §2.4.1.3 or §2.4.1.2.

2.4.1.1. Data Type Conditionals[link]

The commands described in this section test the data type of the argument according to the current settings for the number group character and decimal character and recognised currency symbols.

2.4.1.1.1. Test if Integer Example[link]

🖹
2536: \DTLifint{2536}{integer}{not an integer}.

2536.0: \DTLifint{2536.0}{integer}{not an integer}.

2,536: \DTLifint{2,536}{integer}{not an integer}.

2,5,3,6: \DTLifint{2,5,3,6}{integer}{not an integer}.

\DTLparse{\numA}{2,536}
\numA: \DTLifint{\numA}{integer}{not an integer}.

\DTLsetnumberchars{.}{,}% 
2,536: \DTLifint{2,536}{integer}{not an integer}.

2.536: \DTLifint{2.536}{integer}{not an integer}.

\numA: \DTLifint{\numA}{integer}{not an integer}.

2.4.1.1.2. Test if Decimal Example[link]

🖹
1000.0: \DTLifreal{1000.0}{real}{not real}.

1,000: \DTLifreal{1,000}{real}{not real}.

1,000.0: \DTLifreal{1,000.0}{real}{not real}.

1e+3: \DTLifreal{1e+3}{real}{not real}.

\DTLsetnumberchars{.}{,}% 
1,000.0: \DTLifreal{1,000.0}{real}{not real}.

1.000,0: \DTLifreal{1.000,0}{real}{not real}.

2.4.1.1.3. Test if Currency Example[link]

🖹
\$5.99: \DTLifcurrency{\$5.99}{currency}{not currency}.

\DTLcurrency{5.99}:
\DTLifcurrency{\DTLcurrency{5.99}}{currency}{not currency}.

\pounds5.99:
\DTLifcurrency{\pounds5.99}{currency}{not currency}.

\textsterling5.99:
\DTLifcurrency{\textsterling5.99}{currency}{not currency}.

\$6.99:
\DTLifcurrencyunit{\$6.99}{\$}{dollars}{not dollars}.

\newcommand{\cost}{\pounds10.50}% 
\cost: \DTLifcurrencyunit{\cost}{\pounds}{pounds}{not pounds}.

US\$5.99:
\DTLifcurrency{US\$}{currency}{not currency}.

\DTLnewcurrencysymbol{US\$}% 
US\$5.99:
\DTLifcurrency{US\$}{currency}{not currency}.

2.4.1.1.4. Test if Numerical Example[link]

🖹
1,234: \DTLifnumerical{1,234}{numeric}{not numeric}.

1,234.0: \DTLifnumerical{1,234.0}{numeric}{not numeric}.

\$1,234.0:
\DTLifnumerical{\$1,234.0}{numeric}{not numeric}.

1.234,0: \DTLifnumerical{1.234,0}{numeric}{not numeric}.

\DTLsetnumberchars{.}{,}% 
1.234,0: \DTLifnumerical{1.234,0}{numeric}{not numeric}.

Empty: \DTLifnumerical{}{numeric}{not numeric}.

2.4.1.1.5. Test if String Example[link]

🖹
1,234: \DTLifstring{1,234}{string}{not string}.

\$1,234.0: \DTLifstring{\$1,234.0}{string}{not string}.

1,2,3,4: \DTLifstring{1,2,3,4}{string}{not string}.

Empty: \DTLifstring{}{string}{not string}.

2.4.1.1.6. Test Data Type Example[link]

🖹
1,234: \DTLifcasedatatype{1,234}{string}{int}{real}{currency}.

1,234.0: \DTLifcasedatatype{1,234.0}{string}{int}{real}{currency}.

\$1,234: \DTLifcasedatatype{\$1,234}{string}{int}{real}{currency}.

1,2,3,4: \DTLifcasedatatype{1,2,3,4}{string}{int}{real}{currency}.

Empty: \DTLifcasedatatype{}{string}{int}{real}{currency}.

2.4.1.2. String and List Conditionals[link]

The following comparison commands test for lexicographically equality, less than (comes before) and greater than (comes after). The string arguments have a single expansion applied on the first token and then they are expanded in the same way as for \dtlcompare and \dtlicompare, taking into account the compare settings (see Example 20).