- 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

[ pdftex-Bugs-592 ] TrueType Font can't be embedded
by noreply＠sarovar.org 09 Aug '06

09 Aug '06

Bugs item #592, was opened at 2006-08-08 13:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106 Category: Fonts Group: v1.30.0 Status: Open Resolution: Fixed Priority: 5 Submitted By: Michael (takrl) Assigned to: Nobody (None) Summary: TrueType Font can't be embedded Initial Comment: I tried to embed a TTF in my PDF document (have done so before 100s of times, so I know the general proceedings). However, this is a new MS font (constantia), and pdf(e)tex doesn't seem to support it. Excerpt of the log file: This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5) entering extended mode <snip> [1{psfonts.map}] (ttftest.aux) ) (see the transcript file for additional information){T1-WGL4.enc}<constani.ttf Error: (file constani.ttf): unknown verssion of OS/2 table (0003) ==> Fatal error occurred, the output PDF file is not finished! >From what I saw so far on the net (for example, at http://partners.adobe.com/public/developer/opentype/index_os2.html ) this is the newest version of the font specification, and pdf(e)tex does only seem to support fonts using OS/2-table-versions lower than 3. ---------------------------------------------------------------------- >Comment By: Michael (takrl) Date: 2006-08-09 11:03 Message: Logged In: YES user_id=3803 Ok, I just made up a zip file containing test data and attached it here... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-08 13:50 Message: Logged In: YES user_id=421 I've changed that line to if (version > 3) Michael, can you please attach a complete test case (all needed inputs) to this bug report for future testing? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-08-08 13:17 Message: Logged In: YES user_id=710 >From an email from Eddie Kohler: ================================================= (2) Otftotfm generates map lines that tell pdftex to embed the TTF directly (cool!). Unfortunately, pdftex does not like the Version 3.0 OS/2 table included in OpenType TTFs (boo!), so I hacked the font to change the OS/2 version number to 2.0. Alternately, one could recompile pdftex, after changing line 1026 of writettf.c to: if (version != 0x0000 && version != 0x0001 && version != 0x0002 && version != 0x0003) ================================================= Martin, can you please include this patch into the next release? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106

1 0

[ pdftex-Bugs-592 ] TrueType Font can't be embedded
by noreply＠sarovar.org 08 Aug '06

08 Aug '06

Bugs item #592, was opened at 2006-08-08 13:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106 Category: Fonts Group: v1.30.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Michael (takrl) Assigned to: Nobody (None) Summary: TrueType Font can't be embedded Initial Comment: I tried to embed a TTF in my PDF document (have done so before 100s of times, so I know the general proceedings). However, this is a new MS font (constantia), and pdf(e)tex doesn't seem to support it. Excerpt of the log file: This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5) entering extended mode <snip> [1{psfonts.map}] (ttftest.aux) ) (see the transcript file for additional information){T1-WGL4.enc}<constani.ttf Error: (file constani.ttf): unknown verssion of OS/2 table (0003) ==> Fatal error occurred, the output PDF file is not finished! >From what I saw so far on the net (for example, at http://partners.adobe.com/public/developer/opentype/index_os2.html ) this is the newest version of the font specification, and pdf(e)tex does only seem to support fonts using OS/2-table-versions lower than 3. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-08-08 13:50 Message: Logged In: YES user_id=421 I've changed that line to if (version > 3) Michael, can you please attach a complete test case (all needed inputs) to this bug report for future testing? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-08-08 13:17 Message: Logged In: YES user_id=710 >From an email from Eddie Kohler: ================================================= (2) Otftotfm generates map lines that tell pdftex to embed the TTF directly (cool!). Unfortunately, pdftex does not like the Version 3.0 OS/2 table included in OpenType TTFs (boo!), so I hacked the font to change the OS/2 version number to 2.0. Alternately, one could recompile pdftex, after changing line 1026 of writettf.c to: if (version != 0x0000 && version != 0x0001 && version != 0x0002 && version != 0x0003) ================================================= Martin, can you please include this patch into the next release? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106

1 0

[ pdftex-Bugs-592 ] TrueType Font can't be embedded
by noreply＠sarovar.org 08 Aug '06

