Mon, 16 Jun 1997 23:10:21 +0200
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
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
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
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