- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-896 ] including an image (pdf or png) with transparency messes up other colours on that page
by noreply＠sarovar.org 29 Dec '07

29 Dec '07

Bugs item #896, was opened at 2007-12-29 16:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106 Category: PDF inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jim Diamond (zsd) Assigned to: Martin Schröder (oneiros) Summary: including an image (pdf or png) with transparency messes up other colours on that page Initial Comment: Download http://www.libpng.org/pub/png/img_png/stefan_255_rgba.png (which has a transparent background) and run it through png2pdf as follows: png2pdf -i stefan_255_rgba.png stefan_255_rgba-i.pdf png2pdf -a stefan_255_rgba.png stefan_255_rgba-a.pdf png2pdf stefan_255_rgba.png stefan_255_rgba-neither.pdf Then run the following through pdflatex (pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)) \documentclass{beamer} \mode<presentation> { \usetheme{Madrid} \setbeamercovered{transparent} } \usepackage{ifpdf} \usepackage{graphicx} \usepackage{color} \ifpdf \hypersetup{% pdfpagemode=FullScreen, pdfpagetransition={Wipe /Di 0 /D 0.5} } \fi \title[Beamer and png2pdf]{Using png2pdf with the beamer class} \author[Krause]{D.~Krause} \subject{png2pdf} \begin{document} \beamertemplateshadingbackground{yellow!50}{magenta!50} \begin{frame} \frametitle{NO Image over background} This is some text \end{frame} \begin{frame} \frametitle{Original stefan... png image over background} \includegraphics{stefan_255_rgba.png}% \end{frame} \begin{frame} \frametitle{png2pdf -a stefan... image over background} \includegraphics{stefan_255_rgba-a.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf -i stefan... image over background} \includegraphics{stefan_255_rgba-i.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf stefan... over background} \includegraphics{stefan_255_rgba-neither.pdf}% \end{frame} \end{document} Now look at the resulting PDF (attached) with Acroread 7.0.9 or 8.1.1 on Linux. On the page which includes the PNG and also on the page which includes the png2pdf -a version, the other colours on the page are messed up somewhat. This also happens on Acroread 8.? running on Windoze xp under vmware, although it seems a bit less noticeable. There is no apparent problem when looking at the file with xpdf or kpdf (Slackware 12.0 Linux). It's not clear to me whether this is an acroread bug or a pdftex bug, but Martin Schröder suggested I open a bug here. Cheers. Jim ---------------------------------------------------------------------- >Comment By: Jim Diamond (zsd) Date: 2007-12-29 17:03 Message: Logged In: YES user_id=4814 I just d/l'ed and compiled pdftex Version 3.141592-1.40.5 (Web2C 7.5.6) The pdf files (1.40.3 and 1.40.5 versions) are slightly different (when compared as text) but when viewed with acroread 7.0.9 they look identical (as far as my eyes can tell). ---------------------------------------------------------------------- Comment By: Jim Diamond (zsd) Date: 2007-12-29 16:15 Message: Logged In: YES user_id=4814 Done ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-29 16:08 Message: Logged In: YES user_id=421 Please attach the pdfs from png2pdf. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106

1 0

[ pdftex-Bugs-896 ] including an image (pdf or png) with transparency messes up other colours on that page
by noreply＠sarovar.org 29 Dec '07

29 Dec '07

Bugs item #896, was opened at 2007-12-29 16:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106 Category: PDF inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jim Diamond (zsd) Assigned to: Martin Schröder (oneiros) Summary: including an image (pdf or png) with transparency messes up other colours on that page Initial Comment: Download http://www.libpng.org/pub/png/img_png/stefan_255_rgba.png (which has a transparent background) and run it through png2pdf as follows: png2pdf -i stefan_255_rgba.png stefan_255_rgba-i.pdf png2pdf -a stefan_255_rgba.png stefan_255_rgba-a.pdf png2pdf stefan_255_rgba.png stefan_255_rgba-neither.pdf Then run the following through pdflatex (pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)) \documentclass{beamer} \mode<presentation> { \usetheme{Madrid} \setbeamercovered{transparent} } \usepackage{ifpdf} \usepackage{graphicx} \usepackage{color} \ifpdf \hypersetup{% pdfpagemode=FullScreen, pdfpagetransition={Wipe /Di 0 /D 0.5} } \fi \title[Beamer and png2pdf]{Using png2pdf with the beamer class} \author[Krause]{D.~Krause} \subject{png2pdf} \begin{document} \beamertemplateshadingbackground{yellow!50}{magenta!50} \begin{frame} \frametitle{NO Image over background} This is some text \end{frame} \begin{frame} \frametitle{Original stefan... png image over background} \includegraphics{stefan_255_rgba.png}% \end{frame} \begin{frame} \frametitle{png2pdf -a stefan... image over background} \includegraphics{stefan_255_rgba-a.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf -i stefan... image over background} \includegraphics{stefan_255_rgba-i.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf stefan... over background} \includegraphics{stefan_255_rgba-neither.pdf}% \end{frame} \end{document} Now look at the resulting PDF (attached) with Acroread 7.0.9 or 8.1.1 on Linux. On the page which includes the PNG and also on the page which includes the png2pdf -a version, the other colours on the page are messed up somewhat. This also happens on Acroread 8.? running on Windoze xp under vmware, although it seems a bit less noticeable. There is no apparent problem when looking at the file with xpdf or kpdf (Slackware 12.0 Linux). It's not clear to me whether this is an acroread bug or a pdftex bug, but Martin Schröder suggested I open a bug here. Cheers. Jim ---------------------------------------------------------------------- >Comment By: Jim Diamond (zsd) Date: 2007-12-29 16:15 Message: Logged In: YES user_id=4814 Done ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-29 16:08 Message: Logged In: YES user_id=421 Please attach the pdfs from png2pdf. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106

