Werner Lemberg writes: > But this is the wrong list for such bug reports. You should address it to > [log in to unmask] . well not really :-) or not in this form anyway. for latex-bugs we ask for a short but complete test file with full log. that would mean some constructing. anyway, i think this is more on the level of concepts and thus could well be within this list (even if it is boring for one or the other). as for the use of inputenc a few words on the concepts: latex has the concept of font-encoding specific commands, which are those that are defined via \DeclareText<something> usually in font encoding files, eg T1enc.def those commands + (more or less :-) the visible portion of ascii forms what i call "latex's internal representation of glyphs" it has the caracteristic that it is all represented by 7bit ascii, ie either something like a, b or command names or combination thereof and that all of it is invariant to writing out to files and reading in. so if \foo is an encoding specific command that appears in some \write to the aux file it will end up as \foo (more exactly it will end up with one additional space after it but that is not relevant for the input reading mechanism) so the model is something like inputenc T<something> hex ?? ---------> internal ------> some glyph slot number | | | T<somethingelse> V A ------------> or some fake construction | | ------ invarient to .aux etc processing this model abstracts from the input encoding by allowing the user to use any input encoding that translates into the internal representation and it abstracts from the output encoding, ie the font encoding which means that even if i have fonts which are differently encoded (but contain the appropriate glyphs) i can the document and if characters in my fonts are missing i do get proper warning. now what goes wrong in your first approach is that you have an inputenc file that doesn't use this model, ie it translates one hex into some other hex directly, ie \CYRA is most likely something along \char ... probably just ^^xy in other words you pass as internal an slot position in a particular font rather than an abstract object that only at the last stage (before shipping out to the dvi file basically) gets translated. thus when coming to process the toc file your font encoding slot is now interpreted as an input encoding slot and probably ^^8f is not defined in the inputencoding (it would not make it better only differnt :-) your second example does work because it mainly uses a passthrough concept making the font encoding the internal representation. but that works only if in all places you do have the same font encoding. therefore reading it back in the font encoding form does not do any harm, it would do if at that point you have a different font encoding the inputenc/fontenc model allows you to typeset the toc in a different font that does have a different font encoding that is conceptionally the case. things get a bit muddled as babel is older software and currently restricts some of that potential power (which is why we do need a new language interface). really good night frank ps Werner, for the reason giving above your advice given (to use \char ... is not correct either) it is true that the particular examplethen will probably work but only just ---- the internal representation is not a slot position it should be a encoding specific command of some sort