December 2009 - ntg-pdftex - NTG Mailing Lists

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

01 Dec '09

Bugs item #4289, was opened at 2009-05-21 18:52 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: \primitive\pdfoutput cannot be queried Category: None Group: None >Resolution: Fixed Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-April/003769.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:26 Message: fixed in 1.40.10 ---------------------------------------------------------------------- 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

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

01 Dec '09

Bugs item #4290, was opened at 2009-06-26 17:55 >Status: Closed 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: Fixed Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-May/003786.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:24 Message: fixed in 1.40.10 ---------------------------------------------------------------------- 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][4288] character width mismatch in font XY.vf ignored
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #4288, was opened at 2009-05-12 07:47 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: character width mismatch in font XY.vf ignored Category: Fonts Group: None >Resolution: Fixed Initial Comment: see http://tug.org/pipermail/pdftex/2009-May/008031.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:24 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-05-12 12:23 Message: bugfix from Hartmut attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4288&group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #993, was opened at 2008-05-24 13:24 >Status: Closed Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly Category: None Group: v1.40.6 >Resolution: Fixed Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:22 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-06 08:22 Message: thanks Heiko for the patch, hence I reopened this bug report. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 03:49 Message: Sorry, I cannot accept the rejection, because the problem cannot be fixed at macro level unless * some characters (backslash, parentheses, ...) must be forbidden, * octal escape sequences are used for *every* character of the destination name (otherwise a large amount of programming work is needed to prevent that the bug is triggered.) Therefore I have written patch #3886 that fixes the comparison function `str_less_str' that is used for the sorting of destination names. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 22:55 Message: since the beginning we chose not to parse pdf string of \pdf* commands. Fixing this now would mean a too big change in pdftex code. Sorry. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 16:48 Message: ok then this should be fixed as the spec says. BTW, it doesn't really solve the reported problem (ü will come after eg z). ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2008-05-27 16:03 Message: the spec says: The Names entries in the leaf (or root) nodes contain the tree’s keys and their associated values, arranged in key-value pairs and sorted lexically in ascending order by key. Shorter keys appear before longer ones beginning with the same byte sequence. The encoding of the keys is immaterial as long as it is self-consistent; keys are compared for equality on a simple byte-by-byte basis. so, it's just bytes ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 15:43 Message: this is a problem, but it's not clear to me how it should be fixed. Assume that we translate "\374" to the corresponding charcode (0374 = 252) before sorting, then how we decide the lexicographic order of that char? it can be intepreted as ü but also can be eg ytilde or something different, depending on the encoding we use. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0