1 0

[ pdftex-Bugs-896 ] including an image (pdf or png) with transparency messes up other colours on that page
by noreply＠sarovar.org 29 Dec '07

29 Dec '07

Bugs item #896, was opened at 2007-12-29 21:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106 >Category: PDF inclusion >Group: v1.40.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jim Diamond (zsd) >Assigned to: Martin Schröder (oneiros) Summary: including an image (pdf or png) with transparency messes up other colours on that page Initial Comment: Download http://www.libpng.org/pub/png/img_png/stefan_255_rgba.png (which has a transparent background) and run it through png2pdf as follows: png2pdf -i stefan_255_rgba.png stefan_255_rgba-i.pdf png2pdf -a stefan_255_rgba.png stefan_255_rgba-a.pdf png2pdf stefan_255_rgba.png stefan_255_rgba-neither.pdf Then run the following through pdflatex (pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)) \documentclass{beamer} \mode<presentation> { \usetheme{Madrid} \setbeamercovered{transparent} } \usepackage{ifpdf} \usepackage{graphicx} \usepackage{color} \ifpdf \hypersetup{% pdfpagemode=FullScreen, pdfpagetransition={Wipe /Di 0 /D 0.5} } \fi \title[Beamer and png2pdf]{Using png2pdf with the beamer class} \author[Krause]{D.~Krause} \subject{png2pdf} \begin{document} \beamertemplateshadingbackground{yellow!50}{magenta!50} \begin{frame} \frametitle{NO Image over background} This is some text \end{frame} \begin{frame} \frametitle{Original stefan... png image over background} \includegraphics{stefan_255_rgba.png}% \end{frame} \begin{frame} \frametitle{png2pdf -a stefan... image over background} \includegraphics{stefan_255_rgba-a.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf -i stefan... image over background} \includegraphics{stefan_255_rgba-i.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf stefan... over background} \includegraphics{stefan_255_rgba-neither.pdf}% \end{frame} \end{document} Now look at the resulting PDF (attached) with Acroread 7.0.9 or 8.1.1 on Linux. On the page which includes the PNG and also on the page which includes the png2pdf -a version, the other colours on the page are messed up somewhat. This also happens on Acroread 8.? running on Windoze xp under vmware, although it seems a bit less noticeable. There is no apparent problem when looking at the file with xpdf or kpdf (Slackware 12.0 Linux). It's not clear to me whether this is an acroread bug or a pdftex bug, but Martin Schröder suggested I open a bug here. Cheers. Jim ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-12-29 21:08 Message: Logged In: YES user_id=421 Please attach the pdfs from png2pdf. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106

1 0

[ pdftex-Bugs-896 ] including an image (pdf or png) with transparency messes up other colours on that page
by noreply＠sarovar.org 29 Dec '07

29 Dec '07

Bugs item #896, was opened at 2007-12-29 16:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Diamond (zsd) Assigned to: Nobody (None) Summary: including an image (pdf or png) with transparency messes up other colours on that page Initial Comment: Download http://www.libpng.org/pub/png/img_png/stefan_255_rgba.png (which has a transparent background) and run it through png2pdf as follows: png2pdf -i stefan_255_rgba.png stefan_255_rgba-i.pdf png2pdf -a stefan_255_rgba.png stefan_255_rgba-a.pdf png2pdf stefan_255_rgba.png stefan_255_rgba-neither.pdf Then run the following through pdflatex (pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)) \documentclass{beamer} \mode<presentation> { \usetheme{Madrid} \setbeamercovered{transparent} } \usepackage{ifpdf} \usepackage{graphicx} \usepackage{color} \ifpdf \hypersetup{% pdfpagemode=FullScreen, pdfpagetransition={Wipe /Di 0 /D 0.5} } \fi \title[Beamer and png2pdf]{Using png2pdf with the beamer class} \author[Krause]{D.~Krause} \subject{png2pdf} \begin{document} \beamertemplateshadingbackground{yellow!50}{magenta!50} \begin{frame} \frametitle{NO Image over background} This is some text \end{frame} \begin{frame} \frametitle{Original stefan... png image over background} \includegraphics{stefan_255_rgba.png}% \end{frame} \begin{frame} \frametitle{png2pdf -a stefan... image over background} \includegraphics{stefan_255_rgba-a.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf -i stefan... image over background} \includegraphics{stefan_255_rgba-i.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf stefan... over background} \includegraphics{stefan_255_rgba-neither.pdf}% \end{frame} \end{document} Now look at the resulting PDF (attached) with Acroread 7.0.9 or 8.1.1 on Linux. On the page which includes the PNG and also on the page which includes the png2pdf -a version, the other colours on the page are messed up somewhat. This also happens on Acroread 8.? running on Windoze xp under vmware, although it seems a bit less noticeable. There is no apparent problem when looking at the file with xpdf or kpdf (Slackware 12.0 Linux). It's not clear to me whether this is an acroread bug or a pdftex bug, but Martin Schröder suggested I open a bug here. Cheers. Jim ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106

1 0

[ pdftex-Bugs-887 ] trunk doesn't compile
by noreply＠sarovar.org 20 Dec '07

