- ntg-pdftex - NTG Mailing Lists

[pdftex] New document - tcuythga
by noreply＠sarovar.org 02 Jul '09

02 Jul '09

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

1 0

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

01 Jul '09

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

1 0

[pdftex-Bugs][4292] \rightmarginkern doesn't work for last lines
by pdftex-bugs＠sarovar.org 30 Jun '09

30 Jun '09

Bugs item #4292, was opened at 2009-06-27 21:11 Status: Open Priority: 3 Submitted By: Robert (schlcht) >Assigned to: The Thanh Han (hanthethanh) Summary: \rightmarginkern doesn't work for last lines Category: hz Group: None >Resolution: Accepted Initial Comment: % Protrusion works fine even for the last line of a paragraph. % If, however, you ask \rightmarginkern, it will always report % zero margin kerning. \pdfprotrudechars2 \rpcode\font`\. 200 \parindent0pt \parfillskip=0pt \hsize50pt \tracingoutput1 \showboxbreadth\maxdimen \showboxdepth\maxdimen correct: \setbox0\vbox{AAA AAA. AAA AAA.} \unvcopy0 wrong: \newbox\splitbox \newdimen\rmarg \loop\ifvbox0 \setbox\splitbox\vsplit0 to\baselineskip \unvbox\splitbox\setbox\splitbox=\lastbox \rmarg\rightmarginkern\splitbox \unhbox\splitbox\kern\rmarg\rlap{ : \the\rmarg} \repeat \bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-06-30 09:26 Message: yes I confirm this is a bug that should be fixed. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4292&group_id=106

1 0

[pdftex-Feature Requests][743] Fake beginning/end of line for protrusion
by pdftex-featurerequests＠sarovar.org 27 Jun '09

27 Jun '09

Feature Requests item #743, was opened at 2007-03-06 02:20 Status: Open Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Fake beginning/end of line for protrusion Category: HZ Group: v1.50 Resolution: Accepted Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2009-06-27 21:14 Message: Any news with this feature request? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-07 09:52 Message: Logged In: YES user_id=710 yes inserting a whatsit node that would be changed to a kern seems the easiest way. I will give a try soon. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-03-06 17:21 Message: Logged In: YES user_id=2217 Maybe new (whatsit) nodes that can be caught in find_protchar_left/right? microtype is quite good in translating characters into slots (\MT@get@slot), but not really good enough to always allow natural input, e.g., ligatures and things like "` (German babel) won't be recognised. So my current workaround is: \def\protcharleft#1{% {\everypar{}% \setbox0\vbox{\noindent#1}% \vbadness=10000 \splittopskip=0pt \global\setbox0=\vsplit0 to \baselineskip \unvbox0 \global\setbox0=\lastbox}% \ifhbox0 \leavevmode \kern\leftmarginkern0 \fi #1} But this doesn't always work, e.g. in tabulars. Ligatures and other stuff still have to be enclosed in braces. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-03-06 08:00 Message: Logged In: YES user_id=1608 I will be experimenting with Aleph's \localleftbox somewhere next month, that may be a starting point. But it is unlikely that any command based on that will be able to influence line breaking. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-06 07:52 Message: Logged In: YES user_id=710 yes it makes sense. I am not sure whether \protcharleft could be implemented as macro: one can fetch the next char, get the lpcode and do a corresponding kern. However I don't know how to convert a character to its charcode to fetch the relevant lpcode. Another problem is that if the next char is part of a ligature (as in your example), it doesn't work. Looks like a primitive is needed. Does anyone have a suggestion how it could be implemented? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

[pdftex-Bugs][4292] \rightmarginkern doesn't work for last lines
by pdftex-bugs＠sarovar.org 27 Jun '09

27 Jun '09

