- ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][4308] segfaut on pdf with Metadata in Page dict
by pdftex-bugs＠sarovar.org 15 Apr '10

15 Apr '10

Bugs item #4308, was opened at 2010-04-15 09:52 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: segfaut on pdf with Metadata in Page dict Category: PDF inclusion Group: None Resolution: None Initial Comment: pdftex segfaulted when including the attached pdf, which has Metadata stream per page (Hartmut reported the bug and fixed it for luatex). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4308&group_id=106

1 0

[pdftex-Bugs][4307] whitespace should be inserted when concatenating contents stream
by pdftex-bugs＠sarovar.org 11 Apr '10

11 Apr '10

Bugs item #4307, was opened at 2010-04-10 22:02 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: whitespace should be inserted when concatenating contents stream Category: PDF inclusion Group: None Resolution: Accepted Initial Comment: http://tug.org/pipermail/pdftex/2010-February/008330.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4307&group_id=106

1 0

[pdftex-Patches][4299] pdf font inclusion error (with partial patch)
by pdftex-patches＠sarovar.org 10 Apr '10

10 Apr '10

Patches item #4299, was opened at 2009-11-27 10:03 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: pdf font inclusion error (with partial patch) Category: PDF inclusion Group: None Resolution: Accepted Initial Comment: http://www.ntg.nl/pipermail/ntg-pdftex/2009-November/003859.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-04-10 21:23 Message: could you please attach such a pdf for testing? The latest version of easypdf (6.0) no longer produces such odd pdfs, and I could not find 4.2 anywhere. thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-12-24 10:38 Message: in earlier versions of pdf spec, values in named resources must be indirect object, hence the test isRef(). I looked into the current pdf spec and it seems the above requirement is gone, not sure from which version of pdf. So we can leave out that test now. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=4299&group_id=106

1 0

[pdftex-Bugs][4306] \pdfelapsedtime returns wrong result in 1.40.10
by pdftex-bugs＠sarovar.org 05 Apr '10

05 Apr '10

Bugs item #4306, was opened at 2010-04-05 09:26 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: \pdfelapsedtime returns wrong result in 1.40.10 Category: Primitives Group: None Resolution: Accepted Initial Comment: See http://www.tug.org/pipermail/pdftex/2009-November/008143.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4306&group_id=106

1 0

[pdftex] New document - ibCQOFCJfFeYEMgU
by noreply＠sarovar.org 08 Mar '10

08 Mar '10

