- ntg-pdftex - NTG Mailing Lists

[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

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

18 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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4302&group_id=106

1 0

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

24 Dec '09

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: 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-Patches][4301] Patch to detect/prevent wrong arguments of \pdfsetmatrix
by pdftex-patches＠sarovar.org 23 Dec '09

23 Dec '09

Patches item #4301, was opened at 2009-12-23 15:33 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to detect/prevent wrong arguments of \pdfsetmatrix Category: Primitives Group: None Resolution: Accepted Initial Comment: from Hartmut: ,--------, please have a look what this file produces: \nopagenumbers \pdfcompresslevel=0 \pdfsetmatrix{1 2 3 4 5 6} \bye ...it's an invalid "cm". I accidentally typed 6 components instead of 4, but i guess that this user error should be caught. `--------` and Heiko's reply: ,--------, I have attached a patch that should fix it: * In case of unrecognized formats the literal isn't output. * The warning is fixed and moved to pdftex.web. `--------` Patch by Heiko is attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=4301&group_id=106

1 0

[pdftex-Bugs][4300] wrong description of \pdfelapsedtime in manual
by pdftex-bugs＠sarovar.org 23 Dec '09

23 Dec '09

Bugs item #4300, was opened at 2009-12-23 10:20 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: wrong description of \pdfelapsedtime in manual Category: Documentation Group: None Resolution: Accepted Initial Comment: from http://www.ntg.nl/pipermail/ntg-pdftex/2009-December/003872.html: ,--------, The manual says (January 25, 2007, Rev. 1.675): | \pdfelapsedtime <read-only integer> | The command expands to a number ... \pdfelapsedtime is a integer register and therefore not expandable. It doesn't expand, it needs the help of \the or \number for `expansion'. `--------` ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4300&group_id=106

1 0

Manual: \pdfelapsedtime
by Heiko Oberdiek 22 Dec '09

22 Dec '09

Hello, The manual says (January 25, 2007, Rev. 1.675): | \pdfelapsedtime <read-only integer> | The command expands to a number ... \pdfelapsedtime is a integer register and therefore not expandable. It doesn't expand, it needs the help of \the or \number for `expansion'. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> --

1 0