08 Aug '06

Bugs item #592, was opened at 2006-08-08 11:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106 Category: Fonts Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Michael (takrl) Assigned to: Nobody (None) Summary: TrueType Font can't be embedded Initial Comment: I tried to embed a TTF in my PDF document (have done so before 100s of times, so I know the general proceedings). However, this is a new MS font (constantia), and pdf(e)tex doesn't seem to support it. Excerpt of the log file: This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5) entering extended mode <snip> [1{psfonts.map}] (ttftest.aux) ) (see the transcript file for additional information){T1-WGL4.enc}<constani.ttf Error: (file constani.ttf): unknown verssion of OS/2 table (0003) ==> Fatal error occurred, the output PDF file is not finished! >From what I saw so far on the net (for example, at http://partners.adobe.com/public/developer/opentype/index_os2.html ) this is the newest version of the font specification, and pdf(e)tex does only seem to support fonts using OS/2-table-versions lower than 3. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-08-08 11:17 Message: Logged In: YES user_id=710 >From an email from Eddie Kohler: ================================================= (2) Otftotfm generates map lines that tell pdftex to embed the TTF directly (cool!). Unfortunately, pdftex does not like the Version 3.0 OS/2 table included in OpenType TTFs (boo!), so I hacked the font to change the OS/2 version number to 2.0. Alternately, one could recompile pdftex, after changing line 1026 of writettf.c to: if (version != 0x0000 && version != 0x0001 && version != 0x0002 && version != 0x0003) ================================================= Martin, can you please include this patch into the next release? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106

1 0

[ pdftex-Bugs-592 ] TrueType Font can't be embedded
by noreply＠sarovar.org 08 Aug '06

08 Aug '06

Bugs item #592, was opened at 2006-08-08 13:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106 Category: Fonts Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Michael (takrl) >Assigned to: Nobody (None) Summary: TrueType Font can't be embedded Initial Comment: I tried to embed a TTF in my PDF document (have done so before 100s of times, so I know the general proceedings). However, this is a new MS font (constantia), and pdf(e)tex doesn't seem to support it. Excerpt of the log file: This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5) entering extended mode <snip> [1{psfonts.map}] (ttftest.aux) ) (see the transcript file for additional information){T1-WGL4.enc}<constani.ttf Error: (file constani.ttf): unknown verssion of OS/2 table (0003) ==> Fatal error occurred, the output PDF file is not finished! >From what I saw so far on the net (for example, at http://partners.adobe.com/public/developer/opentype/index_os2.html ) this is the newest version of the font specification, and pdf(e)tex does only seem to support fonts using OS/2-table-versions lower than 3. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106

1 0

[ pdftex-Bugs-592 ] TrueType Font can't be embedded
by noreply＠sarovar.org 08 Aug '06

08 Aug '06

Bugs item #592, was opened at 2006-08-08 13:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106 Category: Fonts Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Michael (takrl) Assigned to: Hartmut Henkel (hhenkel) Summary: TrueType Font can't be embedded Initial Comment: I tried to embed a TTF in my PDF document (have done so before 100s of times, so I know the general proceedings). However, this is a new MS font (constantia), and pdf(e)tex doesn't seem to support it. Excerpt of the log file: This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5) entering extended mode <snip> [1{psfonts.map}] (ttftest.aux) ) (see the transcript file for additional information){T1-WGL4.enc}<constani.ttf Error: (file constani.ttf): unknown verssion of OS/2 table (0003) ==> Fatal error occurred, the output PDF file is not finished! >From what I saw so far on the net (for example, at http://partners.adobe.com/public/developer/opentype/index_os2.html ) this is the newest version of the font specification, and pdf(e)tex does only seem to support fonts using OS/2-table-versions lower than 3. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106

1 0

LuaTeX schedule
by Reinhard Kotucha 28 Jul '06

28 Jul '06

Hi, any idea when LuaTeX will be released? AFAIK it is somewhere near the top on Taco's TODO list. TeXLive-2005 had been frozen end of October. Because Karl spent so much time to move from p4 to svn I don't expect that TL-2006 can be released earlier. Is it likely that we have LuaTeX in TL-2006? Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