Project: pdftex Group: Document title: ibCQOFCJfFeYEMgU Document description: xY0C43 <a href="http://gyrjuuikjvfu.com/">gyrjuuikjvfu</a>, [url=http://fhkzypgmbxme.com/]fhkzypgmbxme[/url] [link=http://xwhglhqvsinz.com/]xwhglhqvsinz[/link] http://gnotfsrzrcvv.com/ Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

[pdftex-Bugs][4303] pdftex segfaults
by pdftex-bugs＠sarovar.org 25 Feb '10

25 Feb '10

Bugs item #4303, was opened at 2010-02-25 13:06 Status: Open Priority: 3 Submitted By: Jeremy Johnson (redwood) Assigned to: Nobody (None) Summary: pdftex segfaults Category: None Group: None Resolution: None Initial Comment: $ pdftex -version pdfTeX 3.1415926-1.40.10-2.2 (Web2C 2009) kpathsea version 5.0.0 Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.2.40; using libpng 1.2.42 Compiled with zlib 1.2.3; using zlib 1.2.3 Compiled with poppler version 0.12.3 After upgrading from texlive-2008 to 2009 on both my x86 and amd64 Gentoo systems, I discovered that all my forms/letters containing pstricks logos/graphics were missing the logo images, when compiled via "pdflatex --shell-escape letter.tex" using auto-pst-pdf: \usepackage[pspdf={-dAutoRotatePages=/None}]{auto-pst-pdf} Apparently pdfcrop was not able to crop the images. Since my logos were already cropped when I created them in Inkscape, I worked around the issue by disabling cropping: \usepackage[pspdf={-dAutoRotatePages=/None}, crop=off]{auto-pst-pdf} or by using the pdfcrop option --ini: \usepackage[pspdf={-dAutoRotatePages=/None}, pdfcrop={--debug --verbose --ini}]{auto-pst-pdf} After looking through test.log I decided to run the runsystem() commands manually. So I tried running the command pdfcrop --verbose --debug "test-autopp.pdf" "test-pics.pdf" which fails: PDFCROP 1.22, 2009/12/29 - Copyright (c) 2002-2009 by Heiko Oberdiek. * System: unix * Not found (gs): /sbin/gs * Not found (gs): /usr/sbin/gs * Not found (gs): /usr/local/sbin/gs * Not found (gs): /bin/gs * Found (gs): /usr/bin/gs * Autodetected ghostscript command: gs * Input file: test-autopp.pdf * Output file: test-autopp-crop.pdf * Margins: 0 0 0 0 * Running ghostscript for BoundingBox calculation ... * Ghostscript call: gs -sDEVICE=bbox -dBATCH -dNOPAUSE -c save pop -f test- autopp.pdf GPL Ghostscript 8.71 (2010-02-10) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 %%BoundingBox: 597 597 686 686 * Page 1: 597 597 686 686 %%HiResBoundingBox: 597.799951 597.799951 685.686284 685.686284 * Running pdfTeX ... * pdfTeX call: pdftex -no-shell-escape -interaction=nonstopmode tmp- pdfcrop-5737 This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) entering extended mode (./tmp-pdfcrop-5737.tex* Cleanup * Temporary files: tmp-pdfcrop-5737.tex tmp-pdfcrop-5737.log !!! Error: pdfTeX run failed! Next, I decided to manually run pdftex on tmp-pdfcrop-5737.tex pdftex -shell-escape -file-line-error tmp-pdfcrop-5737.tex which segfaults. If I run pdftex on the tmp-pdfcrop-????.tex with strace, I get the attached strace.log In case the segfault has something to do with my font caches /var/cache/fontconfig ~/.fontconfig I cleaned out my font caches: "rm ~/.fontconfig/*" and "mv /var/cache/fontconfig/* /var/cache/fontconfig.bak/" but still get same segfault. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4303&group_id=106

1 0

[pdftex] New document - Test_01
by noreply＠sarovar.org 05 Feb '10

05 Feb '10

Project: pdftex Group: Document title: Test_01 Document description: Basic PDF with bad glyphs, says Preflight Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

About SyncTeX and output-directory option
by Jérome Laurens 26 Jan '10

26 Jan '10

Hi fellows, I have just subscribed to the list in order to give, as the SyncTeX developer, more informations about the question raised earlier by Martin Reinders titled "...SyncTeX and output-directory option" and brought to my attention by Karl Berry. (BTW, sorry for breaking the message thread) As noticed by Martin, since TeXLive 09 the .synctex file is always created in the same directory as the pdf output. This is the only way to tell a pdf viewer that there exists some synctex information around. But, as pointed out in Martin's mail, the problem is that all the input file names are recorded relative to the current directory according to pdftex, which is not the current directory according to the pdf viewer. The consequence is that the relative file names recorded in the .synctex file are broken and useless if we do not know the original input directory. We can consider that this is a limitation in synctex code. However, this is (partly) intentional due to the following reasons 1) I don't know for sure how to deal with paths in a OS independent way (actually synctex code already contain parts dedicated to windows OS) 2) I have not made my mind on how to manage this problem properly 3) There is a poor man's workaround implemented in frontends like iTeXMac2 AFAIR Martin proposed to apply a post processing perl script to change in the .synctex.gz file the relative paths to the "appropriate" values. Unfortunately, this breaks forwards synchronization and will certainly break backwards synchronization too if we further move the pdf output file and its synctex.gz companion to another directory. So this solution is not satisfying. Let me explain what is point 3) above when the main input file is main.tex First we can assume that output-directory is - by pdftex design - a subdirectory of the folder containing main.tex If the full path of the output file is /foo/bar/main.pdf, then synchronization from view to source may work as follow if /foo/bar/main.tex exists then assume that all relative input file names in the .synctex file are relative to /foo/bar else if /foo/main.tex exists then assume that all relative input file names in the .synctex file are relative to /foo else if /main.tex exists then assume that all relative input file names in the .synctex file are relative to / else no synchronization info is available No need to modify the .synctex file, this will solve -in general- the problem when implemented in the synctex aware pdf/dvi viewer. BTW, I tend to use "Factory" as output directory name: pdflatex --output-directory "Factory" main.tex Adopting such a rule would render document sharing more friendly: frontends could use something like if there exists a "Factory" folder then pdflatex --output-directory "Factory" main.tex else pdflatex --whatsover main.tex Also, when trying to synchronize forward from ./main.tex, a front could do something like if ./main.pdf exists use if else if ./Factory/main.pdf exists use it else no forward synchronization is available Moreover, when intermediate tools are used to create input material, like for example graphic charts form statistical data, the graphic file can go to this Factory folder such that the front end just has to launch pdflatex --output-directory "Factory" --input-directory "Factory" main.tex In short, my suggestion would be to somehow hard code "Factory" (or any appropriate name) as output directory name. regards Jerome Laurens, temporarily listening to pdftex

