[dev-context] little unharmful bug in \showfont & using \iffontchar in \definecharacter

[Mojca Miklavec]

Hello,

I spotted a somehow strange behaviour in \showfont. It seems to be
language-dependent for some reason. \showfont draws a gray square if
there is no glyph present on some slot, but sometimes the blue numbers
are drawn in that square and sometimes not. See for example the number
14 and 15 (gray square, numbers) in comparison to 16 and seventeen
(gray square, no numbers) in the next example:

\mainlanguage[sl] % try "en" or leave this line out and compare

\starttext
\showfont[ts1-lmr10]
\font\tslmr=ts1-lmr10

% just to test:
\page
\def\test#1{#1: \getglyph{ts1-lmr10}{\char#1}
{\sl\iffontchar\tslmr#1\else (empty)\fi}\par}
\startcolumns[n=5]
\dostepwiserecurse{0}{39}{1}{\test{\recurselevel}}
\stopcolumns
\stoptext


When trying to understand what \showfont does I started wondering if
it would be feasible to do font-depending encoding-depending
definitions of glyphs (\definecharacter). If \iffontchar exists: why
not using it?

It's stupid to tell to ConTeXt that "ijligature" or "ccaron" exists in
the font although the slot is empty, if ConTeXt could figure that out
from the font itself and then use the fallback definition
\buildtextcaron c instead. This would also reduce the need of files
such as "enco-ecm.tex".

I already asked some time ago if it would be possible to use something
like this:
\starttypescript [whatever font]
    \startencoding [ec]
        \definecharacter ijligature {ij}
        % or
        \undefinecharacter ijligature
        % or
        \definecharacter ijligature {\takethefallbackdefinitionofijligature}
    \stopencoding
\stoptypescript

But even if this was implemented, it would require quite some
error-prone manual work. In contrast to that, \iffontchar would offer
a fully automatic alternative and would solve many problems with
third-party fonts (those that don't mind having TeX-specific
characters).

Mojca