## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

 Subject: Re: [Bug Report] Problem with INPUTENC package and TOC files. From: Frank Mittelbach <[log in to unmask]> Reply To: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Mon, 16 Jun 1997 23:10:21 +0200 Content-Type: text/plain Parts/Attachments: text/plain (85 lines)
Werner Lemberg writes:
> But this is the wrong list for such bug reports. You should address it to

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

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