August 2006 - ntg-pdftex - NTG Mailing Lists

1.40.0-beta-20060811
by Martin Schröder 18 Aug '06

18 Aug '06

http://sarovar.org/download.php/1064/pdftex-1.40.0-beta-20060811.tar.bz2 http://sarovar.org/download.php/1065/pdftex-1.40.0-beta-20060725-20060811.d… --------------------------------------------------------------- pdfTeX 3.141592-1.40.0-beta-20060811 was released on 2006-08-11 --------------------------------------------------------------- - renamed primitives: \primitive -> \pdfprimitive \ifprimitive -> \ifpdfprimitive \ifabsdim -> \ifpdfabsdim \ifabsnum -> \ifpdfabsnum - new version of \primitive/\ifprimitive (but see above) - new dimen: \pdfpxdimen - support for jbig2 files - new library: obsdcompat, which has improved string functions and allows the use of __attribute__ - update libpng to 1.2.12 - added JFIF detection patch to writejpg.c (was bug 548) - bugfix: truetype OS/2 v3 fonts (594) - bugfix: file with only \immediate\pdfobj stream results in garbage (505) - bugfix: invalid pdf created if font name contains space (509) Please have a look at libs/obsdcompat; it has a bunch of very nice (and safe) string functions. And it allows the safe use of the __attribute__-feature of gcc. Best Martin

4 8

latest beta goes into an eternal error loop
by Taco Hoekwater 15 Aug '06

15 Aug '06

Hi, I've found a problem in the latest beta. Previous versions of pdftex would crash (segfault) on this input: {\pdfoutput=1 \immediate \pdfobj stream {}}Hello\bye The latest beta gives a nice "you can't change \pdfoutput" error, but it keeps on repeating that error message until the harddisk is full :-( Taco

5 13

[ pdftex-Patches-474 ] Use dynamically linked poppler library instead of xpdf code
by noreply＠sarovar.org 14 Aug '06

14 Aug '06

Patches item #474, was opened at 2006-01-30 17:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Postponed Priority: 5 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Use dynamically linked poppler library instead of xpdf code Initial Comment: This has already been applied and tested in Debian and Ubuntu, but we suggest to apply it upstream. There are a few things to do, however, as Martin already pointed out to me in a private mail. I paraphrase the main points: - the pdftex distribution should not ship libpoppler. Instead it should be possible to switch from xpdf to libpoppler using autoconf magic, if libpoppler headers are installed. This needs some coding work - We need a common API for xpdf and poppler. This is the tricky part, because the very reason for poppler's existence is that the xpdf developer, Derek Noonburg, refuses any patches that would lead to a shared library. As Martin said, "for the beginning, a header file with a couple of #ifdef'ed definitions should be enough". I'm going to subscribe to the pdftex devel list soon, but am not yet subscribed currently. ---------------------------------------------------------------------- >Comment By: Frank Küster (frank) Date: 2006-08-14 21:20 Message: Logged In: YES user_id=3360 Hi Martin, this is clearly post-1.40, I agree. I have not worked on any autofoo stuff, and I won't be able to do that soon (instead, I try to integrate pdftex-1.40 into teTeX 3.0 which proved to be non-trivial). Regards, Frank ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-13 22:02 Message: Logged In: YES user_id=421 Frank, have you done any further work on this? I just had a first look at integrating poppler and see a very different use of configure... :-{ Also your diff only patches the sources, but not the autofoo-stuff. What I want is: - a distribution of poppler in src/libs, which can be used instead of xpdf - a way to switch bewteen xpdf and poppler via configure - for poppler to be able to switch between static and dynamic via configure - and finally, a header file abstracting poppler/xpdf would be nice, but is not really needed, as poppler/xpdf are only used by two source files. Best Martin ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-02-13 08:58 Message: Logged In: YES user_id=3360 I agree that this is something to think over and check very well, so better not push it into 1.40. But I'd appreciate if someone could answer my mail to ntg-pdftex regarding the autoconf setup in pdftex, or if you could tell me whom to ask specifically if nobody among the active developers knows about it. See you in Berlin, Frank ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:50 Message: Logged In: YES user_id=421 I've attached the patch by Frank from http://www.ntg.nl/pipermail/ntg-pdftex/2006-February/001993.html ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:46 Message: Logged In: YES user_id=421 This is too late for 1.40, so I'll postpone it. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106

1 0

[ pdftex-Patches-474 ] Use dynamically linked poppler library instead of xpdf code
by noreply＠sarovar.org 13 Aug '06

13 Aug '06

