Hello, After Hans/Taco succesfully fixed the \dstroke problem (and it already seemed that I will stop annoying for a while ;), I noticed another strange behaviour after the discussion on tex-font mailing list. (Adam: the discussion seems to have brought some benefit after all :) Can someone take a look into the difference between [st]cedilla and [st]commaaccent? I have a strange feeling that something is wrong in the way ConTeXt renders them. \tcedilla, \scedilla both expand into what should be \tcommaaccent and \scommaaccent. The four definitions in enco-def.tex are OK: \definecharacter Scedilla {\buildtextcedilla S} \definecharacter scedilla {\buildtextcedilla s} \definecharacter Tcedilla {\buildtextcedilla T} \definecharacter tcedilla {\buildtextcedilla t} ... but they are lost somewhere. I don't know where they turn into "commaaccent"-ed ones if texnansi encoding is used (in ec endoding they are present and (wrongly?) mapped to [st]commaaccent). But these four definitions are probably strange: \definecharacter scommaaccent {s\quoteright} \definecharacter Scommaaccent {S\quoteright} \definecharacter tcommaaccent {t\quoteright} \definecharacter Tcommaaccent {T\quoteright} Is there a good way to render (=fake) them properly? If yes (I think they are properly faked at some place already, at least in texnansi if nowhere else), than also kcommaaccent, lcommaaccent, ncommaaccent and rcommaaccent can be added to these four definitions (gkommaaccent seems to be slightly different). One question arises however. In Unicode reference it states that tcedilla is a deprecated glyph in Romanian and that tcommaaccent should be used instead. It seems that ConTeXt does exactly that at the moment (Adobe screwed up in their glyph list anyway), but in my opinion \tcedilla should stand for "t with cedilla" no matter what is deprecated and what not. Let's not repeat the Adobe's mistake! It should be documented somewhere (in the wiki?) that if someone insists in automatically mapping tcedilla to tcommaaccent, this can be done in a few lines, but this should not be the default behaviour. We can perhaps map \c{t} or "t to tcedilla if needed instead? (I may be wrong here - I'm ignorant in this field.) This *does* "break backward compatibility" in a way, the documents using tcedilla/scedilla/... won't be the same any more if files are fixed, but I don't believe that anyone wants to follow the way thing are solved in LaTeX and ask the users to use \twithrealcedilla or something similar instead. I tried to figure out if any language uses "tcedilla" and I didn't find any useful information about that yet (except, if I understood correctly, sometimes in Romanian->English transliterations). So I ask myself: why do cp1250 and iso latin2 have tcedilla instead of tcommaaccent if nobody uses the first one??? Btw: in anco-ans.tex, \textcedilla maps to character 184 "instead of" character 24. With \definetypeface[antykwa][rm][serif][antykwa-torunska][default][encoding=texnansi] \setupbodyfont[antykwa] this fails because texnansi-antt.enc has a .notdef at slot 184 (perhaps this .enc file could be "fixed" as well, if I may call that "fixing"). It would be great if someone from Romania or Turkey would be reading that and could say a word about it. All the information I have are the (fuzzy) standards, full of mistakes, which "cannot easily be fixed". Mojca