[NTG-pdftex] [ pdftex-Bugs-315 ] pdflatex on solaris font problems with acroread

noreply at sarovar.org noreply at sarovar.org
Thu Mar 24 16:01:16 CET 2005


Bugs item #315, was opened at 2005-03-21 10:53
You can respond by visiting: 
http://sarovar.org/tracker/?func=detail&atid=493&aid=315&group_id=106

Category: Fonts
Group: v1.21a
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Stan Swiercz (swiercz)
Assigned to: Thomas Esser (tetex)
Summary: pdflatex on solaris font problems with acroread

Initial Comment:
I have compiled pdflatex 1.2.1a that comes with teTeX 3.0
on both linux and solaris. The linux version works
properly but the solaris one does not.

The last font included in the pdf output produces the
error:

   Unable to extract the embedded font 'KTGBVU+CMR8'.
   Some characters may not display or print correctly.

when viewed with acroread (version 5 or 6, windows,
linux and solaris versions). Note that no error is seen
when viewed with ghostscript and xpdf. The above error
comes from the file:
------------------------
\documentclass{article} 
\newcommand{\ip}[2]{(#1, #2)}
\begin{document}  
This is an example input file.

Footnotes \footnote{This is an example of a footnote.}
pose no problem.

\LaTeX\ is good at typesetting mathematical formulas
like
       \( x-3y + z = 7 \)
or
       \( a_{1} > x^{2n} + y^{2n} > x' \)
or
       \( \ip{A}{B} = \sum_{i} a_{i} b_{i} \).
The spaces you type in a formula are
ignored.  Remember that a letter like
       $x$                   % $ ... $  and  \( ... \)
 are equivalent
is a formula when it denotes a mathematical
symbol, and it should be typed as one.

\end{document}
-----------------------

The sigma is produced correctly. If however I comment
out the footnote, the sigma in the summation is no
longer viewable and the error message is

   Unable to extract the embedded font 'ATSTIO+CMEX10'.
   Some characters may not display or print correctly.


I attach a pdf files produced on solaris.

Is this a know problem with a patch available?
If you need further information please
do not hesitate to contact me.

Stan



----------------------------------------------------------------------

>Comment By: Stan Swiercz (swiercz)
Date: 2005-03-24 10:01

Message:
Logged In: YES 
user_id=2345

It does appear that t1_offset_value is at fault.
I put in a pdftex_warn (something easy to add) in writet1.c
and the first time it outputs I see

Warning: pdflatex (file
/nfs/encs/ArchDep/sun4.solaris8/pkg/teTeX-3.0/root/texm
f/fonts/type1/bluesky/cm/cmr8.pfb): -268435455
t1_save_offset value

All the other times the "warning" is displayed it
returns 0.

Stan


----------------------------------------------------------------------

Comment By: Hartmut Henkel (hhenkel)
Date: 2005-03-24 09:52

Message:
Logged In: YES 
user_id=929

thanks a lot, it was as expected :-( but the error _is_
around there, it's uninitialized fb_ptr i guess, just
searching how to initialize it.

Regards, Hartmut

----------------------------------------------------------------------

Comment By: Stan Swiercz (swiercz)
Date: 2005-03-24 09:44

Message:
Logged In: YES 
user_id=2345

I have applied the patch and found no difference.


Stan

----------------------------------------------------------------------

Comment By: Hartmut Henkel (hhenkel)
Date: 2005-03-24 09:29

Message:
Logged In: YES 
user_id=929

maybe the infamous "Solaris compiler bug" is just an
uninitialized variable t1_save_offset? It's unclear, as it
seems that this could happen only if the font is not being
included. Anyway: Could some Solaris freak try out the
attached tiny patch to writet1.c?

Regards, Hartmut

----------------------------------------------------------------------

Comment By: Thomas Esser (tetex)
Date: 2005-03-23 19:35

Message:
Logged In: YES 
user_id=1230

We have seen this before. pdftex list, posting by Adrian
Lanz, Mon, 
09 Aug 2004.

There was no real outcome of that thread. Adrian wrote on 23
Sep 2004
to the texlive list:

    > On Tue, Sep 21, 2004 at 07:18:23PM -0500, Maksym
Polyakov wrote:
    >> apparently there was some overflow in /Length1 -- it
should be 810
    >
    > Ah, now it sounds familiar. Adrian Lanz has reported
the same to
    > pdftex at tug.org (09 Aug 2004, he uses SUN Solaris 9 /
gcc 3.3.2).
    >

    Yes, I had exactly the same problem recently installing
teTeX-beta
    2.96.7.20040721. In my case, the symptom was that
pdflatex run 
    without error, but a wrong /Length1 parameter was
inserted in the PDF
    output file, which evidently caused Acrobat Reader's
error message
    (no problem, however, with xpdf or with the "dvips
-Ppdf" routine).

    I think I solved the problem by changing the order and
rules how
    shared libraries are found and handled on my Sun Sparc
Solaris 2.9
    system, and/or I may have re-installed some programs and
libraries
    (ncurses, gettext, libiconv). I am sorry not being more
specific on

So, we have at least three people with this problem: Stan
Swiercz,
Maksym Polyakov, Adrian Lanz.

I think that this is some king of compiler bug or something
like that...

Thomas                                                     
                                                               

----------------------------------------------------------------------

Comment By: Martin Schröder (oneiros)
Date: 2005-03-23 09:42

Message:
Logged In: YES 
user_id=421

Yes, this is definitely a problem for some specific solaris
installations which I can't reproduce.

----------------------------------------------------------------------

Comment By: Stan Swiercz (swiercz)
Date: 2005-03-23 09:08

Message:
Logged In: YES 
user_id=2345

I have done more debugging and I find that with a newer
solaris 9 kernel the executable works fine. There is some
patch to the OS that fixes this. This is something static as
when I run this executable on a solaris machine running an
older solaris9 kernel or solaris8 it works properly.

Further digging I find that when I run the linker command 
on the older solaris 9 machine it produces a faulty
executable BUT if I run "g++ -v" to see what the real
linking command
is and cut and paste it so as to run it instead  the
executable produces a pdf viewable with acroread.

The basic g++ link command is

c++ -o pdfetex pdfetexini.o pdfetex0.o pdfetex1.o pdfetex2.o
pdfetex3.o pdfetexextra.o ../../libs/md5/md5.o 
pdftexdir/libpdf.a ../../libs/libpng/libpng.a
../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a
../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a
-lsocket lib/lib.a ../kpathsea/.libs/libkpathsea.a -lm

Instead of running this on older kernels I used

/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/collect2
-V -Y P,/usr/ccs/lib:/usr/lib -L /local/lib -L /encs/lib -Qy
-o pdfetex
/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crt1.o
/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crti.o
/usr/ccs/lib/values-Xa.o
/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtbegin.o
-L/encs/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.2
-L/encs/bin/../lib/gcc-lib
-L/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2
-L/usr/ccs/bin -L/usr/ccs/lib
-L/encs/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../..
-L/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../..
pdfetexini.o pdfetex0.o pdfetex1.o pdfetex2.o pdfetex3.o
pdfetexextra.o ../../libs/md5/md5.o pdftexdir/libpdf.a
../../libs/libpng/libpng.a ../../libs/zlib/libz.a
../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a
../../libs/xpdf/fofi/libfofi.a -lsocket lib/lib.a
../kpathsea/.libs/libkpathsea.a -lstdc++ -lm -lgcc_s -lgcc
-lc -lgcc_s -lgcc -lc
/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtend.o
/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtn.o

For the record /usr/ccs/lib/values-Xa.o is the same on both
systems. I don't understrand...


I also tracked down what the difference was between a pdf
file that displays and does not display.

The one that does display correctly has 

/Type /Page
/Contents 49 0 R
/Resources 47 0 R
/MediaBox [0 0 612 792]
/Parent 25 0 R
>> endobj
47 0 obj <<
/Font << /F8 12 0 R /F27 24 0 R /F11 31 0 R /F13 37 0 R /F7
18 0 R /F10 34 0 R >>
/ProcSet [ /PDF /Text ]
>> endobj
45 0 obj <<
/Length1 946
/Length2 3204
/Length3 532
/Length 3847      
/Filter /FlateDecode

while the one that does not has


/Type /Page
/Contents 49 0 R
/Resources 47 0 R
/MediaBox [0 0 612 792]
/Parent 25 0 R
>> endobj
47 0 obj <<
/Font << /F8 12 0 R /F27 24 0 R /F11 31 0 R /F13 37 0 R /F7
18 0 R /F10 34 0 R >>
/ProcSet [ /PDF /Text ]
>> endobj
45 0 obj <<
/Length1 268436401
/Length2 3204
/Length3 532
/Length 3848      
/Filter /FlateDecode


the 946 has turned into 268436401!

Hope this info helps.

Stan


----------------------------------------------------------------------

Comment By: Martin Schröder (oneiros)
Date: 2005-03-23 08:25

Message:
Logged In: YES 
user_id=421

This seems to be a build problem on Solaris. Compiling the
example on teTeX 3.0 on Linux produces a pdf that shows no
problems in AR.

A possible cause for the message by AR might be this extract
from pdf_test_solaris.pdf:
---------
29 0 obj <<
/Length1 268436401
/Length2 3204
---------
Length1 is definitely wrong.

----------------------------------------------------------------------

Comment By: Martin Schröder (oneiros)
Date: 2005-03-23 08:16

Message:
Logged In: YES 
user_id=421

I can reproduce the problem with AR5 and AR7(latest "beta")
on Linux. I can't reproduce it with gs 8.50 and Jaws.

I suspect that this is a bug in AR. :-(

----------------------------------------------------------------------

You can respond by visiting: 
http://sarovar.org/tracker/?func=detail&atid=493&aid=315&group_id=106


More information about the ntg-pdftex mailing list