3 2

[ pdftex-Bugs-577 ] Type 3 fonts: on screen fine, on paper filled and displaced
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #577, was opened at 2006-06-28 13:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106 Category: Fonts Group: v1.30.0 >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Peter Dyballa (ballapete) Assigned to: Hartmut Henkel (hhenkel) Summary: Type 3 fonts: on screen fine, on paper filled and displaced Initial Comment: Hello! It's pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5), on Mac OS X 10.4.6, PPC. The Type 3 font is dijkstra, a famous person's handwriting, as distributed by many SunOS and Solaris versions. Until mid May I had no problem with pdfTeX, dijkstra, and my EPSON EPL-5800 (PostScript 3). This week I again wanted to print a personal letter with Prof. Dijkstra's handwriting used for my letter head. And some letters were filled (P,e,9), others were horizontally and/or vertically displaced from their correct positions. Dijkstra was installed with fontinst. Can this be a pdfTeX problem? End of May I added almost 1 GB of files to update SDKs etc. in Mac OS X to be able to produce Universal Binaries. The last few Tiger versions are known as a bit buggy. My last TeX binaries updates happened in the middle of May, but I have no LOG files from this. The recent LOGs from making the format files contain the string above ... Greetings Pete ---------------------------------------------------------------------- Comment By: Peter Dyballa (ballapete) Date: 2006-07-26 15:25 Message: Logged In: YES user_id=2303 *I* am terribly sorry! Examining again my printer drivers upon your findings I now found that the PS3<version number> part of its name was removed! So I had some filter that converted PS or PDF into raster that was sent via ESP/P or such to the printer? I found the right PPD file in the right place and re-installed this as my printer -- and it prints again. (Although it puzzles me why I could print the PDF output from XeTeX! This worked all the last weeks.) Probably *I* was choosing the wrong items in the printer configuration dialog! Sorry for this! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-24 23:46 Message: Logged In: YES user_id=421 [Sorry for not reacting earlier, but gforge sends no mail when a file is attached; you also have to add a comment.] The attached file uses a Type 1 font and prints perfectly on an Lexmark Optra T612 (which has a PS3 RIP)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-06-28 16:09 Message: Logged In: YES user_id=421 Please provide a pdf showing the problems (attach it to this bug). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106

1 0

[ pdftex-Bugs-577 ] Type 3 fonts: on screen fine, on paper filled and displaced
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #577, was opened at 2006-06-28 13:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106 Category: Fonts Group: v1.30.0 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Peter Dyballa (ballapete) Assigned to: Hartmut Henkel (hhenkel) Summary: Type 3 fonts: on screen fine, on paper filled and displaced Initial Comment: Hello! It's pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5), on Mac OS X 10.4.6, PPC. The Type 3 font is dijkstra, a famous person's handwriting, as distributed by many SunOS and Solaris versions. Until mid May I had no problem with pdfTeX, dijkstra, and my EPSON EPL-5800 (PostScript 3). This week I again wanted to print a personal letter with Prof. Dijkstra's handwriting used for my letter head. And some letters were filled (P,e,9), others were horizontally and/or vertically displaced from their correct positions. Dijkstra was installed with fontinst. Can this be a pdfTeX problem? End of May I added almost 1 GB of files to update SDKs etc. in Mac OS X to be able to produce Universal Binaries. The last few Tiger versions are known as a bit buggy. My last TeX binaries updates happened in the middle of May, but I have no LOG files from this. The recent LOGs from making the format files contain the string above ... Greetings Pete ---------------------------------------------------------------------- >Comment By: Peter Dyballa (ballapete) Date: 2006-07-26 15:25 Message: Logged In: YES user_id=2303 *I* am terribly sorry! Examining again my printer drivers upon your findings I now found that the PS3<version number> part of its name was removed! So I had some filter that converted PS or PDF into raster that was sent via ESP/P or such to the printer? I found the right PPD file in the right place and re-installed this as my printer -- and it prints again. (Although it puzzles me why I could print the PDF output from XeTeX! This worked all the last weeks.) Probably *I* was choosing the wrong items in the printer configuration dialog! Sorry for this! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-24 23:46 Message: Logged In: YES user_id=421 [Sorry for not reacting earlier, but gforge sends no mail when a file is attached; you also have to add a comment.] The attached file uses a Type 1 font and prints perfectly on an Lexmark Optra T612 (which has a PS3 RIP)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-06-28 16:09 Message: Logged In: YES user_id=421 Please provide a pdf showing the problems (attach it to this bug). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106