Patches item #474, was opened at 2006-01-30 17:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Postponed Priority: 5 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Use dynamically linked poppler library instead of xpdf code Initial Comment: This has already been applied and tested in Debian and Ubuntu, but we suggest to apply it upstream. There are a few things to do, however, as Martin already pointed out to me in a private mail. I paraphrase the main points: - the pdftex distribution should not ship libpoppler. Instead it should be possible to switch from xpdf to libpoppler using autoconf magic, if libpoppler headers are installed. This needs some coding work - We need a common API for xpdf and poppler. This is the tricky part, because the very reason for poppler's existence is that the xpdf developer, Derek Noonburg, refuses any patches that would lead to a shared library. As Martin said, "for the beginning, a header file with a couple of #ifdef'ed definitions should be enough". I'm going to subscribe to the pdftex devel list soon, but am not yet subscribed currently. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-08-13 22:02 Message: Logged In: YES user_id=421 Frank, have you done any further work on this? I just had a first look at integrating poppler and see a very different use of configure... :-{ Also your diff only patches the sources, but not the autofoo-stuff. What I want is: - a distribution of poppler in src/libs, which can be used instead of xpdf - a way to switch bewteen xpdf and poppler via configure - for poppler to be able to switch between static and dynamic via configure - and finally, a header file abstracting poppler/xpdf would be nice, but is not really needed, as poppler/xpdf are only used by two source files. Best Martin ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-02-13 08:58 Message: Logged In: YES user_id=3360 I agree that this is something to think over and check very well, so better not push it into 1.40. But I'd appreciate if someone could answer my mail to ntg-pdftex regarding the autoconf setup in pdftex, or if you could tell me whom to ask specifically if nobody among the active developers knows about it. See you in Berlin, Frank ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:50 Message: Logged In: YES user_id=421 I've attached the patch by Frank from http://www.ntg.nl/pipermail/ntg-pdftex/2006-February/001993.html ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:46 Message: Logged In: YES user_id=421 This is too late for 1.40, so I'll postpone it. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106

1 0

Re: [NTG-pdftex] [XeTeX] OT?: Interesting? post about LuaTeX on usenet:comp.text.tex
by Hans Hagen 10 Aug '06

10 Aug '06

William Adams wrote: > On Aug 10, 2006, at 11:36 AM, Musa Furber wrote: > > >> Does LuaTeX today run on more than XeTeX's three platforms well >> enough to be used for production work? >> > > Given that, ``This Project Hs Not Released Any Files'', no. > Presumably it will run on all platforms which pdftex is available for. > i have no time for much discussion now: (and i don't read or wanna read usenet tex lists) - luatex started as an experiment en was presented/discussed at a couple of tex conferences; - it's done by a subset of the pdftex dev team and so it's 's an experimental branch of pdftex - the first major release will be called metatex which will then be the dev version - next year (or so) the first releases show up - in the end, the stabel releas will become pdftex 2.0 with pdftex < 2 being frozen in terms of extensions (not in terms of fixes) - it runs on all platforms (since there is a major overhaul being done now, it does not run anywhere -) - new functionality as well as compatibility issues will be tested in the oriental tex project (will be presented at tug 2006) > I thought the commenting on XeTeX was kind of strange and off-key, > hence my mention of it here. > i dunno about that; the luatex people know about xetex and jonathan knows about luatex; metatex will merge pdftex, implement pending ideas in the pdftex team, parts of aleph, lua scripting, open type, unicode, more math stuff, and probably runtime metapost support + a bit more); while xetex uses libraries, metatex will use methods built into tex (more complex from the perspective of most user but probably also more suiting demands of others) the development is mostly done by taco hoekwater as part of the oriental tex project; since pdftex is the de facto tex engine on tex live, the team deliberately keeps a low profile - no false promisses (on the schedule), priority on pdftex bug fixes, etc etc. when, how and if those projects will ever merge into one tex ... we'll see (neither of us sees a reason to cripple the xetex and/or pdftex dev by yet another development and it's fun to have two fresh tex's around - both following a slightly different approach andmaybe a different audience but both usable) side note: there is no competition with any other branch of tex (xetex, omega 2, ...) involved, just evolution of pdftex also, some parts of this spin off can be retrofitted into xetex (and vise versa) which is good for shared macro development Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

1 0

[ pdftex-Bugs-594 ] PDF picture with Type3 fonts causes unkown XObject "R8"
by noreply＠sarovar.org 09 Aug '06

09 Aug '06

