- ntg-pdftex - NTG Mailing Lists

unbuffered vs. buffered terminal output
by Hartmut Henkel 23 Dec '05

23 Dec '05

following trivial observation i made (several runs): $ time pdfetex samplepdf real 0m2.536s real 0m2.605s real 0m2.737s real 0m2.654s $ time pdfetex samplepdf | buffer real 0m0.900s real 0m1.035s real 0m0.900s real 0m0.913s the speed gain is impressive here, also with other files from daily business and for longer runs. Same if i write $ pdfetex samplepdf > xxx So at least here pdfetex spends lots of time just for unbuffered talk to the terminal. And it's faster with a smaller window. Maybe we should think of implementing buffered writing? See e. g. man 3 setbuf. The problem is that it should fflush() in case of errors and switch to unbuffered. And maybe it should fflush() also after a certain time of say 0.5 s, which would require select(). Has anybody similar statistics? Regards, Hartmut

5 10

[NTG-pdftex] [ pdftex-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 22 Dec '05

22 Dec '05

Feature Requests item #87, was opened at 2004-07-02 11:13 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106 Category: None Group: v1.21 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) >Assigned to: Martin Schröder (oneiros) Summary: In case of fatal errors, delete the output file Initial Comment: When pdfTeX currently encounters a fatal error, it closes it's output file, which leads to incomplete/corrupt files. pdfTeX should produce only valid files, and in case of fatal errors the output should be deleted. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-12-19 00:38 Message: Logged In: YES user_id=421 The attached patch unlinks the current file, if a fatal error happens. Currently this is done without any checks, and may be a security problem. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 14:35 Message: Logged In: YES user_id=1608 When you truncate a file, the result is an empty file. From a user's viewpoint, that is not the same thing as a corrupt PDF. The distinction is small, but the advantage of an empty file is that it is not likely to be confused for a correct PDF. If it is possible, then deleting the PDF file is definately better, but file deletion doesn't always work. Truncation almost always does work, and it's only two syscalls extra, so why not? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-07-02 14:21 Message: Logged In: YES user_id=421 Simply truncating a pdf still makes it invalid (because the file structure is incomplete). Producing a valid truncated output file in case of fatal errors will be tricky and not always possible. Deleting the corrupt output is much easier. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 13:50 Message: Logged In: YES user_id=1608 If deleting the file doesnt work, truncation is probably still better than nothing. (?) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106

4 5

doc gaps
by Pawel Jackowski 21 Dec '05

21 Dec '05

Hi, three things, I suppose, already established in releases but not documented: -- regexp support -- string comparison -- `page' modifier for \pdfliteral Experimental? -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

5 5

Re: [NTG-pdftex] various features
by Akira Kakuto 20 Dec '05

20 Dec '05

> On 2005-12-19 14:16:49 +0100, Hans Hagen wrote: > > Are all Than's recent patches included? Like the \pdfprependkern and > > alike stuff? > > No. But I included all I got. > > Thanh? http://pdftex.sarovar.org/src/pdftex-20050924.patch.gz Please include the above patch by Thanh which defines \pdfprependkern etc. I'm personally using the subfont mechanism in the patch to typeset Japanese. The patch is for 1.30.3. So some hand work will be needed. Thanks, Akira

1 0

various features
by Hans Hagen 19 Dec '05

19 Dec '05

Hi, Are all Than's recent patches included? Like the \pdfprependkern and alike stuff? Hans

2 2

1.40.0-alpha-20051205
by Martin Schröder 13 Dec '05

13 Dec '05

http://sarovar.org/download.php/846/pdftex-1.40.0-alpha-20051205.tar.bz2 I've tried to intergrate as many patches as possible: - 386 grow obj_tab and dest_names arrays dynamically - 416 new primitive pdflastlink - 427 Character positioning patch - 432 Rules in a PDF qQ group - 434 Remove queued map item handling - 438 \pdfsavepos in DVI mode - 443 512 zeros in Type1 fonts not copied anymore - 447 Don't write /Encoding for non-reencoded fonts - 453 Object Streams for PDF-1.5 - take PK resolution from "pk_dpi" parameter in texmfmp.c, if it has not been set by the format file or by the user It's roughly tested: The manual still compiles. Best Martin -- http://www.tm.oneiros.de

7 12

pdftex-1.40.0-alpha-20051208
by Martin Schröder 09 Dec '05

09 Dec '05

http://sarovar.org/download.php/850/pdftex-1.40.0-alpha-20051205-20051208.d… http://sarovar.org/download.php/851/pdftex-1.40.0-alpha-20051208.tar.bz2 - improved patches: - 386 grow obj_tab and dest_names arrays dynamically - 453 Object Streams for PDF-1.5 - take PK resolution from "pk_dpi" parameter in texmf.cnf, if it has not been set by the format file or by the user - write out PDF statistics later to make them correct - makefile target pdfetex-all.pdf for a huge file Have fun Martin -- http://www.tm.oneiros.de

1 0

[ pdftex-Patches-416 ] new primitive pdflastlink
by noreply＠sarovar.org 06 Dec '05

06 Dec '05

Patches item #416, was opened at 2005-08-19 09:42 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106 Category: Primitives Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Utermann (ralfu) Assigned to: Nobody (None) Summary: new primitive pdflastlink Initial Comment: This patch implements a new primitive \pdflastlink (analogous to \pdflastannot) which returns the object number of the last object created with \pdfstartlink. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106

3 2

[ pdftex-Patches-415 ] various extensions and fixes
by noreply＠sarovar.org 05 Dec '05

05 Dec '05

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: Open Resolution: None 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: 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

3 2

[ pdftex-Feature Requests-454 ] distribution: rename Build script
by noreply＠sarovar.org 04 Dec '05

04 Dec '05

Feature Requests item #454, was opened at 2005-11-27 00:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=454&group_id=106 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) >Assigned to: Martin Schröder (oneiros) Summary: distribution: rename Build script Initial Comment: Here is a very, very minor nuisance: In order to compile pdftex on case-insensitive file systems like Windows, one always has to rename the Build script first, e.g., to Build.sh, since otherwise the directory build/ cannot be created. I would suggest to rename either the script or the build directory. Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-12-04 15:14 Message: Logged In: YES user_id=421 This has been fixed in 1.30.5 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=454&group_id=106

1 0