Bug#50247: might be solvable

["C.M. Connelly" <c@eskimo.com>]

"AK" == Atsuhito Kohda <kohda@nsx.pm.tokushima-u.ac.jp> writes:

   AK> Hmm, I was very confused.  In fact I wish to say;

   AK> If this is true then G might be good for default setting,
   AK> IMHO.

Are you sure?  I thought exactly the opposite.  (I think you're
saying that it would be okay to leave the G in config.pdf,
uncommented.  Let me know if I'm confused.)

   AK> I tested more.

   AK> with \usepackage{times}, and with 'G'       bad ligature 
   AK> with \usepackage{times}, and with '%G'      good 
   AK> without \usepackage{times}, and with 'G'    good 
   AK> without \usepackage{times}, and with '%G'   good

Yes, I get the same results.

But these results suggest to me that the ``G'' option in
config.pdf is *unnecessary*.  Without the ``G'', config.pdf works
with documents using either Computer Modern or other Type 1 fonts;
with the ``G'', documents using non-CM Type 1 fonts have problems.


That said, you were right to point out that

   AK> There might be possibility that "without
   AK> \usepackage{times}, and with '%G'" causes trouble but I
   AK> have no concrete examples.

After talking about the situation with my partner, I think I
understand what was happening and why the G option was added to
dvips and config.pdf.  I even have a possible example of the
problem, although I'm not sure it really counts a problem these
days.  Anyway, what happened is the following:

Computer Modern Roman includes Greek glyphs at the start of the
font (low character positions) including 0 (zero).

Adobe's Acrobat Reader application was written in C.  C uses
character 0 to indicate the end of a string.  As a result, files
that use character 0 caused problems for Acrobat Reader.  The G
option to dvips shifts the low character value glyphs to higher
characters to work around that problem.

I created PDF files using PostScript files generated with and
without the G option from the following file:

   \documentclass{article}
   %\usepackage{times}

   \begin{document}
   Diffusionskoeffizient (diffusion coefficient)

   \char0\char1\char2

   ffl fl ff fi ffi
   \end{document}

I then viewed the files with Acrobat Reader 4.0 for Intel Linux,
gv 3.5.8, xpdf 0.90, Acrobat Exchange 3.01 for Macintosh, and
Acrobat Reader 3.0 for Macintosh.  The only file and viewer
combination that showed a problem was the no-G file viewed in
Acrobat Reader 3.0 for Macintosh, where the fl ligature was
missing.  All the rest were fine.  And I'm not at all sure that
the missing fl ligature in Reader 3.0 wasn't just an example of
*another* bug Reader 3.0 for Mac has.

That strongly suggests to me that the G option may no longer be
necessary.  (For safety's sake, it might be useful to check with
Tim Van Zandt (tvz@econ.insead.fr), who wrote config.pdf, to see
if he knows of any continuing problems.)


   AK> And as Connelly suggested, the command option '-G0'
   AK> suppress the effects of 'G' in config.pdf.  But it seems
   AK> there is no explanation in info of dvips concerning '-G'
   AK> command-line option nor configuration file commands.

No, there isn't, and that sounds like another bug.  If you do
``dvips --help'', however, you will find

   G*  Shift low chars to higher pos.  

in the list of options.  (The * indicates that you can use a ``0''
to turn the option off.)


   Me> It's hard to say whether or not the default config.pdf file
   Me> should include the G flag without knowing which group is
   Me> larger: those using the Type 1 Computer Modern fonts or
   Me> those using other Type 1 fonts.  No matter what you do, one
   Me> of those groups will be unhappy.

   AK> I agreed the above comments.  The solution seems to explain
   AK> this situation in some document (README.Debian?).

I was too wishy-washy in my first message.  Now that I understand
the reason for adding the G option, I think it's no longer
necessary and should be removed from config.pdf unless someone can
come up with some really convincing reasons not to do so.  It's an
indiscriminate hack to work around a bug in some broken PDF
viewers.  If it only tinkered with Computer Modern fonts, that
would be one thing, but it affects all Type 1 fonts.  Finally,
even with this fix, there are several other subtle ways that dvips
can output PostScript that, when converted to PDF, tickles bugs in
early versions of Acrobat Reader (e.g., reencoding fonts).

   CMC

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 Behind the counter a boy with a shaven head stared vacantly into space, 
 a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   C.M. Connelly               c@eskimo.com                   SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+