- ntg-pdftex - NTG Mailing Lists

[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-01 15:43 Status: Open Priority: 3 Submitted By: John Owens (jowens) Assigned to: Nobody (None) Summary: issue with isolated/non-isolated page transparency group Category: PDF inclusion Group: None Resolution: None 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-16 16: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-15 16: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-15 15:46 Message: Just checkin' in. Thanks! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-10-23 09: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 13: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

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

16 Nov '09

Bugs item #4294, was opened at 2009-09-02 00:43 Status: Open Priority: 3 Submitted By: John Owens (jowens) Assigned to: Nobody (None) Summary: issue with isolated/non-isolated page transparency group >Category: PDF inclusion Group: None Resolution: None 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: 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

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

16 Nov '09

Bugs item #4294, was opened at 2009-09-01 15:43 Status: Open Priority: 3 Submitted By: John Owens (jowens) Assigned to: Nobody (None) Summary: issue with isolated/non-isolated page transparency group Category: None Group: None Resolution: None 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-15 15:46 Message: Just checkin' in. Thanks! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-10-23 09: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 13: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

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

14 Nov '09

Support Requests item #4298, was opened at 2009-11-14 20:24 Status: Open 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: None 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 ---------------------------------------------------------------------- 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 02 Nov '09

02 Nov '09

Support Requests item #4297, was opened at 2009-10-31 11:50 Status: Open 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 10: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 09: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 09: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 02: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 02:13 Message: FWIW: there is a fix for this problem in texlive 2009. ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-01 22: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 12: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-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 02 Nov '09

02 Nov '09

Support Requests item #4297, was opened at 2009-10-31 16:50 Status: Open 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: Taco Hoekwater (taco) Date: 2009-11-02 15: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 15: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 08: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 08:13 Message: FWIW: there is a fix for this problem in texlive 2009. ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 04: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 17: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-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 02 Nov '09

02 Nov '09

Support Requests item #4297, was opened at 2009-10-31 11:50 Status: Open 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 09: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 02: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 02:13 Message: FWIW: there is a fix for this problem in texlive 2009. ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-01 22: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 12: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-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 02 Nov '09

02 Nov '09

Support Requests item #4297, was opened at 2009-10-31 16:50 Status: Open 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: Martin Schröder (oneiros) Date: 2009-11-02 08: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 08:13 Message: FWIW: there is a fix for this problem in texlive 2009. ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 04: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 17: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-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 02 Nov '09

02 Nov '09

Support Requests item #4297, was opened at 2009-10-31 16:50 Status: Open 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: Taco Hoekwater (taco) Date: 2009-11-02 08:13 Message: FWIW: there is a fix for this problem in texlive 2009. ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 04: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 17: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-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 02 Nov '09

02 Nov '09

Support Requests item #4297, was opened at 2009-10-31 11:50 Status: Open 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-01 22: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 12: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-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 31 Oct '09

31 Oct '09

Support Requests item #4297, was opened at 2009-10-31 11:50 Status: Open 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-10-31 12: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-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 31 Oct '09

31 Oct '09

Support Requests item #4297, was opened at 2009-10-31 11:50 Status: Open 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? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4297&group_id=106

1 0

[pdftex] New document - eqpuarxok
by noreply＠sarovar.org 31 Oct '09

31 Oct '09

Project: pdftex Group: Document title: eqpuarxok Document description: 9HXzzg <a href="http://ymxcfbghfyrr.com/">ymxcfbghfyrr</a>, [url=http://jfqmuarxbzuh.com/]jfqmuarxbzuh[/url] [link=http://igqbdfiqwvab.com/]igqbdfiqwvab[/link] http://omuamnsihtyg.com/ Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

suspicious line in pdftoepdf.cc
by Taco Hoekwater 28 Oct '09

28 Oct '09

Hi, FYI: We just ran into a bug in luatex where there acciddentally appear newlines before the %!PDF in the output file. It turns out this is caused by querying embedded PDF images before any real output has taken place. We tracked it down to a line in pdftoepdf.cc that is present in both luatex and pdftex. In the current pdftex trunk, it is line 836 (inside read_pdf_info function): // get the group and make sure it's indirect if (page->getGroup() != NULL) { initDictFromDict(lastGroup, page->getGroup()); if (lastGroup->dictGetLength() > 0) { groupIsIndirect = lastGroup->isRef(); if (groupIsIndirect) { // FIXME: Here we already copy the object. It would be // better to do this only after write_epdf, otherwise we // may copy ununsed /Group objects copyObject(&lastGroup); epdf_lastGroupObjectNum = getNewObjectNumber(lastGroup->getRef()); } else { // make the group an indirect object; copying is done later // by write_additional_epdf_objects after write_epdf epdf_lastGroupObjectNum = pdfnewobjnum(); } pdf_puts("\n"); // THIS line } I have currently moved the pdf_puts in luatex to inside the if (groupIsIndirect) { branch, but that is probably not right either, in light of that FIXME. Best wishes, Taco

1 0

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

23 Oct '09

Bugs item #4294, was opened at 2009-09-01 22:43 Status: Open Priority: 3 Submitted By: John Owens (jowens) Assigned to: Nobody (None) Summary: issue with isolated/non-isolated page transparency group Category: None Group: None Resolution: None 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: The Thanh Han (hanthethanh) Date: 2009-10-23 16: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 20: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

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

22 Oct '09

Bugs item #4294, was opened at 2009-09-01 15:43 Status: Open Priority: 3 Submitted By: John Owens (jowens) Assigned to: Nobody (None) Summary: issue with isolated/non-isolated page transparency group Category: None Group: None Resolution: None 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-10-22 13: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

build-pdftex.sh fails in stable
by Martin Schröder 06 Oct '09

06 Oct '09

./CXXLD.sh: g++ -g -O2 -o pdftosrc pdftosrc-pdftosrc.o /home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/libs/libpng/libpng.a /home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/libs/zlib/libz.a /home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/libs/xpdf/libxpdf.a /home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/libs/obsdcompat/libopenbsd-compat.a libmd5.a lib/lib.a /home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/texk/kpathsea/.libs/libkpathsea.a -lm -nodefaultlibs -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm -lgcc_eh -lgcc -lc -lgcc_eh -lgcc make[5]: *** No rule to make target `omegaware/otangle.web', needed by `otangle.p'. Stop. make[5]: Leaving directory `/home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/texk/web2c' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/texk/web2c' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/texk/web2c' make[2]: *** [subtexk] Error 1 make[2]: Leaving directory `/home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/texk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ms/tex/pdftex/svn/branches/stable/source/build-pdftex/texk' make: *** [all-recursive] Error 1

1 0

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

05 Oct '09

Bugs item #4296, was opened at 2009-10-05 14:46 Status: Open Priority: 3 Submitted By: Lars Hellström (lars_h) Assigned to: Nobody (None) Summary: No /Fit, please! Category: Documentation Group: v1.40.8 Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4296&group_id=106

1 0

[pdftex-Feature Requests][4295] CIDFonts, raw font embedding
by pdftex-featurerequests＠sarovar.org 05 Oct '09

05 Oct '09

Feature Requests item #4295, was opened at 2009-10-05 14:22 Status: Open Priority: 3 Submitted By: Lars Hellström (lars_h) Assigned to: Nobody (None) Summary: CIDFonts, raw font embedding Category: Fonts Group: v1.50 Resolution: None Initial Comment: As posted to the pdftex mailing list in September 2009: A while ago, I started examining new ways of using OpenType fonts with TeX, focusing in particular on catering for fonts that have many ligatures or alternate glyphs. I expect I'll end up creating some new tool for converting fonts to TeX-usable format, but would prefer to make do with existing backends (in particular dvips and pdfTeX) as far as possible. One of my early hypotheses, which so far has held beautifly, is that OpenType fonts are best served by being treated as CIDFonts. This is particularly clear for the combination of TrueType font and PDF, since the support in PDF (the standard) for simple TrueType fonts can at best be described as a kludge, whereas the composite font (i.e., CIDFont) counterpart provides clean control of e.g. the encoding. CIDFonts don't seem to have been much used by us TeXies, though (presumably because they were introduced to deal with CJK fonts, and their documentation is geared towards suggesting such usage). Getting dvips to map a TeX font onto a (PS type 0 font mapping to) a CIDFont is merely a matter of giving it a file with "the font" in a suitable PS wrapper, and as of today I have a couple of procedures that will generate such a wrapper for an arbitrary TrueType font.[*] Unfortunately, pdfTeX doesn't seem so easily instructed. I know what data structure should appear in the finished PDF file, but there doesn't seem to be a way of making pdfTeX put it there -- at least not (a) according to the manual (though that may be incomplete; e.g. I've noticed some mechanisms for interpreting encoding vector glyph names that exist in the source but aren't mentioned in the manual) and (b) from within the map file. Using \pdffontattr I suppose it is possible to construct a pretty arbitrary font dictionary from within TeX code, but that doesn't seem to be able to get at the base fonts of a virtual font, which would really be all that the CIDFonts should be. Moreover I'd prefer it if the font set-up could be accomplished without pdfTeX-specific TeX commands, as that is hard to integrate with LaTeX's NFSS. So therefore I would like to request a new pdfTeX feature, to the end of allowing a mapfile to specify that an arbitrary PDF data structure should be used as the font dictionary corresponding to a specific TeX font. Now, the most practical way of encoding a PDF data structure for embedding is of course to provide it within another PDF file; I understand pdfTeX already has the machinery to copy a PDF object (and everything it references) from another PDF file, so this shouldn't be difficult to implement.[**] Concerning the interface, my suggestion would be the following: * If the <fontfile> in a mapline has suffix .pdf, then the wanted font dictionary can be found in its Catalog/Pages/Resources/Fonts dictionary, i.e., among the fonts in the Resources dictionary of the root node in the pages tree of that file. The <basename> of the mapline is then the key within the Resources/Fonts dictionary of the selected font. For nice appearance, one could structure such "font container" PDF files to be demonstrations of the glyphs in the font(s), maybe even with instructions for how to configure pdfTeX to use them... Lars Hellström [*] The same principles should apply for CFF fonts, but in that case one has to cut a bit deeper when performing some necessary surgery, so I'm leaving those for later. The PS wrapper is simpler in that case than for TrueType, though. [**] Not difficult, unless one insists on subsetting the fonts. For the moment I'm perfectly happy with getting the font embedded in full, since that is /way/ better than not being able to use it at all. Subsetting can always be added later, if anyone cares enough to implement it. To the above, Thanh replied by off-list email: what you suggested should be very doable and I am interested in getting it done, too. However I am overloaded at the moment; can we come back to this issue in about 2 months? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=4295&group_id=106

1 0

Re: [NTG-pdftex] [luatex] tex.enableprimitives producing non-primitives?
by Heiko Oberdiek 23 Sep '09

23 Sep '09

On Wed, Sep 23, 2009 at 12:30:40PM +0300, Élie Roux wrote: > [discussion about the use of \pdfprimitive] Perhaps it becomes clearer, if I quote the pdfTeX manual: | \pdfprimitive control sequence | | This command executes the primitive meaning of the following control | sequence, if it has been redefined or made undefined. If the following | control sequence is undefined and never was a primitive, nothing happens | and no error is raised. If the control sequence was initially expandable, | \pdfprimitive expands either. Otherwise \pdfprimitive doesn't expand. The | primitive has been introduced in pdfTEX 1.40.0. BTW, as you have seen, the second sentence is wrong: \catcode`\{=1 \catcode`\}=2 \ifx\directlua\undefined \else \directlua{tex.enableprimitives('',{'pdfprimitive'})} \fi \pdfprimitive\FooBar \end pdftex -ini: This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009) (INITEX) ... ! Missing primitive name. <to be read again> \FooBar l.7 \pdfprimitive\FooBar luatex -ini: This is LuaTeX, Version beta-0.40.6-2009090421 (TeX Live 2009) (INITEX) ... ! Missing primitive name. <to be read again> \FooBar l.7 \pdfprimitive\FooBar I think, the error message is a good thing, thus the manual should be fixed. (Therefore I have added ntg-pdftex). Also the manual could meantion, that \pdfprimitive was fixed in 1.40.4. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de>

2 1

[pdftex] New document - qbFwnNzIjkXbPqPJE
by noreply＠sarovar.org 18 Sep '09

18 Sep '09

Project: pdftex Group: Document title: qbFwnNzIjkXbPqPJE Document description: dPrCQjrAAgvRyrw Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

[pdftex-Bugs][4293] error on build: C compiler cannot create executables
by pdftex-bugs＠sarovar.org 02 Sep '09

02 Sep '09

Bugs item #4293, was opened at 2009-09-01 00:51 >Status: Closed Priority: 3 Submitted By: Pedrocelli (pedrocelli) Assigned to: Nobody (None) Summary: error on build: C compiler cannot create executables Category: Build process Group: None >Resolution: Invalid Initial Comment: Build of pdfLaTex version 1.40.9 attempted on Red Hat Linux 2.6.18, and failed with the above message. Log file config.log attached. What do I need to do to build this? Cheers Pedrocelli ---------------------------------------------------------------------- Comment By: Pedrocelli (pedrocelli) Date: 2009-09-02 05:16 Message: No I haven't - it's a new system. I don't know if anyone else has but it doesn't matter - I installed it through the package manager and it works fine. Thanks Pedrocelli ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-09-01 14:11 Message: The log file says: ,--------, | configure:2575: gcc conftest.c >&5 | collect2: cannot find 'ld' `--------` Have you successfully built anything from sources on that system? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4293&group_id=106

1 0

[pdftex-Bugs][4293] error on build: C compiler cannot create executables
by pdftex-bugs＠sarovar.org 02 Sep '09

02 Sep '09

Bugs item #4293, was opened at 2009-09-01 12:51 Status: Open Priority: 3 Submitted By: Pedrocelli (pedrocelli) Assigned to: Nobody (None) Summary: error on build: C compiler cannot create executables Category: Build process Group: None Resolution: None Initial Comment: Build of pdfLaTex version 1.40.9 attempted on Red Hat Linux 2.6.18, and failed with the above message. Log file config.log attached. What do I need to do to build this? Cheers Pedrocelli ---------------------------------------------------------------------- Comment By: Pedrocelli (pedrocelli) Date: 2009-09-02 17:16 Message: No I haven't - it's a new system. I don't know if anyone else has but it doesn't matter - I installed it through the package manager and it works fine. Thanks Pedrocelli ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-09-02 02:11 Message: The log file says: ,--------, | configure:2575: gcc conftest.c >&5 | collect2: cannot find 'ld' `--------` Have you successfully built anything from sources on that system? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4293&group_id=106

1 0

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

02 Sep '09

Bugs item #4294, was opened at 2009-09-01 15:43 Status: Open Priority: 3 Submitted By: John Owens (jowens) Assigned to: Nobody (None) Summary: issue with isolated/non-isolated page transparency group Category: None Group: None Resolution: None 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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4294&group_id=106

1 0

[pdftex-Bugs][4293] error on build: C compiler cannot create executables
by pdftex-bugs＠sarovar.org 01 Sep '09

01 Sep '09

Bugs item #4293, was opened at 2009-09-01 00:51 Status: Open Priority: 3 Submitted By: Pedrocelli (pedrocelli) Assigned to: Nobody (None) Summary: error on build: C compiler cannot create executables Category: Build process Group: None Resolution: None Initial Comment: Build of pdfLaTex version 1.40.9 attempted on Red Hat Linux 2.6.18, and failed with the above message. Log file config.log attached. What do I need to do to build this? Cheers Pedrocelli ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-09-01 14:11 Message: The log file says: ,--------, | configure:2575: gcc conftest.c >&5 | collect2: cannot find 'ld' `--------` Have you successfully built anything from sources on that system? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4293&group_id=106

1 0