[pdftex] problem with margin kerning

[Reinhard Kotucha]

D. R. Evans writes:
 > Thanh Han The said the following at 01/03/2009 10:13 AM :
 >> I can compile your test file without problem:
 >> 
 >> [...]  
 >> I guess the problem is caused by some conflicting macros
 >> in protcode.tex and your macros. Please don't take protcode.tex
 >> as a reference, but rather as an example.

 > OK. (Sort of; I don't understand at all how exactly the same file can fail
 > here but work there.)
 > 
 > I haven't the foggiest idea how protcode works. I'm a user, not in
 > any sense a TeXpert. So I guess I'll just have to do without margin
 > kerning and leave it as a mystery why it's not working here. Maybe
 > protcode.tex or abbr.tex distributed by Kubuntu is different from
 > what you have (I noticed, for example, that the output following
 > "protcode.tex" is very different when you compile the file than
 > when I do so). It seems like that's where the difference must be.
 > 
 > Anyway, just for the record, here is what happens when I try to compile the
 > file:
 > 
 > ----
 > 
 > [HN:shadow] pdftex test.tex
 > This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
 >  %&-line parsing enabled.
 > entering extended mode
 > (./test.tex (./protcode.tex (./abbr.tex))
 > ! Missing number, treated as zero.
 > <to be read again>
 >                    F
 > �->{\char "F
 >             7}
 > l.36 f�
 >        tid breath swept over Catherine like a warm, noxious gale. She cowered,

I can reproduce the problem.  However, there is one strange thing:
Though your file is displayed properly in Emacs, it seems that that
there is an encoding problem.  Since strange things regarding
encodings can happen in email clients, it's necessary that you check
your file yourself.  It's more secure to make a zipped version of the
file available in order to avoid re-encoding by mail clients.

A possible way to check your file is to load it into Emacs and then
type:  M-x hexl-mode

I get:

00000110: 7673 697a 653d 362e 3735 696e 0a0a 2520  vsize=6.75in..% 
00000120: 9cf4 a0f3 0a5c 6361 7463 6f64 6560 9cf4  .....\catcode`..
00000130: a0f3 3d5c 6163 7469 7665 0a5c 6465 669c  ..=\active.\def.
00000140: f4a0 f37b 7b5c 6368 6172 2246 377d 7d0a  ...{{\char"F7}}.
00000150: 0a5c 6361 7463 6f64 6560 223d 5c61 6374  .\catcode`"=\act
00000160: 6976 650a 5c64 6566 227b 7d0a 0a4c 616e  ive.\def"{}..Lan
00000170: 6469 6e67 206e 6f20 6d6f 7265 2074 6861  ding no more tha

On Unix there is another very simple way to debug such things:

   env LESSCHARSET=ascii less test.tex

The program "less" will then print all non-ASCII characters in
hexadecimal notation.  This is what I get

% <9C><F4><A0><F3>
\catcode`<9C><F4><A0><F3>=\active
\def<9C><F4><A0><F3>{{\char"F7}}

and it explains why test.tex fails here.

But as I said before, these encoding problems can easily be produced
by email clients, hence I'm not sure whether the file I have is the
same as the one you have.  

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------