July 2009 - ntg-pdftex - NTG Mailing Lists

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

22 Jul '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-07-22 10:49 Message: here is a patch for pdftex stable. ---------------------------------------------------------------------- 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 22 Jul '09

22 Jul '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: The Thanh Han (hanthethanh) Date: 2009-07-22 09:14 Message: here is a patch for pdftex stable. Test file: \font\f=cmr10 \lpcode\f`\A=500 \f \hbox{ABC} \hbox{DEF} \setbox0=\hbox{\pdfprotcharleft ABC} \showbox0 \box0 \bye ---------------------------------------------------------------------- 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

Re: [NTG-pdftex] processing speed
by Reinhard Kotucha 03 Jul '09

03 Jul '09

On 1 July 2009 Jérome Laurens wrote: > Hahn found a bug in synctex, I fixed it and made the tests with the > stable branch of pdftex Hi Jérome, of course, if there had been a bug in synctex, it's good that it is fixed now. However, I doubt that synctex was responsible for the problem I reported. There must still be another problem. Isn't synctex very new technology? I could reproduce the problem with older versions of TeX Live. Please try: http://tug.org/~kotucha/testpgfplots.tex.gz I suppose that it's a better test file than the one I prepared first. What I've found out so far is that 1. the problem is not new, 2. luatex has the same problem, 3. the string pool is growing. Because I don't know what exactly causes the problem, I can't even provide a minimal test file. "Unfortunately" pgfplots depends on e-TeX and I don't have a "Knuth's TeX + e-TeX" binary. Maybe there exists something like this in older TL releases. Maybe even Knuth's TeX has this problem, but I don't know to prove it. Hans and Taco said that the string pool is the culprit. Yes, after adding some tiny things to the .tex file, I had to create a new format file with an increased string pool in order to get PDF files at all. It's definitely the string pool which causes trouble. I don't know anything about TeX's innards but the name "string pool" implies that it contains human readable stuff. If this is true, isn't it possible to convince TeX to dump the string pool to a file or to standard output, for instance, whenever a page is shipped out? This probably helps to find out what's going on. Anyway, please try http://tug.org/~kotucha/testpgfplots.tex.gz instead of mktestfiles.gz. 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. ----------------------------------------------------------------------------

3 5

Re: [NTG-pdftex] processing speed
by The Thanh Han 03 Jul '09

03 Jul '09

On Wed, Jul 01, 2009 at 04:01:02PM +0200, Jerome Laurens wrote: > Hi there, > > Hahn found a bug in synctex, I fixed it and made the tests with the > stable branch of pdftex > > [...] > > That makes 74 files processed at 4.75 sec/file > > [...] > > That makes 63 files processed at 5.3 sec/file > > If that's OK I'll send the diff file please do post the diff file. thanks, Thanh

1 0

[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