20 Dec '07

Bugs item #887, was opened at 2007-12-19 17:19 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106 Category: Build process Group: v1.50.0-alpha >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: trunk doesn't compile Initial Comment: Since r314, I cannot compile trunk/ anymore. The last lines from build.sh are: c++ -g -O2 -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/pdftexdir -I../.. -I../../../../src/texk/web2c/pdftexdir/.. /.. -I../../../libs/xpdf -I../../../libs/xpdf/xpdf -I../../../libs/xpdf/goo -I../../../libs/xpdf/fofi -I../../../../src/ texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/xpdf -I../../../../src /texk/web2c/pdftexdir/../../../libs/xpdf/goo -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/fofi -I../../../l ibs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../src/texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../ ../src/texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DPDF_PARSER_ONLY -DDISABLE_OUTLINE -c ../../../../src/texk/web2 c/pdftexdir/pdftoepdf.cc In file included from ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:30: ../../../../src/texk/web2c/pdftexdir/pdflib.h:264: error: base `XRef' with only non-default constructor in class without a constructor make[2]: *** [pdftoepdf.o] Error 1 make[2]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c' make: *** [pdftexbin] Error 2 with: $ c++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr -- sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --w ithout-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-20 00:07 Message: Logged In: YES user_id=2217 it is, thanks. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 21:44 Message: Logged In: YES user_id=421 This should be fixed in r325. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 20:56 Message: Logged In: YES user_id=421 I can reproduce this with gcc (GCC) 3.3.5 (propolice) on OpenBSD 4.1 So it's not cygwin, but g++ 3. I'll fix this tomorrow. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 17:51 Message: Logged In: YES user_id=2217 If the one in trunk/source/src/libs/xpdf is a standard xpdf, then yes, it compiles. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 17:31 Message: Logged In: YES user_id=421 Cygwin :-( It works with cc (GCC) 4.2.1 (SUSE Linux), but I'll test on OpenBSD. Can you compile a standard xpdf 3.02? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106

1 0

[ pdftex-Bugs-887 ] trunk doesn't compile
by noreply＠sarovar.org 20 Dec '07

20 Dec '07

Bugs item #887, was opened at 2007-12-19 16:19 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106 Category: Build process Group: v1.50.0-alpha Status: Open Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: trunk doesn't compile Initial Comment: Since r314, I cannot compile trunk/ anymore. The last lines from build.sh are: c++ -g -O2 -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/pdftexdir -I../.. -I../../../../src/texk/web2c/pdftexdir/.. /.. -I../../../libs/xpdf -I../../../libs/xpdf/xpdf -I../../../libs/xpdf/goo -I../../../libs/xpdf/fofi -I../../../../src/ texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/xpdf -I../../../../src /texk/web2c/pdftexdir/../../../libs/xpdf/goo -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/fofi -I../../../l ibs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../src/texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../ ../src/texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DPDF_PARSER_ONLY -DDISABLE_OUTLINE -c ../../../../src/texk/web2 c/pdftexdir/pdftoepdf.cc In file included from ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:30: ../../../../src/texk/web2c/pdftexdir/pdflib.h:264: error: base `XRef' with only non-default constructor in class without a constructor make[2]: *** [pdftoepdf.o] Error 1 make[2]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c' make: *** [pdftexbin] Error 2 with: $ c++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr -- sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --w ithout-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2007-12-19 23:07 Message: Logged In: YES user_id=2217 it is, thanks. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 20:44 Message: Logged In: YES user_id=421 This should be fixed in r325. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 19:56 Message: Logged In: YES user_id=421 I can reproduce this with gcc (GCC) 3.3.5 (propolice) on OpenBSD 4.1 So it's not cygwin, but g++ 3. I'll fix this tomorrow. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 16:51 Message: Logged In: YES user_id=2217 If the one in trunk/source/src/libs/xpdf is a standard xpdf, then yes, it compiles. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 16:31 Message: Logged In: YES user_id=421 Cygwin :-( It works with cc (GCC) 4.2.1 (SUSE Linux), but I'll test on OpenBSD. Can you compile a standard xpdf 3.02? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106

1 0

[ pdftex-Bugs-887 ] trunk doesn't compile
by noreply＠sarovar.org 19 Dec '07

19 Dec '07

Bugs item #887, was opened at 2007-12-19 17:19 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106 Category: Build process Group: v1.50.0-alpha Status: Open >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: trunk doesn't compile Initial Comment: Since r314, I cannot compile trunk/ anymore. The last lines from build.sh are: c++ -g -O2 -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/pdftexdir -I../.. -I../../../../src/texk/web2c/pdftexdir/.. /.. -I../../../libs/xpdf -I../../../libs/xpdf/xpdf -I../../../libs/xpdf/goo -I../../../libs/xpdf/fofi -I../../../../src/ texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/xpdf -I../../../../src /texk/web2c/pdftexdir/../../../libs/xpdf/goo -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/fofi -I../../../l ibs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../src/texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../ ../src/texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DPDF_PARSER_ONLY -DDISABLE_OUTLINE -c ../../../../src/texk/web2 c/pdftexdir/pdftoepdf.cc In file included from ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:30: ../../../../src/texk/web2c/pdftexdir/pdflib.h:264: error: base `XRef' with only non-default constructor in class without a constructor make[2]: *** [pdftoepdf.o] Error 1 make[2]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c' make: *** [pdftexbin] Error 2 with: $ c++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr -- sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --w ithout-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-12-19 21:44 Message: Logged In: YES user_id=421 This should be fixed in r325. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 20:56 Message: Logged In: YES user_id=421 I can reproduce this with gcc (GCC) 3.3.5 (propolice) on OpenBSD 4.1 So it's not cygwin, but g++ 3. I'll fix this tomorrow. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 17:51 Message: Logged In: YES user_id=2217 If the one in trunk/source/src/libs/xpdf is a standard xpdf, then yes, it compiles. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 17:31 Message: Logged In: YES user_id=421 Cygwin :-( It works with cc (GCC) 4.2.1 (SUSE Linux), but I'll test on OpenBSD. Can you compile a standard xpdf 3.02? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106