Bugs item #594, was opened at 2006-08-09 11:11 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=594&group_id=106 Category: PDF inclusion Group: v1.30.0 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Martin Schröder (oneiros) >Summary: PDF picture with Type3 fonts causes unkown XObject "R8" Initial Comment: Please have a look at the attached minimal file. It just includes a PDF with LaTeX's \includegraphics. The result is an illegal PDF accoursing to acroread and Ghostscript. acroread speaks on an unknown XObject called "R8" (I also saw R10 in another case). The reason is probably the Type3 fonts used in the PDF graphics. If I use Type1, everything is fine. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-08-09 19:30 Message: Logged In: YES user_id=421 It's not a pdfTeX problem. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-08-09 18:58 Message: Logged In: YES user_id=929 that's a flaw in Adobe Reader 7.0, which doesn't follow the PDF specification strictly enough. Ghostscript people changed gs to adapt to this, see Ghostscript Bug #688357: http://bugs.ghostscript.com/show_bug.cgi?id=688357 pdftex can't do anything about this. When you generate the graphics by epstopdf using gs 8.54, everything should be ok. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=594&group_id=106

1 0

[ pdftex-Bugs-595 ] PDF picture with Type3 fonts causes unkown XObject "R8"
by noreply＠sarovar.org 09 Aug '06

09 Aug '06

Bugs item #595, was opened at 2006-08-09 11:11 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=595&group_id=106 Category: PDF inclusion Group: v1.30.0 >Status: Deleted Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Martin Schröder (oneiros) >Summary: PDF picture with Type3 fonts causes unkown XObject "R8" Initial Comment: Please have a look at the attached minimal file. It just includes a PDF with LaTeX's \includegraphics. The result is an illegal PDF accoursing to acroread and Ghostscript. acroread speaks on an unknown XObject called "R8" (I also saw R10 in another case). The reason is probably the Type3 fonts used in the PDF graphics. If I use Type1, everything is fine. ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-08-09 18:59 Message: Logged In: YES user_id=929 duplicate of bug report #594, see there Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=595&group_id=106

1 0

[ pdftex-Bugs-594 ] PDF picture with Type3 fonts causes unkown XObject "R8"
by noreply＠sarovar.org 09 Aug '06

09 Aug '06

Bugs item #594, was opened at 2006-08-09 11:11 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=594&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Martin Schröder (oneiros) >Summary: PDF picture with Type3 fonts causes unkown XObject "R8" Initial Comment: Please have a look at the attached minimal file. It just includes a PDF with LaTeX's \includegraphics. The result is an illegal PDF accoursing to acroread and Ghostscript. acroread speaks on an unknown XObject called "R8" (I also saw R10 in another case). The reason is probably the Type3 fonts used in the PDF graphics. If I use Type1, everything is fine. ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-08-09 18:58 Message: Logged In: YES user_id=929 that's a flaw in Adobe Reader 7.0, which doesn't follow the PDF specification strictly enough. Ghostscript people changed gs to adapt to this, see Ghostscript Bug #688357: http://bugs.ghostscript.com/show_bug.cgi?id=688357 pdftex can't do anything about this. When you generate the graphics by epstopdf using gs 8.54, everything should be ok. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=594&group_id=106

1 0

[ pdftex-Bugs-595 ] PDF picture with Type3 fonts causes unkown XObject "R8"
by noreply＠sarovar.org 09 Aug '06

09 Aug '06

Bugs item #595, was opened at 2006-08-09 11:11 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=595&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Martin Schröder (oneiros) Summary: PDF picture with Type3 fonts causes unkown XObject "R8" Initial Comment: Please have a look at the attached minimal file. It just includes a PDF with LaTeX's \includegraphics. The result is an illegal PDF accoursing to acroread and Ghostscript. acroread speaks on an unknown XObject called "R8" (I also saw R10 in another case). The reason is probably the Type3 fonts used in the PDF graphics. If I use Type1, everything is fine. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=595&group_id=106

1 0

[ pdftex-Bugs-594 ] PDF picture with Type3 fonts causes unkown XObject "R8"
by noreply＠sarovar.org 09 Aug '06

09 Aug '06

Bugs item #594, was opened at 2006-08-09 11:11 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=594&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Martin Schröder (oneiros) Summary: PDF picture with Type3 fonts causes unkown XObject "R8" Initial Comment: Please have a look at the attached minimal file. It just includes a PDF with LaTeX's \includegraphics. The result is an illegal PDF accoursing to acroread and Ghostscript. acroread speaks on an unknown XObject called "R8" (I also saw R10 in another case). The reason is probably the Type3 fonts used in the PDF graphics. If I use Type1, everything is fine. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=594&group_id=106

1 0