[pdftex-Patches][3886] Fix for str_less_str (bug #993)
by pdftex-patches＠sarovar.org 01 Dec '09

01 Dec '09

Patches item #3886, was opened at 2009-04-06 03:38 >Status: Closed Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Fix for str_less_str (bug #993) Category: None Group: None >Resolution: Accepted Initial Comment: The patch is based on pdftex-1.40.9. It fixes the bug #993 `/Names array not sorted correctly' by correcting function `str_less_str'. In theory pdfTeX can still be fooled by * invalid pdf strings and * equal destination names that only differs in the way of escaping. But both problems can be solved at macro level by passing the name argument of \pdfdest through \pdfescapestring. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 22:03 Message: included in 1.40.10 ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 13:14 Message: Thanh, I forgot. Thanks, also for removing the redundancy -- I am not too familiar with the "web" language. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-06 13:01 Message: Heiko, it seems the test (c2 < 32) is missing for the second string. I changed slightly your patch. It looks a bit ugly now but less redundant. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 04:08 Message: pdftex2.web.diff replaces pdftex.web.diff. It handles the case correctly if the octal sequence starts with a digit greater than three. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=3886&group_id=106

1 0

[pdftex-Patches][2087] Support for CMap namespaces
by pdftex-patches＠sarovar.org 01 Dec '09

01 Dec '09

Patches item #2087, was opened at 2008-08-28 08:17 >Status: Closed Priority: 3 Submitted By: Vasile Gaburici (vga) Assigned to: Nobody (None) Summary: Support for CMap namespaces Category: Fonts Group: v1.40.0 >Resolution: Accepted Initial Comment: There are a couple of LaTeX packages out there (cmap and mmap) that provide CMaps. They don't work as well as \pdfglyphtounicode, i.e. virtual fonts don't get CMaps at all (the CMap is included in the PDF but not referenced), and otftotfm-installed fonts lack the CMap entries for the ligatures that otftotfm sneaks in empty slots. As you know, \pdfglyphtounicode fixes these problems. On the other hand, these two packages let the user specify a CMap for each LaTeX encoding, so the user ca give different Unicode values to the same PS glyph name in different LaTeX encodings. Of course that works properly only if the fonts invoked by the different LaTeX encodings are different; otherwise only one can win the \pdffontattr. A compelling application of this feature are CMaps that set math code points (usually above BMP) for TeX math fonts; those glyphs have exactly the same names as in text fonts /A etc. Adding namespaces to \pdfglyphtounicode makes those two packages obsolete in their current implementation. Another advantage of namespaces is the ability to (reliably) fix TrueType font CMaps. The troublesome glyphs are usually ligatures that don't have a Unicode entry (Th, ti, tf, ffb, etc.), which otftotfm writes as /indexZZZ in the enc file. Putting those in a per-font namespace avoids any potential clashes. So, I've patched pdftex to provide namespaces using the following syntax extension: the first argument of \pdfglyphtounicode can now take additional forms: \pdfglyphtounicode{fnt:tex-font-name/ps-glyph-name}{...} \pdfglyphtounicode{enc:ps-enc-name/ps-glyph-name}{...} Since fonts for which the built-in encoding is used happen to be exactly those that have multiple design sizes (cmr, stmary etc.), using a separate ps-enc-name for each is not helpful. Instead, the 'enc' namespace for those is obtained by dropping any final digits from the font name, e.g. cmr10 has PS encoding cmr (for CMap purposes only). The search policy is to first search the font namespce, then the encoding, and finally the global namespace, for which the syntax remains unchanged. All these namespace are implemented in the same avl tree; just using the above strings as key names. In theory this makes the search 3 times slower, but that particular phase of pdftex hardly takes any time, so it seemed premature to implement any optimization. Some usage examples: % make the ti ligature searchable in Calibri regular \pdfglyphtounicode{fnt:calibly1--base/index415}{0074 0069} % go crazy with Unicode math; TeX math italic gives above-BMP math A \pdfglyphtounicode{enc:cmmi/A}{D835 DC34} % UTF16BE required Note that search behavior for math letters varies with pdf viewers. Acrobat implements only canonical equivalence, so you need to enter the exact code point, and copy/paste preserves the code points, so you can paste into a LaTeX document if it's using utf8x input encoding. Evince implements compatibility equivalence, so it's easier to find those math As by searching for plain A, but they also copy/paste as plain A. You can use pdftotext however, which uses the same poppler backend, to have the code points are preserved. I'm not really advocating Unicode math letters, but now they're easily supported in pdftex -- no need for manual CMaps anymore. BTW, \pdfglyphtounicode now really needs to be documented in the manual, so people would stop writing (buggy) CMaps by hand. I volunteer to do it if you accept the patch :) ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 22:02 Message: included in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-07 14:59 Message: this patch is indeed very useful, however adding tfm namespace support is enough since it can cover the other case. I have changed the patch slightly to: - drop the enc: case - use "tfm:" instead of "fnt:" as the tfm namespace prefix And added a small test file. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=2087&group_id=106

1 0

[pdftex-Support Requests][4298] pdfTeX mit GCC für Windows kompilieren geht nicht
by pdftex-supportrequests＠sarovar.org 01 Dec '09

01 Dec '09

Support Requests item #4298, was opened at 2009-11-14 20:24 >Status: Closed Priority: 3 Submitted By: Siggi Siggi (siggi) Assigned to: Nobody (None) Summary: pdfTeX mit GCC für Windows kompilieren geht nicht Category: None Group: None >Resolution: Wont Fix Initial Comment: ch möchte gerne eine schlange Lösung zum automatisierten Erzeugen von PDF-Dateien haben - am besten indem ich .tex-Dateien konvertiere. Da pdfTeX ein schlankes Programm ist, versuchte ich den Quellcode zu kompilieren (da ich keine fertigen Binaries für Windows finden konnte). Ich kompiliere in der Umgebung MSys mit dem GCC. Dabei kommt es zuerst zum Typenkonflikt durch die erneute Deklaration des Datentyp 'Boolean' im Quellcode von pdfTeX. Wenn ich in den GCC includes die typedef auskommentiere, schreitet der Kompilierprozess weiter voran, bricht aber schließlich erneut ab mit der Meldung: http://a.imagehost.org/view/0059/cmd Kann mir jemand sagen, warum ganz unten kein Dateiname vorhanden ist, weshalb der Kompiliervorgang fehlschlägt? Unabhängig davon: Gibt es die Möglichkeit, pdfTeX komplett in eine .exe-Datei oder .dll-Datei zu kompilieren (ohne externe Bibliotheken)? Das wäre eigentlich die optimale Lösung. Grüße siggi ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:39 Message: Please use texlive or miktex, which includes pdftex. fwiw, compiling pdftex using minwg *is* possible, just not officially supported. If you want to build pdftex from sources, you are on your own. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4298&group_id=106

1 0

[pdftex-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 01 Dec '09

01 Dec '09

Support Requests item #4297, was opened at 2009-10-31 15:50 >Status: Closed Priority: 3 Submitted By: Bob Tennent (rdtennent) Assigned to: Nobody (None) Summary: conflicting types for 'getline' Category: Install Problem (example) Group: None Resolution: None Initial Comment: Building pdftex on a Fedora 11 system using build.sh fails: gcc -DHAVE_CONFIG_H -I. -I../../../src/texk/web2c -I.. -I../../../src/texk/web2c/.. -I../../libs/obsdcompat -I../../libs/obsdcompat/.. -I../../../src/texk/web2c/../../libs/obsdcompat -I../../../src/texk/web2c/../../libs/obsdcompat/.. -I../../../src/texk/web2c/../../libs/zlib -g -O2 -c tangleboot.c -o tangleboot.o In file included from tangleboot.c:94: tangleboot.h:34: error: conflicting types for 'getline' /usr/include/stdio.h:653: note: previous declaration of 'getline' was here tangleboot.c:2175: error: conflicting types for 'getline' /usr/include/stdio.h:653: note: previous declaration of 'getline' was here I've built pdftex often on other systems without running into this. What's wrong? ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 15:05 Message: >| Near the end of texk/web2c/cpascal.h: #ifdef getline #undef getline #endif #define getline web2c_getline Thanks. I'd change this request to "closed" if I could figure out how :+) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2009-11-02 14:22 Message: Near the end of texk/web2c/cpascal.h: #ifdef getline #undef getline #endif #define getline web2c_getline ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 14:08 Message: "there is a fix for this problem in texlive 2009" That won't help those of us using a distribution like Fedora 11 which is still at texlive-2007. Editing stdio.h isn't an option for most users. And editing the source of pdftex isn't straightforward because of the conversions. What exactly is the "fix" implemented in texlive 2009? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2009-11-02 07:30 Message: POSIX 2008? That's new. It seems the glibc team likes to break old programs. http://blog.scottt.tw/2009/04/getline-is-in-posix-2008-and-exposed-in.html and numerous other hits. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2009-11-02 07:13 Message: FWIW: there is a fix for this problem in texlive 2009. ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 03:03 Message: This is the response at the Fedora bugzilla: getline is a standard POSIX 2008 function, and glibc headers by default offer POSIX 2008 namespace. See info libc 'Feature Test Macros' for details. You should just either fix pdftex to use a different name, not reserved by POSIX 2008, or use a namespace macro that doesn't provide POSIX 2008 stuff. https://bugzilla.redhat.com/show_bug.cgi?id=532230 ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-10-31 16:50 Message: According to some reports on the web, the problem is in glibc-2.10.1. Apparently the non-standard definition of getline there should be "protected". Indeed, if I comment out that definition in /usr/include/stdio.h, pdftex builds normally. I'm willing to file a bug report in the Fedora bugzilla but I need some help: what exactly is the "protection" needed? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4297&group_id=106

1 0

[pdftex-Bugs][4296] No /Fit, please!
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #4296, was opened at 2009-10-05 12:46 >Status: Closed Priority: 3 Submitted By: Lars Hellström (lars_h) Assigned to: Nobody (None) Summary: No /Fit, please! Category: Documentation Group: v1.40.8 >Resolution: Invalid Initial Comment: In the pdfTeX manual (e.g. the ones that comes with TeXLive 2009), all links seem to be made with /Fit destinations. THIS --- shrinking the text to beneath readable size at every jump, so that one constantly has to rezoom the document in order to read it --- IS INCREDIBLY ANNOYING! For your information, it's not very difficult to preserve the zoom level: just use /XYZ with null for z (and maybe also x and y, if determining the destination location is too hard). Please stop using the extremely annoying /Fit. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:32 Message: sorry, this is not a bug but a matter of personal taste/opinion. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4296&group_id=106

1 0

[pdftex-Bugs][606] Forbidden ... while scanning ???
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #606, was opened at 2006-09-16 20:28 >Status: Closed Priority: 2 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Forbidden ... while scanning ??? Category: Primitives Group: v1.40.0 >Resolution: Fixed Initial Comment: \pdftrailer {abc \bye gives ! Forbidden control sequence found while scanning text of \pdftrailer. but \pdfximage {abc \bye or \pdfliteral {abc \bye give ! Forbidden control sequence found while scanning text of ???. Instead of these three question marks there should be the name of the primitive. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:29 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2009-04-07 06:28 Message: Attached is what I would do: patch scan_keyword() to restore cur_cs in the 'false' case. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-27 15:40 Message: Logged In: YES user_id=421 Hartmut, can you please check this again for 1.50? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-21 12:22 Message: Logged In: YES user_id=421 I've backed out the change; this is low priority and probably needs more changes. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-17 19:10 Message: Logged In: YES user_id=929 yes, the patch works, thanks a lot! But there are in fact many more \pdf... primitives that suffer from this problem, actually any with a scan_keyword call before the scan_pdf_ext_toks. After the way how it's done in @<Implement \.{\\write}@>=, it seems that a new variable save_cur_cs is not needed if one uses k for this purpose. Needs change of a few k uses to j. But problematic is \pdfoutline as it has another scan_pdf_ext_toks for the attr keyword. Wouldn't these many changes be too risky for 1.40.0? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 16:34 Message: Logged In: YES user_id=421 The patch was missing. Fixed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 14:30 Message: Logged In: YES user_id=421 The cause seems to be that some scan_functions loose the meaning of cur_cs, which leads to the ??? when reaching <Tell the user what has run away...@>. The attached (IMHO crude) patch fixes this for the cases you mentioned, but there are probably other cases not found... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106

1 0

[pdftex-Bugs][4289] \primitive\pdfoutput cannot be queried
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #4289, was opened at 2009-05-21 18:52 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: \primitive\pdfoutput cannot be queried Category: None Group: None >Resolution: Fixed Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-April/003769.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:26 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-05-21 18:54 Message: fix from Taco attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4289&group_id=106

1 0

[pdftex-Bugs][4290] processing speed: pdftex slows down when processes long files in DVI mode
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #4290, was opened at 2009-06-26 17:55 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: processing speed: pdftex slows down when processes long files in DVI mode Category: None Group: None >Resolution: Fixed Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-May/003786.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:24 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-07-01 19:46 Message: with the help from Taco and Hartmut, the problem has been traced down to this: section 816 from tex the program says: ,-------- | This code assumes that a |glue_node| and a |penalty_node| occupy the | same number of |mem|~words. | @^data structure assumptions@> | | @<Get ready to start...@>= | link(temp_head):=link(head); | if is_char_node(tail) then tail_append(new_penalty(inf_penalty)) | else if type(tail)<>glue_node then tail_append(new_penalty(inf_penalty)) | else begin type(tail):=penalty_node; delete_glue_ref(glue_ptr(tail)); | flush_node_list(leader_ptr(tail)); penalty(tail):=inf_penalty; | end; `-------- and synctex has changed glue_node_size to 4, so that when a paragraph is processed, there is one node that was located with size=4 but freed with size=2. Therefore the problem is only visible with very long document like Reinhard's test file. Taco's suggestion for the problem: > I strongly suggest you just change the penalty size to 4, because > the other possibilities that I see have much more impact. Starting > from the head node each time is quite slow (much slower than the > speed penalty incurred by the extra size of the penalty node). > > There are other options, but increasing the penalty size is simplest > by far. And it is not like a typical paragraph has hundreds of > penalties, anyway. > > In luatex this worked out reasonably well in the end because in > luatex the node list is doubly linked. But in pdftex there is no > room for an extra back pointer in the node objects (nor is there > in either tex or xetex) so that won't work without a lot of work. and my response: ,-------- | yes this seems a good option. There is still one catch that | pdftex without synctex still has glue_node_size=2 and | doesn't need this change. Therefore this should better be | done by synctex. `-------- I have sent an email asking synctex's author for this change. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4290&group_id=106

1 0

[pdftex-Bugs][4288] character width mismatch in font XY.vf ignored
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #4288, was opened at 2009-05-12 07:47 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: character width mismatch in font XY.vf ignored Category: Fonts Group: None >Resolution: Fixed Initial Comment: see http://tug.org/pipermail/pdftex/2009-May/008031.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:24 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-05-12 12:23 Message: bugfix from Hartmut attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4288&group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #993, was opened at 2008-05-24 13:24 >Status: Closed Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly Category: None Group: v1.40.6 >Resolution: Fixed Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:22 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-06 08:22 Message: thanks Heiko for the patch, hence I reopened this bug report. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 03:49 Message: Sorry, I cannot accept the rejection, because the problem cannot be fixed at macro level unless * some characters (backslash, parentheses, ...) must be forbidden, * octal escape sequences are used for *every* character of the destination name (otherwise a large amount of programming work is needed to prevent that the bug is triggered.) Therefore I have written patch #3886 that fixes the comparison function `str_less_str' that is used for the sorting of destination names. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 22:55 Message: since the beginning we chose not to parse pdf string of \pdf* commands. Fixing this now would mean a too big change in pdftex code. Sorry. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 16:48 Message: ok then this should be fixed as the spec says. BTW, it doesn't really solve the reported problem (ü will come after eg z). ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2008-05-27 16:03 Message: the spec says: The Names entries in the leaf (or root) nodes contain the tree’s keys and their associated values, arranged in key-value pairs and sorted lexically in ascending order by key. Shorter keys appear before longer ones beginning with the same byte sequence. The encoding of the keys is immaterial as long as it is self-consistent; keys are compared for equality on a simple byte-by-byte basis. so, it's just bytes ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 15:43 Message: this is a problem, but it's not clear to me how it should be fixed. Assume that we translate "\374" to the corresponding charcode (0374 = 252) before sorting, then how we decide the lexicographic order of that char? it can be intepreted as ü but also can be eg ytilde or something different, depending on the encoding we use. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0

pdftex-1.40.10
by Thanh Han The 01 Dec '09

01 Dec '09

Hi, pdftex-1.40.10 is available at http://sarovar.org/frs/download.php/1292/pdftex-1.40.10.tar.bz2 This is a maintenance release with mostly bugfixes. ,--------, | - sync with TL09 | - changes: | - increased sup_dest_names_size | - partial support for TTC | - enable mktexpk by default | - patch #2087: Support for CMap namespace | - \pdfshellescape is 2 if restricted shell escapes are enabled. | - bugfixes: | - segfault when processing certain TTF fonts | - jpg image resolution not set in some cases | - \pdfobj file {foo} for files foo that don't end with '\n' | - bugfix #4289: \primitive\pdfoutput cannot be queried | - bugfix #4288: character width mismatch in font XY.vf ignored | - bugfix #993: "/Names array not sorted correctly" | - bugfix #606: "Forbidden ... while scanning ???" | - bugfix #3253: Bug in Type1 font subsetting | - \show\pdfstartlink is wrong | - pdf_set_rule() uses incorrect variables | - bugfix #2090: enabling LFS breaks PDF inclusion on some systems (warning: not heavily-tested yet) | - t1_log() macro caused problem with some compilers `--------` there are still some minor bugs which are not included in 1.40.10, since this release is to be compatible with TL09. Regards, Thanh

1 0

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

27 Nov '09

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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=4299&group_id=106

1 0

pdf font inclusion error (with partial patch)
by Taco Hoekwater 26 Nov '09

26 Nov '09

Hi, I have added the patch below to luatex and a similar one-liner for my local pdftex because we here ran into a pdf document that has the following oddness: 5 0 obj << /F15 << /Type /Font /Subtype /TrueType /BaseFont /WIDGBH+ArialMT /Encoding /WinAnsiEncoding /FirstChar 0 /LastChar 255 /FontDescriptor 8 0 R /Widths 7 0 R >> ... >> 6 0 obj << /Type /Page /Parent 4 0 R /MediaBox [ 0 0 595.276 841.89 ] /Resources << /Font 5 0 R /ProcSet [ /PDF /Text /ImageB /ImageC ] >> /Contents 13 0 R >> endobj Current pdftoepdf.cc expects to find indirect references inside object 5, without the patch it generates a fatal error. The patch itself is only a quick fix that works thanks to my setting of \pdfinclusioncopyfonts, as I do not know how to fix the 'other' case, sorry. Best wishes, Taco taco(a)metatex.org wrote: > Author: taco > Date: 2009-11-26 15:14:10 +0100 (Thu, 26 Nov 2009) > New Revision: 3192 > > Modified: > trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc > Log: > add a quick and dirty fix for pdfs generated by easyPDF Printer Driver 4.2, > which uses full font dictionaries inside the Font resources instead of > indirect references. > > > Modified: trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc > =================================================================== > --- trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc 2009-11-23 21:04:08 UTC (rev 3191) > +++ trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc 2009-11-26 14:14:10 UTC (rev 3192) > @@ -459,7 +459,8 @@ > pdf_puts(pdf, "/Font << "); > for (i = 0, l = obj->dictGetLength(); i < l; ++i) { > obj->dictGetValNF(i, &fontRef); > - if (fontRef->isRef()) > + if (fontRef->isRef() || > + (fontRef->isDict() && (pdf->inclusion_copy_font == 0))) > copyFont(pdf, obj->dictGetKey(i), &fontRef); > else > pdftex_fail("PDF inclusion: invalid font in reference type <%s>", > > _______________________________________________ > Luatex-commits mailing list > Luatex-commits(a)lists.foundry.supelec.fr > http://lists.foundry.supelec.fr/mailman/listinfo/luatex-commits

1 0

pdftex-1.40.10-RC
by Thanh Han The 20 Nov '09

20 Nov '09

Hi, pdftex-1.40.10-RC is available at http://sarovar.org/frs/download.php/1284/pdftex-1.40.10-RC.tar.bz2 This is a maintenance release with mostly bugfixes. ,--------, | - sync with TL09 | - changes: | - increased sup_dest_names_size | - partial support for TTC | - enable mktexpk by default | - patch #2087: Support for CMap namespace | - \pdfshellescape is 2 if restricted shell escapes are enabled. | - bugfixes: | - segfault when processing certain TTF fonts | - jpg image resolution not set in some cases | - \pdfobj file {foo} for files foo that don't end with '\n' | - bugfix #4289: \primitive\pdfoutput cannot be queried | - bugfix #4288: character width mismatch in font XY.vf ignored | - bugfix #993: "/Names array not sorted correctly" | - bugfix #606: "Forbidden ... while scanning ???" | - bugfix #3253: Bug in Type1 font subsetting | - \show\pdfstartlink is wrong | - pdf_set_rule() uses incorrect variables | - bugfix #2090: enabling LFS breaks PDF inclusion on some systems (warning: not heavily-tested yet) | - t1_log() macro caused problem with some compilers `--------` there are still some minor bugs which will not be fixed in 1.40.10 yet, since this release is to be compatible with TL09. Regards, Thanh

1 0

[pdftex-Bugs][4294] issue with isolated/non-isolated page transparency group
by pdftex-bugs＠sarovar.org 17 Nov '09

17 Nov '09

Bugs item #4294, was opened at 2009-09-02 00:43 >Status: Closed Priority: 3 Submitted By: John Owens (jowens) >Assigned to: Martin Schröder (oneiros) Summary: issue with isolated/non-isolated page transparency group Category: PDF inclusion Group: None >Resolution: Works For Me Initial Comment: (The last bug didn't show up. So I am posting a web link to the three files referenced below: http://tinyurl.com/n4jjm4 ) Howdy, I'm attaching 3 files. One is a tar.gz of a LaTeX document. When we first submitted the paper built from the document, we used dvips and Distiller. Now we're using pdflatex for the final version. Both pdfs are attached. However, strangely, page 4 on the pdflatex pdf, when viewed in Apple Preview on Snow Leopard (10.6), has substantially lighter fonts than the other pages. This is probably Preview's problem, not pdflatex's problem, and I've filed an Apple bug. However, from talking to a PDF expert (summary below), it appears that pdflatex is doing something weird, so I thought I'd bring it to your attention. The base page transparency group for page 4 is nonisolated, where for all the other pages the /I key is not present (and thus they are implicitly isolated). The PDF is correct, although a little weird--there is no point in even specifying the isolation key of a page's transparency group unless it a) contains non-normal blend modes _and_ b) will be rendered in non-device-like contexts (e.g., as an object in a larger piece of artwork). So I would argue that pdflatex should probably not even bother specifying the /I key, especially given that it appears to trigger a bug--or at least a dramatically different code path--in Preview. This _should_ have no effect, as the value of the /I key for the page group is supposed to be ignored (and treated as if it were true). Furthermore even if Preview were ignoring that requirement, the page doesn't have any blend modes, so mathematically it shouldn't be producing a different result. But my guess is this: Preview is rendering page 4 into a nonisolated transparency group using an initial, opaque, all-white backdrop, when it should be completely ignoring the /I key and rendering into a completely transparent backdrop. This shouldn't lead to different results unless a blend mode is present. But,the isolated and nonisolated code paths are somehow sufficiently different that they generate different pixel values--due to precision or perhaps an actual bug. But most of what I say is conjecture. See chapter 7.3.6 ("Page Group") of the PDF Reference Manual, sixth edition. The Distiller version doesn't even have transparency group objects on the pages (which is normal). So I wouldn't expect it to have the same issues in Preview, and it doesn't. (This is LaTeX source for a paper, so though I know you'll need the source to do your investigations and bug fixes, kindly don't do anything else with it beyond that.) $ pdflatex --version pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 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.39; using libpng 1.2.39 Compiled with zlib 1.2.3; using zlib 1.2.3 Compiled with xpdf version 3.02pl3 $ uname -a Darwin classico-2.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 i386 ---------------------------------------------------------------------- Comment By: John Owens (jowens) Date: 2009-11-17 01:33 Message: Quite sensible. Not reasonable to expect pdftex to analyze the PDF and decide if a page's group dictionary is unnecessary. I think you can close this out. Thanks for looking at it! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2009-11-16 01:08 Message: John, the display problem is most likely a problem of apple - I can't reproduce the effext with AR9 on Linux. The page group on page 4 comes from the included pdf (figures/multiValue.pdf). pdftex will copy a page group from an included pdf (or synthesize one for pngs with transparency). I don't think it should analyze the content of the page groups it copies. ---------------------------------------------------------------------- Comment By: John Owens (jowens) Date: 2009-11-16 00:46 Message: Just checkin' in. Thanks! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-10-23 18:41 Message: yes this is. Sorry for not replying, I will take a close look in about 2 weeks. ---------------------------------------------------------------------- Comment By: John Owens (jowens) Date: 2009-10-22 22:21 Message: Is this the right place to report pdftex issues? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4294&group_id=106

1 0