1 0

[ pdftex-Bugs-887 ] trunk doesn't compile
by noreply＠sarovar.org 19 Dec '07

19 Dec '07

Bugs item #887, was opened at 2007-12-19 17:19 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106 Category: Build process >Group: v1.50.0-alpha Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: trunk doesn't compile Initial Comment: Since r314, I cannot compile trunk/ anymore. The last lines from build.sh are: c++ -g -O2 -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/pdftexdir -I../.. -I../../../../src/texk/web2c/pdftexdir/.. /.. -I../../../libs/xpdf -I../../../libs/xpdf/xpdf -I../../../libs/xpdf/goo -I../../../libs/xpdf/fofi -I../../../../src/ texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/xpdf -I../../../../src /texk/web2c/pdftexdir/../../../libs/xpdf/goo -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/fofi -I../../../l ibs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../src/texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../ ../src/texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DPDF_PARSER_ONLY -DDISABLE_OUTLINE -c ../../../../src/texk/web2 c/pdftexdir/pdftoepdf.cc In file included from ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:30: ../../../../src/texk/web2c/pdftexdir/pdflib.h:264: error: base `XRef' with only non-default constructor in class without a constructor make[2]: *** [pdftoepdf.o] Error 1 make[2]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c' make: *** [pdftexbin] Error 2 with: $ c++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr -- sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --w ithout-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 20:56 Message: Logged In: YES user_id=421 I can reproduce this with gcc (GCC) 3.3.5 (propolice) on OpenBSD 4.1 So it's not cygwin, but g++ 3. I'll fix this tomorrow. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 17:51 Message: Logged In: YES user_id=2217 If the one in trunk/source/src/libs/xpdf is a standard xpdf, then yes, it compiles. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 17:31 Message: Logged In: YES user_id=421 Cygwin :-( It works with cc (GCC) 4.2.1 (SUSE Linux), but I'll test on OpenBSD. Can you compile a standard xpdf 3.02? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106

1 0

[ pdftex-Bugs-887 ] trunk doesn't compile
by noreply＠sarovar.org 19 Dec '07

19 Dec '07

Bugs item #887, was opened at 2007-12-19 17:19 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106 Category: Build process Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: trunk doesn't compile Initial Comment: Since r314, I cannot compile trunk/ anymore. The last lines from build.sh are: c++ -g -O2 -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/pdftexdir -I../.. -I../../../../src/texk/web2c/pdftexdir/.. /.. -I../../../libs/xpdf -I../../../libs/xpdf/xpdf -I../../../libs/xpdf/goo -I../../../libs/xpdf/fofi -I../../../../src/ texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/xpdf -I../../../../src /texk/web2c/pdftexdir/../../../libs/xpdf/goo -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/fofi -I../../../l ibs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../src/texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../ ../src/texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DPDF_PARSER_ONLY -DDISABLE_OUTLINE -c ../../../../src/texk/web2 c/pdftexdir/pdftoepdf.cc In file included from ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:30: ../../../../src/texk/web2c/pdftexdir/pdflib.h:264: error: base `XRef' with only non-default constructor in class without a constructor make[2]: *** [pdftoepdf.o] Error 1 make[2]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c' make: *** [pdftexbin] Error 2 with: $ c++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr -- sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --w ithout-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-12-19 20:56 Message: Logged In: YES user_id=421 I can reproduce this with gcc (GCC) 3.3.5 (propolice) on OpenBSD 4.1 So it's not cygwin, but g++ 3. I'll fix this tomorrow. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 17:51 Message: Logged In: YES user_id=2217 If the one in trunk/source/src/libs/xpdf is a standard xpdf, then yes, it compiles. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 17:31 Message: Logged In: YES user_id=421 Cygwin :-( It works with cc (GCC) 4.2.1 (SUSE Linux), but I'll test on OpenBSD. Can you compile a standard xpdf 3.02? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106

1 0

[ pdftex-Bugs-887 ] trunk doesn't compile
by noreply＠sarovar.org 19 Dec '07

19 Dec '07