1 0

[ pdftex-Bugs-548 ] Forwarded problem with Test.jpg
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #548, was opened at 2006-05-10 18:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=548&group_id=106 Category: Image inclusion Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Forwarded problem with Test.jpg Initial Comment: Hello, in de.comp.text.tex Simon Eugster has problems with a jpg file: http://livingshadow.uttx.net/uploads/Test.jpg (Message-ID: <1147112925.079314.323190(a)v46g2000cwv.googlegroups.com>) I don't have a JPEG validator, but mozilla/firefox/ImageMagick/xzgv/file don't show any sign of problems with the JPEG file. Also I could reproduce his problems with pdfTeX 1.40.0-beta-20060213: \pdfximage{Test.jpg} | Error: pdftex (file ./Test.jpg): reading JPEG image failed | ==> Fatal error occurred, no output PDF file produced! Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 14:54 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-05-10 21:50 Message: Logged In: YES user_id=929 The test for JFIF file format was not adequate. Please test the patch. Bear in mind that currently only JFIF files allow to extract the image resolution values. For all others either explicitly give the wished dimensions (usual way), or set \pdfimageresolution. Else you get some default resolution. The problem went away also after treating Test.jpg (which is an EXIF file) by jhead -de, as this removed all EXIF headers. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=548&group_id=106

