Hans Hagen wrote:
if you use regimes:
input encoding font encoding
<active char> => \namedglyph => 8bit char | fallback
OK, thanks. I didn't check if this works, but I hope the problem will finally be solved now: In enco-ec.tex change \definecharacter dmacron 158 into \definecharacter dstroke 158 and add \definecharacter Dstroke 208 % perhaps also something like \definecharacter dcroat 158 % but I think that you deal with synonyms at some place Please also take a look at lang-hr.pat (or, better, please grep for all occurencies of dbar and dmacron and see if you can get rid of as many of them as possible). Did I miss any other files? Another remark. I'm not sure which name is better, dstroke (unicode-based) or dcroat (adobe-based). ConTeXt seems to have a strange mixture of unicode- and adobe- based names. "hungarumlaut" is adobe-based, while "diaeresis" is unicode-based for example. I don't want to introduce just another name, incompatible with any standards. This additional patch below is the wrong way of doing things. It gives wrong result in the sense that the copy-paste will result in wrong character codes (and that a Croat won't notice that he's using the wrong encoding, just as I didn't notice anything weird in ccaron for a long time), but the resulting glyphs in PDF will be better and in the printed material this won't be seen, which is the most important part. If you use fallback, the results are worse in both senses anyway (the document is not any more searchable). So, can you please also add \definecharacter Dstroke 208 to enco-qx.tex and enco-ans.tex? And add also a comment that the glyphs are identical, but the charecters differ, just in case anyone wonders a couple of years later what these dstrokes are doing there. Thank you, Mojca PS: So, let me count: dstroke, dmacron, dbar, dcroat, [wrong] eth, ... any other suggestions for standardisation ;) ?