Bugs item #887, was opened at 2007-12-19 16:19 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106 Category: Build process Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: trunk doesn't compile Initial Comment: Since r314, I cannot compile trunk/ anymore. The last lines from build.sh are: c++ -g -O2 -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/pdftexdir -I../.. -I../../../../src/texk/web2c/pdftexdir/.. /.. -I../../../libs/xpdf -I../../../libs/xpdf/xpdf -I../../../libs/xpdf/goo -I../../../libs/xpdf/fofi -I../../../../src/ texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/xpdf -I../../../../src /texk/web2c/pdftexdir/../../../libs/xpdf/goo -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/fofi -I../../../l ibs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../src/texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../ ../src/texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DPDF_PARSER_ONLY -DDISABLE_OUTLINE -c ../../../../src/texk/web2 c/pdftexdir/pdftoepdf.cc In file included from ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:30: ../../../../src/texk/web2c/pdftexdir/pdflib.h:264: error: base `XRef' with only non-default constructor in class without a constructor make[2]: *** [pdftoepdf.o] Error 1 make[2]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c' make: *** [pdftexbin] Error 2 with: $ c++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr -- sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --w ithout-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2007-12-19 16:51 Message: Logged In: YES user_id=2217 If the one in trunk/source/src/libs/xpdf is a standard xpdf, then yes, it compiles. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-19 16:31 Message: Logged In: YES user_id=421 Cygwin :-( It works with cc (GCC) 4.2.1 (SUSE Linux), but I'll test on OpenBSD. Can you compile a standard xpdf 3.02? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106

1 0

[ pdftex-Bugs-884 ] Letterspacing and non-autoexpanded fonts
by noreply＠sarovar.org 19 Dec '07

19 Dec '07

Bugs item #884, was opened at 2007-11-27 09:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=884&group_id=106 Category: hz Group: v1.40.5 Status: Open Resolution: Accepted Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Letterspacing and non-autoexpanded fonts Initial Comment: While auto-expanding letterspaced fonts works fine now, there still is a problem with non-automatic expansion. The following will complain about a missing tfm file. It doesn't make a difference whether the expanded font instance is created from an mf file (like below), via `ExtendFont' in the map file, or even whether it was created from a MM font (ie., the expanded instance actually exists as a pfb file). The latter case is what bothers me the most. \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr=cmr10 \cmr \letterspacefont\cmrls=\cmr 100 \pdffontexpand\cmrls 100 0 100 %autoexpand \cmrls Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye PS: what about the `invalid entry' complaint for the map lines? Are they not legal? ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2007-12-19 16:42 Message: Logged In: YES user_id=2217 > A map line needs either a psname (for not-embedded fonts) > or the file name (for embedded fonts) The manual seems to suggest otherwise (re scalable Type 3 fonts). Also, older pdftex versions wouldn't throw a warning, but use the Type 3 font instead. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-11-27 10:05 Message: Logged In: YES user_id=421 A map line needs either a psname (for not-embedded fonts) or the file name (for embedded fonts) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=884&group_id=106

1 0

[ pdftex-Bugs-887 ] trunk doesn't compile
by noreply＠sarovar.org 19 Dec '07

19 Dec '07

Bugs item #887, was opened at 2007-12-19 17:19 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106 >Category: Build process Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) >Assigned to: Martin Schröder (oneiros) Summary: trunk doesn't compile Initial Comment: Since r314, I cannot compile trunk/ anymore. The last lines from build.sh are: c++ -g -O2 -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/pdftexdir -I../.. -I../../../../src/texk/web2c/pdftexdir/.. /.. -I../../../libs/xpdf -I../../../libs/xpdf/xpdf -I../../../libs/xpdf/goo -I../../../libs/xpdf/fofi -I../../../../src/ texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/xpdf -I../../../../src /texk/web2c/pdftexdir/../../../libs/xpdf/goo -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/fofi -I../../../l ibs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../src/texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../ ../src/texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DPDF_PARSER_ONLY -DDISABLE_OUTLINE -c ../../../../src/texk/web2 c/pdftexdir/pdftoepdf.cc In file included from ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:30: ../../../../src/texk/web2c/pdftexdir/pdflib.h:264: error: base `XRef' with only non-default constructor in class without a constructor make[2]: *** [pdftoepdf.o] Error 1 make[2]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c' make: *** [pdftexbin] Error 2 with: $ c++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr -- sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --w ithout-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-12-19 17:31 Message: Logged In: YES user_id=421 Cygwin :-( It works with cc (GCC) 4.2.1 (SUSE Linux), but I'll test on OpenBSD. Can you compile a standard xpdf 3.02? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106

1 0

[ pdftex-Patches-871 ] Synchronization: pdfsync.sty embedded (1)
by noreply＠sarovar.org 19 Dec '07

19 Dec '07

Patches item #871, was opened at 2007-09-30 08:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106 Category: User interaction Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Martin Schröder (oneiros) Summary: Synchronization: pdfsync.sty embedded (1) Initial Comment: To the administrator, please remove the preceding patch submission The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf PS: I have problems with my connection ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 16:21 Message: Logged In: YES user_id=2217 Also, the command line switch seems to be broken. It only works with \synchronize=1 in the source here. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-18 14:50 Message: Logged In: YES user_id=421 Please update the patch against trunk and please use svn diff. I refuse to look at this patch more closely since the diff includes all the .svn files. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-10-15 07:21 Message: Logged In: YES user_id=4698 Synchronize3.zip is available. It just adds a flag in the .sync file to indicate whether dvi or pdf mode was used. So far I have found only one problem, using dvips or dvipdf with a concrete offset (-x and -y options) will break the synchronization. If such a filter is gentle enough to indicate that it used a custom offset, then viewers can take this into account and the synchronization is not broken. Viewers will check the above mentionned flag to look for customized offset. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-30 22:00 Message: Logged In: YES user_id=421 You didn't attach Synchronize 2.zip yet... ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 21:10 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 21:09 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106

1 0

[ pdftex-Bugs-887 ] trunk doesn't compile
by noreply＠sarovar.org 19 Dec '07

19 Dec '07