1 0

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #555, was opened at 2006-05-20 16:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 Category: hz Group: v1.30.0 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Dag Leine (dag) Assigned to: Taco Hoekwater (taco) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 14:52 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-07-26 14:08 Message: Logged In: YES user_id=1608 FWIW, I looked at it and agree with Hartmut. --- pdftex.web.orig 2006-07-25 20:22:54.000000000 +0200 +++ pdftex.web 2006-07-26 14:19:35.514413422 +0200 @@ -24600,9 +24600,9 @@ p := q; ptmp := p; end else begin - p := prev_rightmost(temp_head, q); {get |link(p) = q|} + p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} ptmp := p; - p := find_protchar_right(temp_head, p); + p := find_protchar_right(link(temp_head), p); end; @{ short_display_n(p, 1); ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-26 00:04 Message: Logged In: YES user_id=929 the value of temp_head seems to be right, but maybe it must be p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} p := find_protchar_right(link(temp_head), p); with link(temp_head) instead of temp_head, as "The current line to be justified appears in a horizontal list starting at |link(temp_head)| and ending at |cur_break(cur_p)|." wild guess only, seems to work. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-25 23:33 Message: Logged In: YES user_id=929 seems it happens at this line in pdftex.web: p := prev_rightmost(temp_head, q); {get |link(p) = q|} the temp_head before this call is 1499996 which seems to be wrong. Then after the call p = 1499996, and there is font f=-4096 attached to this node which is also wrong. So it seems that somehow temp_head got lost before call of prev_rightmost(). No clue how. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-07-25 23:06 Message: Logged In: YES user_id=1608 ok, will check tomorrow ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 21:30 Message: Logged In: YES user_id=421 This still happens with the latest beta (I've got an OpenBSD machine now myself): Program received signal SIGSEGV, Segmentation fault. 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; (gdb) bt #0 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 #1 0x1c053d53 in zpostlinebreak (d=1) at pdftex2.c:7715 #2 0x1c007659 in zlinebreak (d=1) at pdftexini.c:2136 #3 0x1c05bb11 in initmath () at pdftex3.c:141 #4 0x1c065091 in maincontrol () at pdftex3.c:4582 #5 0x1c0130a2 in mainbody () at pdftexini.c:5647 #6 0x1c069d9e in main (ac=2, av=0xcfbd239c) at pdftexextra.c:340 (gdb) l pdftex2.c:3191 3186 c = getlpcode ( f , mem [p ].hh.b1 ) ; 3187 lastleftmostchar = p ; 3188 } 3189 else { 3190 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; 3192 lastrightmostchar = p ; 3193 } 3194 if ( c == 0 ) 3195 return Result ; (gdb) p f $1 = -4096 (gdb) p p $2 = 999996 (gdb) p mem[p].hh $3 = {v = {LH = -268435455, RH = 675}, u = {B1 = 1, B0 = -4096}} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #555, was opened at 2006-05-20 16:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 Category: hz Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Dag Leine (dag) Assigned to: Taco Hoekwater (taco) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2006-07-26 14:08 Message: Logged In: YES user_id=1608 FWIW, I looked at it and agree with Hartmut. --- pdftex.web.orig 2006-07-25 20:22:54.000000000 +0200 +++ pdftex.web 2006-07-26 14:19:35.514413422 +0200 @@ -24600,9 +24600,9 @@ p := q; ptmp := p; end else begin - p := prev_rightmost(temp_head, q); {get |link(p) = q|} + p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} ptmp := p; - p := find_protchar_right(temp_head, p); + p := find_protchar_right(link(temp_head), p); end; @{ short_display_n(p, 1); ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-26 00:04 Message: Logged In: YES user_id=929 the value of temp_head seems to be right, but maybe it must be p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} p := find_protchar_right(link(temp_head), p); with link(temp_head) instead of temp_head, as "The current line to be justified appears in a horizontal list starting at |link(temp_head)| and ending at |cur_break(cur_p)|." wild guess only, seems to work. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-25 23:33 Message: Logged In: YES user_id=929 seems it happens at this line in pdftex.web: p := prev_rightmost(temp_head, q); {get |link(p) = q|} the temp_head before this call is 1499996 which seems to be wrong. Then after the call p = 1499996, and there is font f=-4096 attached to this node which is also wrong. So it seems that somehow temp_head got lost before call of prev_rightmost(). No clue how. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-07-25 23:06 Message: Logged In: YES user_id=1608 ok, will check tomorrow ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 21:30 Message: Logged In: YES user_id=421 This still happens with the latest beta (I've got an OpenBSD machine now myself): Program received signal SIGSEGV, Segmentation fault. 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; (gdb) bt #0 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 #1 0x1c053d53 in zpostlinebreak (d=1) at pdftex2.c:7715 #2 0x1c007659 in zlinebreak (d=1) at pdftexini.c:2136 #3 0x1c05bb11 in initmath () at pdftex3.c:141 #4 0x1c065091 in maincontrol () at pdftex3.c:4582 #5 0x1c0130a2 in mainbody () at pdftexini.c:5647 #6 0x1c069d9e in main (ac=2, av=0xcfbd239c) at pdftexextra.c:340 (gdb) l pdftex2.c:3191 3186 c = getlpcode ( f , mem [p ].hh.b1 ) ; 3187 lastleftmostchar = p ; 3188 } 3189 else { 3190 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; 3192 lastrightmostchar = p ; 3193 } 3194 if ( c == 0 ) 3195 return Result ; (gdb) p f $1 = -4096 (gdb) p p $2 = 999996 (gdb) p mem[p].hh $3 = {v = {LH = -268435455, RH = 675}, u = {B1 = 1, B0 = -4096}} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