Bugs item #4292, was opened at 2009-06-27 21:11 Status: Open Priority: 3 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: \rightmarginkern doesn't work for last lines Category: hz Group: None Resolution: None Initial Comment: % Protrusion works fine even for the last line of a paragraph. % If, however, you ask \rightmarginkern, it will always report % zero margin kerning. \pdfprotrudechars2 \rpcode\font`\. 200 \parindent0pt \parfillskip=0pt \hsize50pt \tracingoutput1 \showboxbreadth\maxdimen \showboxdepth\maxdimen correct: \setbox0\vbox{AAA AAA. AAA AAA.} \unvcopy0 wrong: \newbox\splitbox \newdimen\rmarg \loop\ifvbox0 \setbox\splitbox\vsplit0 to\baselineskip \unvbox\splitbox\setbox\splitbox=\lastbox \rmarg\rightmarginkern\splitbox \unhbox\splitbox\kern\rmarg\rlap{ : \the\rmarg} \repeat \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4292&group_id=106

1 0

[pdftex-Bugs][4291] \pdfgentounicode conflicts with cmap+\pdffontattr
by pdftex-bugs＠sarovar.org 27 Jun '09

27 Jun '09

Bugs item #4291, was opened at 2009-06-26 22:37 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: \pdfgentounicode conflicts with cmap+\pdffontattr Category: None Group: None Resolution: None Initial Comment: from https://www.tug.org/pipermail/tex-live/2007-October/014986.html > I think there are unsolved issues. Now there are two methods > for adding CMaps: > (a) \pdffontattr, package cmap > (b) \pdfgentounicode, glyphtounicode.tex > > Both methods have its limitations, e.g. (b) only works for Type 1 > fonts. Thus you could need both methods to cover all fonts, but the > methods doesn't know each other, thus fonts can end up with two CMap > tables. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4291&group_id=106

1 0

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

26 Jun '09

Bugs item #4290, was opened at 2009-06-26 17:55 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: processing speed: pdftex slows down when processes long files in DVI mode Category: None Group: None Resolution: None Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-May/003786.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4290&group_id=106

1 0

Re: [NTG-pdftex] Bug#532074: texlive-base-bin: 'man pdftex': missing .ds WB
by Frank Küster 14 Jun '09

14 Jun '09

Dear pdftex developers, Török Edwin <edwintorok(a)gmail.com> wrote: > 'man pdftex' shows at the bottom: > "that generated by the to C system (web2c), originally written by" > > There is a missing word after 'the': 'Web', the manpage source has: > 'by the \*(WB to'. But there is no .ds WB at the top of the manpage. > > The fix would be to copy the definition of WB from another manpage, for example > pltotf: > .if n .ds WB Web > .if t .ds WB W\s-2EB\s0 In current TeXLive svn, the patch would be the following. Index: pdftex.man =================================================================== --- pdftex.man (revision 13610) +++ pdftex.man (working copy) @@ -19,6 +19,8 @@ .if n .ds AX AmSTeX .if t .ds AY \fRA\\h'-0.1667m'\\v'0.20v'M\\v'-0.20v'\\h'-0.125m'S\fP\*(LX .if n .ds AY AmSLaTeX +.if n .ds WB Web +.if t .ds WB W\s-2EB\s0 .\"===================================================================== .SH NAME pdftex, pdfinitex, pdfvirtex \- PDF output from TeX We would be happy if you could apply the patch. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg

2 1

processing speed
by Reinhard Kotucha 30 May '09

30 May '09

Hi, did anybody observe already that pdftex gets slower and slower when processing huge documents? I recently wrote a few perl scripts which create huge LaTeX files containing data from spectrum analyzers and I'm using the pgfplots package in order to visualize the results. On my humble Windows machine it takes about one second to create such a plot. This is ok even if I have to create thousands of them. But now I have to create thousands of them, and I noticed that the amount of time needed to produce one single plot is increasing steadily. I first thought that it's a pgfplots issue but I created test files which confirm that it's a pdftex problem. Download the tiny Perl script http://tug.org/~kotucha/mktestfiles.gz and then try: tex --shell-escape testplain.tex and pdftex --shell-escape testplain.tex What you'll see on screen is the output of "date +%s" whenever the \input file had been processed. (Thus, it works only on UNIX). You'll see that at the beginning Knuth's TeX and pdfTeX need approximately the same amount of time to process one \input file. But while Knuth's TeX needs the same amount of time to process any \input file, the amount of time pdfTeX needs increases steadily. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

6 25

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

21 May '09

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

1 0