Bugs item #887, was opened at 2007-12-19 16:19 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: trunk doesn't compile Initial Comment: Since r314, I cannot compile trunk/ anymore. The last lines from build.sh are: c++ -g -O2 -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/pdftexdir -I../.. -I../../../../src/texk/web2c/pdftexdir/.. /.. -I../../../libs/xpdf -I../../../libs/xpdf/xpdf -I../../../libs/xpdf/goo -I../../../libs/xpdf/fofi -I../../../../src/ texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/xpdf -I../../../../src /texk/web2c/pdftexdir/../../../libs/xpdf/goo -I../../../../src/texk/web2c/pdftexdir/../../../libs/xpdf/fofi -I../../../l ibs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../src/texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../ ../src/texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DPDF_PARSER_ONLY -DDISABLE_OUTLINE -c ../../../../src/texk/web2 c/pdftexdir/pdftoepdf.cc In file included from ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:30: ../../../../src/texk/web2c/pdftexdir/pdflib.h:264: error: base `XRef' with only non-default constructor in class without a constructor make[2]: *** [pdftoepdf.o] Error 1 make[2]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/cygdrive/c/Programme/TeXLive-test/trunk/source/build/texk/web2c' make: *** [pdftexbin] Error 2 with: $ c++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr -- sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --w ithout-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=887&group_id=106

1 0

[ pdftex-Patches-735 ] patch for simplified horizontal positional tracking
by noreply＠sarovar.org 18 Dec '07

18 Dec '07

Patches item #735, was opened at 2007-02-19 22:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=735&group_id=106 Category: Positioning Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: Taco Hoekwater (taco) Summary: patch for simplified horizontal positional tracking Initial Comment: 1. simpler calculations for horizontal position update when inside []TJ arrays, now by pure additions within a fontsize/10000 raster; no rounding errors can accumulate. Gives about 7 % pdftex speed gain when typesetting fiction-type stuff. 2. writet3.c now also with standard /FontMatrix [0.001 0 0 0.001 0 0], tidied up a little (.pgc part untested). No need anymore (hope it's right) to handle PK fonts specially by adv_char_width() in pdftex.web. 3. wrong use of printf() at a few places corrected by Martin. Work in progess, not safe for production. Needs more testing, particularly with PK fonts. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-12-18 15:57 Message: Logged In: YES user_id=421 Hartmut, what's the state of this? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-03-04 11:27 Message: Logged In: YES user_id=929 the extended patch 70226a needs more work; removed the patch file. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-02-25 23:51 Message: Logged In: YES user_id=929 The previous patch 735 is now extended to general text and graphics positioning on the PDF page. pdf_set_origin() (now pdf_move_to()), pdf_set_textmatrix(), and pdf_begin_string() are rewritten. In low placement resolution (e. g. \pdfdecimaldigits=0) now the glyph placement is corrected within the []TJ array by a leading number, like [7(a)...]TJ, if required, so that always full TeX precision is kept (very early pdftex versions might have used this also). Any accumulation of rounding errors should be avoided now by the used calculation principle. Needs lots of testing. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=735&group_id=106

1 0

[ pdftex-Patches-871 ] Synchronization: pdfsync.sty embedded (1)
by noreply＠sarovar.org 18 Dec '07

18 Dec '07

Patches item #871, was opened at 2007-09-30 10:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106 Category: User interaction Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Martin Schröder (oneiros) Summary: Synchronization: pdfsync.sty embedded (1) Initial Comment: To the administrator, please remove the preceding patch submission The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf PS: I have problems with my connection ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-12-18 15:50 Message: Logged In: YES user_id=421 Please update the patch against trunk and please use svn diff. I refuse to look at this patch more closely since the diff includes all the .svn files. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-10-15 09:21 Message: Logged In: YES user_id=4698 Synchronize3.zip is available. It just adds a flag in the .sync file to indicate whether dvi or pdf mode was used. So far I have found only one problem, using dvips or dvipdf with a concrete offset (-x and -y options) will break the synchronization. If such a filter is gentle enough to indicate that it used a custom offset, then viewers can take this into account and the synchronization is not broken. Viewers will check the above mentionned flag to look for customized offset. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-01 00:00 Message: Logged In: YES user_id=421 You didn't attach Synchronize 2.zip yet... ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:10 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:09 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106

1 0

[ pdftex-Patches-828 ] Make /XObject /Form coordinates independent from PDF page dimensions
by noreply＠sarovar.org 18 Dec '07

18 Dec '07

Patches item #828, was opened at 2007-06-30 17:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=828&group_id=106 Category: Positioning Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: Taco Hoekwater (taco) Summary: Make /XObject /Form coordinates independent from PDF page dimensions Initial Comment: Experimental patch for pdftex-1.40.3/luatex In pdftex-1.30.4 \pdfpageheight spills over into coordinate transforms inside /XObject /Form objects. This isn't an error, but it complicates coordinate transforms. This tiny patch should tidy up the web source a little, making coordinate transforms inside /Form objects relative to their inner lower left position, independently from the PDF page dimensions. Testing welcome. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-12-18 15:44 Message: Logged In: YES user_id=421 I've updated the patch to apply cleanly against trunk. Taco, can you comment on this? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-07-01 02:14 Message: Logged In: YES user_id=929 more simplified, few variables removed. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-06-30 18:29 Message: Logged In: YES user_id=929 annotations were positioned wrongly. patch corrected. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-06-30 17:35 Message: Logged In: YES user_id=929 seems it can be further simplified, new patch. Testing welcome. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=828&group_id=106