[ pdftex-Patches-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #466, was opened at 2006-01-07 17:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106 Category: Primitives Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \primitive and \ifprimitive Initial Comment: This patch implements two new primitives: \primitive \par This will run the 'primitive' command \par, even if it has been re- or undefined in the meantime. \primitive is not expandable, because it may be asked to execute unexpandable primitives as well as expandable ones. If you supply a nonexistant primitive, it will be ignored (no error is raised). The second primitive is a new type of \if: \ifprimitive \par ... \else .. \fi returns true if the current meaning of \par is the 'primitive' command \par. The patch is against alpha-20051226, i hope that is not too old (?). I expect to do at least one minor update during the beta cycle, after the pdftex code is flattened. It was quite a struggle to make this change file work ok, and as a result, there are a few ugly web hacks. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 08:17 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-13 18:56 Message: Logged In: YES user_id=1608 We need to think about this. I see your point, but making \primitive expandable forces the introduction of un-redefinable tokens, and that has its own problematic side-effects (like slowing down each and every definition). I welcome third opinions on whether the benefits outweigh that downside. At one point I tried making the expandability depend on the referred primitive, but that gave me headaches at the implementation stage (a pity, because that would have been nice). Yet another solution is to have an expandable command as well as an unexpandable command (two primitives instead of just the single \primitive). On the side note: I will happily write an implementation ... but only if someone comes up with a specification that works under all conditions instead of only under specific programming styles :-) ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-13 17:40 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

2 1

[ pdftex-Patches-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #466, was opened at 2006-01-07 17:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106 Category: Primitives Group: v1.30.0 >Status: Open Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \primitive and \ifprimitive Initial Comment: This patch implements two new primitives: \primitive \par This will run the 'primitive' command \par, even if it has been re- or undefined in the meantime. \primitive is not expandable, because it may be asked to execute unexpandable primitives as well as expandable ones. If you supply a nonexistant primitive, it will be ignored (no error is raised). The second primitive is a new type of \if: \ifprimitive \par ... \else .. \fi returns true if the current meaning of \par is the 'primitive' command \par. The patch is against alpha-20051226, i hope that is not too old (?). I expect to do at least one minor update during the beta cycle, after the pdftex code is flattened. It was quite a struggle to make this change file work ok, and as a result, there are a few ugly web hacks. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 08:17 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-13 18:56 Message: Logged In: YES user_id=1608 We need to think about this. I see your point, but making \primitive expandable forces the introduction of un-redefinable tokens, and that has its own problematic side-effects (like slowing down each and every definition). I welcome third opinions on whether the benefits outweigh that downside. At one point I tried making the expandability depend on the referred primitive, but that gave me headaches at the implementation stage (a pity, because that would have been nice). Yet another solution is to have an expandable command as well as an unexpandable command (two primitives instead of just the single \primitive). On the side note: I will happily write an implementation ... but only if someone comes up with a specification that works under all conditions instead of only under specific programming styles :-) ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-13 17:40 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

1 0

[ pdftex-Patches-415 ] various extensions and fixes
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #415, was opened at 2005-08-19 09:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106 Category: Primitives Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: various extensions and fixes Initial Comment: This is a patch for various experimental extensions: - \pdfinsertht: return the height of an insert (requested by Hans); this has similar syntax to \pdftexrevision. - do not fail when \pdfobj is used with an invalid object number (requested by Hans) - snapping: support for grid typesetting -- see snap.txt for details - kern before space: allow changing interword glues in a flexible way and inserting a kern before certain characters -- see kern-before-interword-glue.txt for details The notes in snap.txt and kern-before-interword-glue.txt are from email correspondence with people interested in; hence these notes are somewhat informal, inaccurate or out-of-date. How to apply: ~~~~~~~~~~~~~ cd /path/to/pdftex-1.30.0-srcdir/src/texk patch -p1 < /path/to/pdftex-20050818.patch cd web2c make pdfetex ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:31 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-09-04 18:22 Message: Logged In: YES user_id=421 The patch for invalid object numbers is included in 1.30.1++ ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106

1 0

[ pdftex-Patches-432 ] Rules in a PDF qQ group
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #432, was opened at 2005-10-06 21:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106 Category: Positioning Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hans Hagen (hagen) Summary: Rules in a PDF qQ group Initial Comment: Put rules with their positioning on the page inside a qQ group. Should make \pdfliteral page {...} behave consistently after text or rules or images, as then any positioning starts from the PDF origin; no delta-positioning anymore. It's already being tested in pdfluatex. Just to have it at sarovar... Testing welcome, particularily with text and graphics transforms by graphicx package, to spot backward incompatibilities, if any... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:29 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:07 Message: Logged In: YES user_id=929 Update pdf_set_origin_temp: Now has (h, v) parameters. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106

1 0