6 5

[pdftex-Bugs][4302] transparency bug: missing /ExtGState in Resources of Form XObject
by pdftex-bugs＠sarovar.org 20 Jan '10

20 Jan '10

Bugs item #4302, was opened at 2010-01-18 16:32 >Status: Closed Priority: 3 Submitted By: Alexander Grahn (grahn) Assigned to: Nobody (None) Summary: transparency bug: missing /ExtGState in Resources of Form XObject Category: None Group: None >Resolution: Invalid Initial Comment: In the attached example a Form XObject is created from a savebox containing transparent objects. The Form XObject is later used by \pdfrefxform\pdflastxform. When loaded in AR-7, the resulting PDF cannot be displayed but causes the error message: Could not find the Extended Graphics State named 'pgf(a)CA0.5'. (AR-7 is more verbose with regard to PDF errors.) The reason is that the XObject produced is broken. At some point in the content stream of the XObject, the graphics state is modified to set the transparency of subsequent fills and strokes: /pgf(a)CA0.5 gs /pgf(a)ca0.5 gs Although the operands pgf(a)CA0.5 and pgf(a)ca0.5 are defined in an ExtGState Dictionary as 1 0 obj << /pgf(a)CA0.5 << /CA 0.5 >> /pgf(a)ca0.5 << /ca 0.5 >>>> endobj the corresponding /ExtGState key is missing in the Resources dictionary of the XObject. Instead, it is put to the Resources dictionary of the Page object. But there it is useless, because it is not used in the content stream of the page. pdfTeX-Version: 1.40.10 ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-01-20 09:46 Message: thanks for confirming. ---------------------------------------------------------------------- Comment By: Alexander Grahn (grahn) Date: 2010-01-20 09:44 Message: After all, it is not a pdftex bug. I found out that PGF/TikZ adds resources such as /ExtGState and /Pattern, used in the graphics, to the /Resources dict of the /Page object. In order to make such resources accessible to the graphics encapsulated in a Form XObject too, one has to once more add a reference to the /Resources dict, this time to the Form XObject to be created, by means of the `resources {...}' argument of \pdfxform. See the attached example file `transs_ok.tex'. I think this bug can be closed. Sorry for the noise. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4302&group_id=106

1 0

[pdftex-Bugs][4302] transparency bug: missing /ExtGState in Resources of Form XObject
by pdftex-bugs＠sarovar.org 20 Jan '10

20 Jan '10

Bugs item #4302, was opened at 2010-01-18 17:32 Status: Open Priority: 3 Submitted By: Alexander Grahn (grahn) Assigned to: Nobody (None) Summary: transparency bug: missing /ExtGState in Resources of Form XObject Category: None Group: None Resolution: None Initial Comment: In the attached example a Form XObject is created from a savebox containing transparent objects. The Form XObject is later used by \pdfrefxform\pdflastxform. When loaded in AR-7, the resulting PDF cannot be displayed but causes the error message: Could not find the Extended Graphics State named 'pgf(a)CA0.5'. (AR-7 is more verbose with regard to PDF errors.) The reason is that the XObject produced is broken. At some point in the content stream of the XObject, the graphics state is modified to set the transparency of subsequent fills and strokes: /pgf(a)CA0.5 gs /pgf(a)ca0.5 gs Although the operands pgf(a)CA0.5 and pgf(a)ca0.5 are defined in an ExtGState Dictionary as 1 0 obj << /pgf(a)CA0.5 << /CA 0.5 >> /pgf(a)ca0.5 << /ca 0.5 >>>> endobj the corresponding /ExtGState key is missing in the Resources dictionary of the XObject. Instead, it is put to the Resources dictionary of the Page object. But there it is useless, because it is not used in the content stream of the page. pdfTeX-Version: 1.40.10 ---------------------------------------------------------------------- Comment By: Alexander Grahn (grahn) Date: 2010-01-20 10:44 Message: After all, it is not a pdftex bug. I found out that PGF/TikZ adds resources such as /ExtGState and /Pattern, used in the graphics, to the /Resources dict of the /Page object. In order to make such resources accessible to the graphics encapsulated in a Form XObject too, one has to once more add a reference to the /Resources dict, this time to the Form XObject to be created, by means of the `resources {...}' argument of \pdfxform. See the attached example file `transs_ok.tex'. I think this bug can be closed. Sorry for the noise. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4302&group_id=106

1 0