1 0

[ pdftex-Patches-738 ] new primitive \pdfreplacefont
by noreply＠sarovar.org 18 Dec '07

18 Dec '07

Patches item #738, was opened at 2007-02-27 23:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=738&group_id=106 >Category: Fonts >Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive \pdfreplacefont Initial Comment: This primitive controls whether font replacement should be done when embedding pdf's. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-12-18 15:30 Message: Logged In: YES user_id=421 What's the status of this? The patch doesn't apply to trunk anymore... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=738&group_id=106

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 18 Dec '07

18 Dec '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 Category: Primitives Group: v1.50.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-18 15:25 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-09-18 08:10 Message: Logged In: YES user_id=1608 Well, at least it does not affect the tex user directly: there is a stream of garbage on the screen and that looks ugly, but there is no error interaction, and the system-level return value of pdftex is unaffected. I don't know if there is a clean way to control mktextfm cs, but if it can be done, that would be a nice addition to the web2c change file. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-17 21:53 Message: Logged In: YES user_id=421 IMHO it works only somuch, but that may be due to kpathsea: > pdftex test.tex This is pdfTeX, Version 3.141592-1.50.0-alpha-20070917 (Web2C 7.5.6) entering extended mode (./test.texkpathsea: Running mktextfm cmr-junk mktextfm: Running mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk This is METAFONT, Version 2.71828 (Web2C 7.5.4) kpathsea: Running mktexmf cmr-junk ! I can't find file `cmr-junk'. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Please type another input file name ! Emergency stop. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Transcript written on mfput.log. grep: cmr-junk.log: Datei oder Verzeichnis nicht gefunden mktextfm: `mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk' failed to make cmr-junk.tfm. kpathsea: Appending font creation commands to missfont.log. Font cmr-junk not found ) No pages of output. Transcript written on test.log. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0

[ pdftex-Bugs-861 ] including encrypted pdf
by noreply＠sarovar.org 14 Dec '07

14 Dec '07

Bugs item #861, was opened at 2007-09-07 10:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=861&group_id=106 Category: xpdf Group: v1.40.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Herbert Voss (voss) Assigned to: Martin Schröder (oneiros) Summary: including encrypted pdf Initial Comment: when i insert a page of the http://tug.org/texshowcase/en_gb_eclipse_114.pdf with \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics[page=1]{en_gb_eclipse_114} \end{document} I'll get an empty page with pdftex 1.40.5 With version 1.40.3 (xpdf 3.01) everything is fine. There is no difference in both logfiles. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-14 01:47 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.6/1.50.0). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-09 20:44 Message: Logged In: YES user_id=421 It also works with 1.40.5 and libs/xpdf from 1.40.3, so the problem is either in xpdf or in our binding. We have contacted Derek. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=861&group_id=106

1 0

\expanded (was: Misleading cs names?)
by Heiko Oberdiek 11 Dec '07

11 Dec '07

Hello, On Sun, Dec 09, 2007 at 08:14:31PM +0100, Morten Høgholm wrote: > Usually the x expansion meant "uses \edef" and so they were all > non-expandable. But now that we have pdfeTeX'ed the l3 kernel, we have > functions doing full expansion like \numexpr and friends and \pdfstrcmp > (does \edef on both arguments) used in \tlist_if_eq:xxTF. This reminds me: > the notes from the Oldenburg meeting mentions an \expanded primitive: > \expanded <general text> > Expandable command returning the full expansion > of the tokens in <general text>. > So since this pretty much exists inside \pdfstrcmp as it is now, it could > go into pdfTeX 1.50 and we would be free of these problems. Except of > course, \expanded is already used a lot in ConTeXt with different > semantics. > > Any opinions from the ConTeXt/pdfTeX people here? I miss "\expanded", too. A workaround for a \detokenize with expanded argument: \pdfunescapehex{\pdfunescapehex{...}} For LuaTeX \pdf(|un)escapehex are defined in package `pdftexcmds': \pdf@unescapehex and \pdf@escapehex, both are expandable. Disadvantages of the workaround: * slower * no <general text>, but macro argument * detokenization happens. But I assume, you want only expansion, not detokenization? (then the latter can be achieved by \detokenize\expandafter{\expanded{...}}) Biggest problem is probably a good name: a) \expanded would be a nice name, but it clashes with ConTeXt. I remember trouble with \unexpanded :-( b) It would belong to e-TeX, but there isn't a e-TeX prefix: \etexexpanded or \etexexpand c) pdfTeX's convention with prefix "\pdf" (see \pdfstrcmp, \pdfescape*): \pdfexpanded or \pdfexpand d) longer names My preference is c) to avoid trouble with macro name clashes. I can live with a), then my package etexcmds would get a new macro \etex@expanded. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: ntg-pdftex list added.

6 10

[ pdftex-Bugs-856 ] build.sh can't handle pathnames with spaces
by noreply＠sarovar.org 29 Nov '07

29 Nov '07

