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