Bugs item #856, was opened at 2007-08-14 09:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=856&group_id=106 Category: Build process Group: v1.40.4 Status: Open Resolution: Postponed >Priority: 1 Submitted By: Francky Leyn (leyn) Assigned to: Martin Schröder (oneiros) Summary: build.sh can't handle pathnames with spaces Initial Comment: Dear, I want to compile pdftex for cygwin. I untarred the distribution in /cygdrive/c/Document and Settings/Francky Leyn/My Documents/LaTeX leyn@newyork ~/LaTeX/pdftex-1.40.5 $ ./build.sh ... build.sh stops with the following error: configure: error: can not run /cygdrive/c/Documents and Settings/Francky Leyn/My Documents/LaTeX/pdftex- 1.40.5/build/../src/config/config.sub The file exists and is executable: $ ls -lh "/cygdrive/c/Documents and Settings/Francky Leyn/My Documents/LaTeX/pdftex- 1.40.5/build/../src/config/config.sub" -rwx------+ 1 leyn None 32K Jul 31 19:00 /cygdrive/c/Documents and Settings/Francky Leyn/My Documents/LaTeX/pdftex- 1.40.5/build/../src/config/config.sub The file /cygdrive/c/Documents doesn't exist of course and that is why buid.sh stops its execution. Could the scripts be modified so that they can handle spaces? Best regards, Francky Leyn ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-08-15 01:52 Message: Logged In: YES user_id=421 I'm sorry, but fixing this needs a change in the whole autofoo system of TL, which is not likely to happen soon. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-08-14 10:50 Message: Logged In: YES user_id=421 This needs a new configure script; I've pushed this upstream (to TeXlive). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=856&group_id=106

1 0

[ pdftex-Bugs-884 ] Letterspacing and non-autoexpanded fonts
by noreply＠sarovar.org 29 Nov '07

29 Nov '07

Bugs item #884, was opened at 2007-11-27 10:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=884&group_id=106 Category: hz Group: v1.40.5 Status: Open Resolution: Accepted >Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Letterspacing and non-autoexpanded fonts Initial Comment: While auto-expanding letterspaced fonts works fine now, there still is a problem with non-automatic expansion. The following will complain about a missing tfm file. It doesn't make a difference whether the expanded font instance is created from an mf file (like below), via `ExtendFont' in the map file, or even whether it was created from a MM font (ie., the expanded instance actually exists as a pfb file). The latter case is what bothers me the most. \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr=cmr10 \cmr \letterspacefont\cmrls=\cmr 100 \pdffontexpand\cmrls 100 0 100 %autoexpand \cmrls Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye PS: what about the `invalid entry' complaint for the map lines? Are they not legal? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-11-27 11:05 Message: Logged In: YES user_id=421 A map line needs either a psname (for not-embedded fonts) or the file name (for embedded fonts) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=884&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 29 Nov '07

29 Nov '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-11-29 15:49 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.6/1.50.0). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-03 20:51 Message: Logged In: YES user_id=421 Fix is in the works. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-01 07:08 Message: Logged In: YES user_id=421 Adding /Group to the /Page is not an option for us (and probably wrong): What should we do when we have more than one included pdf on a page and they have different /CS entries? And why does transparency in an /XObject need an entry in the /Page? The entry in the /XObject should suffice. I wouldn't be surprised if AR is faulty here. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-10-01 02:04 Message: Logged In: YES user_id=4699 After adding /Group << /CS /DeviceRGB /Type /Group /S /Transparency >> to the /Page object in newfile2-1.pdf it displays correctly in Acrobat. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-01 01:04 Message: Logged In: YES user_id=421 The attached file newfile2-1.pdf has a copied page group, which as I now know, should be correct. Still, AR8@Linux shows different colours for it and TestSkizze.pdf . ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:51 Message: Logged In: YES user_id=3168 > Why is this WONTFIX? Sorry, this bug was once closed when this additional info was not available. -> I reopened this bug. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:46 Message: Logged In: YES user_id=3168 Why is this WONTFIX? I mean: > The file TestSkizze.pdf specifies the color blending space > with "/CS /DeviceRGB" in the transparency group. In > the PDF produced by pdftex this has been stripped out. So the bug is that pdftex strips out the color space. If you really think it's WONTFIX, then tell me what is the correct way of specifying the color space so that I can forward this to the Inkscape developers. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-09-30 15:34 Message: Logged In: YES user_id=4699 The file TestSkizze.pdf specifies the color blending space with "/CS /DeviceRGB" in the transparency group. In the PDF produced by pdftex this has been stripped out. When the color space is not specified Acrobat defaults to CMYK. This results in RGB colors being converted to CMYK, blended in CMYK color space, then converted back to RGB. This will produce different results compared to blending the colors in RGB space. This problem was also reported to the cairo list: http://lists.cairographics.org/archives/cairo/2007-September/011471.html ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-03 19:41 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-884 ] Letterspacing and non-autoexpanded fonts
by noreply＠sarovar.org 27 Nov '07

27 Nov '07

Bugs item #884, was opened at 2007-11-27 10:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=884&group_id=106 Category: hz Group: v1.40.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Letterspacing and non-autoexpanded fonts Initial Comment: While auto-expanding letterspaced fonts works fine now, there still is a problem with non-automatic expansion. The following will complain about a missing tfm file. It doesn't make a difference whether the expanded font instance is created from an mf file (like below), via `ExtendFont' in the map file, or even whether it was created from a MM font (ie., the expanded instance actually exists as a pfb file). The latter case is what bothers me the most. \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr=cmr10 \cmr \letterspacefont\cmrls=\cmr 100 \pdffontexpand\cmrls 100 0 100 %autoexpand \cmrls Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye PS: what about the `invalid entry' complaint for the map lines? Are they not legal? ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-11-27 11:05 Message: Logged In: YES user_id=421 A map line needs either a psname (for not-embedded fonts) or the file name (for embedded fonts) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=884&group_id=106

1 0