- ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][606] Forbidden ... while scanning ???
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #606, was opened at 2006-09-16 20:28 >Status: Closed Priority: 2 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Forbidden ... while scanning ??? Category: Primitives Group: v1.40.0 >Resolution: Fixed Initial Comment: \pdftrailer {abc \bye gives ! Forbidden control sequence found while scanning text of \pdftrailer. but \pdfximage {abc \bye or \pdfliteral {abc \bye give ! Forbidden control sequence found while scanning text of ???. Instead of these three question marks there should be the name of the primitive. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:29 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2009-04-07 06:28 Message: Attached is what I would do: patch scan_keyword() to restore cur_cs in the 'false' case. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-27 15:40 Message: Logged In: YES user_id=421 Hartmut, can you please check this again for 1.50? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-21 12:22 Message: Logged In: YES user_id=421 I've backed out the change; this is low priority and probably needs more changes. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-17 19:10 Message: Logged In: YES user_id=929 yes, the patch works, thanks a lot! But there are in fact many more \pdf... primitives that suffer from this problem, actually any with a scan_keyword call before the scan_pdf_ext_toks. After the way how it's done in @<Implement \.{\\write}@>=, it seems that a new variable save_cur_cs is not needed if one uses k for this purpose. Needs change of a few k uses to j. But problematic is \pdfoutline as it has another scan_pdf_ext_toks for the attr keyword. Wouldn't these many changes be too risky for 1.40.0? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 16:34 Message: Logged In: YES user_id=421 The patch was missing. Fixed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 14:30 Message: Logged In: YES user_id=421 The cause seems to be that some scan_functions loose the meaning of cur_cs, which leads to the ??? when reaching <Tell the user what has run away...@>. The attached (IMHO crude) patch fixes this for the cases you mentioned, but there are probably other cases not found... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106

1 0

[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

pdftex-1.40.10
by Thanh Han The 30 Nov '09

30 Nov '09

Hi, pdftex-1.40.10 is available at http://sarovar.org/frs/download.php/1292/pdftex-1.40.10.tar.bz2 This is a maintenance release with mostly bugfixes. ,--------, | - sync with TL09 | - changes: | - increased sup_dest_names_size | - partial support for TTC | - enable mktexpk by default | - patch #2087: Support for CMap namespace | - \pdfshellescape is 2 if restricted shell escapes are enabled. | - bugfixes: | - segfault when processing certain TTF fonts | - jpg image resolution not set in some cases | - \pdfobj file {foo} for files foo that don't end with '\n' | - bugfix #4289: \primitive\pdfoutput cannot be queried | - bugfix #4288: character width mismatch in font XY.vf ignored | - bugfix #993: "/Names array not sorted correctly" | - bugfix #606: "Forbidden ... while scanning ???" | - bugfix #3253: Bug in Type1 font subsetting | - \show\pdfstartlink is wrong | - pdf_set_rule() uses incorrect variables | - bugfix #2090: enabling LFS breaks PDF inclusion on some systems (warning: not heavily-tested yet) | - t1_log() macro caused problem with some compilers `--------` there are still some minor bugs which are not included in 1.40.10, since this release is to be compatible with TL09. Regards, Thanh

1 0

[pdftex-Patches][4299] pdf font inclusion error (with partial patch)
by pdftex-patches＠sarovar.org 27 Nov '09

27 Nov '09

Patches item #4299, was opened at 2009-11-27 10:03 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: pdf font inclusion error (with partial patch) Category: PDF inclusion Group: None Resolution: Accepted Initial Comment: http://www.ntg.nl/pipermail/ntg-pdftex/2009-November/003859.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=4299&group_id=106

1 0

pdf font inclusion error (with partial patch)
by Taco Hoekwater 26 Nov '09

26 Nov '09

Hi, I have added the patch below to luatex and a similar one-liner for my local pdftex because we here ran into a pdf document that has the following oddness: 5 0 obj << /F15 << /Type /Font /Subtype /TrueType /BaseFont /WIDGBH+ArialMT /Encoding /WinAnsiEncoding /FirstChar 0 /LastChar 255 /FontDescriptor 8 0 R /Widths 7 0 R >> ... >> 6 0 obj << /Type /Page /Parent 4 0 R /MediaBox [ 0 0 595.276 841.89 ] /Resources << /Font 5 0 R /ProcSet [ /PDF /Text /ImageB /ImageC ] >> /Contents 13 0 R >> endobj Current pdftoepdf.cc expects to find indirect references inside object 5, without the patch it generates a fatal error. The patch itself is only a quick fix that works thanks to my setting of \pdfinclusioncopyfonts, as I do not know how to fix the 'other' case, sorry. Best wishes, Taco taco(a)metatex.org wrote: > Author: taco > Date: 2009-11-26 15:14:10 +0100 (Thu, 26 Nov 2009) > New Revision: 3192 > > Modified: > trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc > Log: > add a quick and dirty fix for pdfs generated by easyPDF Printer Driver 4.2, > which uses full font dictionaries inside the Font resources instead of > indirect references. > > > Modified: trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc > =================================================================== > --- trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc 2009-11-23 21:04:08 UTC (rev 3191) > +++ trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc 2009-11-26 14:14:10 UTC (rev 3192) > @@ -459,7 +459,8 @@ > pdf_puts(pdf, "/Font << "); > for (i = 0, l = obj->dictGetLength(); i < l; ++i) { > obj->dictGetValNF(i, &fontRef); > - if (fontRef->isRef()) > + if (fontRef->isRef() || > + (fontRef->isDict() && (pdf->inclusion_copy_font == 0))) > copyFont(pdf, obj->dictGetKey(i), &fontRef); > else > pdftex_fail("PDF inclusion: invalid font in reference type <%s>", > > _______________________________________________ > Luatex-commits mailing list > Luatex-commits(a)lists.foundry.supelec.fr > http://lists.foundry.supelec.fr/mailman/listinfo/luatex-commits

1 0

pdftex-1.40.10-RC
by Thanh Han The 20 Nov '09

20 Nov '09

Hi, pdftex-1.40.10-RC is available at http://sarovar.org/frs/download.php/1284/pdftex-1.40.10-RC.tar.bz2 This is a maintenance release with mostly bugfixes. ,--------, | - sync with TL09 | - changes: | - increased sup_dest_names_size | - partial support for TTC | - enable mktexpk by default | - patch #2087: Support for CMap namespace | - \pdfshellescape is 2 if restricted shell escapes are enabled. | - bugfixes: | - segfault when processing certain TTF fonts | - jpg image resolution not set in some cases | - \pdfobj file {foo} for files foo that don't end with '\n' | - bugfix #4289: \primitive\pdfoutput cannot be queried | - bugfix #4288: character width mismatch in font XY.vf ignored | - bugfix #993: "/Names array not sorted correctly" | - bugfix #606: "Forbidden ... while scanning ???" | - bugfix #3253: Bug in Type1 font subsetting | - \show\pdfstartlink is wrong | - pdf_set_rule() uses incorrect variables | - bugfix #2090: enabling LFS breaks PDF inclusion on some systems (warning: not heavily-tested yet) | - t1_log() macro caused problem with some compilers `--------` there are still some minor bugs which will not be fixed in 1.40.10 yet, since this release is to be compatible with TL09. Regards, Thanh

1 0

[pdftex-Bugs][4294] issue with isolated/non-isolated page transparency group
by pdftex-bugs＠sarovar.org 17 Nov '09

17 Nov '09

Bugs item #4294, was opened at 2009-09-02 00:43 >Status: Closed Priority: 3 Submitted By: John Owens (jowens) >Assigned to: Martin Schröder (oneiros) Summary: issue with isolated/non-isolated page transparency group Category: PDF inclusion Group: None >Resolution: Works For Me Initial Comment: (The last bug didn't show up. So I am posting a web link to the three files referenced below: http://tinyurl.com/n4jjm4 ) Howdy, I'm attaching 3 files. One is a tar.gz of a LaTeX document. When we first submitted the paper built from the document, we used dvips and Distiller. Now we're using pdflatex for the final version. Both pdfs are attached. However, strangely, page 4 on the pdflatex pdf, when viewed in Apple Preview on Snow Leopard (10.6), has substantially lighter fonts than the other pages. This is probably Preview's problem, not pdflatex's problem, and I've filed an Apple bug. However, from talking to a PDF expert (summary below), it appears that pdflatex is doing something weird, so I thought I'd bring it to your attention. The base page transparency group for page 4 is nonisolated, where for all the other pages the /I key is not present (and thus they are implicitly isolated). The PDF is correct, although a little weird--there is no point in even specifying the isolation key of a page's transparency group unless it a) contains non-normal blend modes _and_ b) will be rendered in non-device-like contexts (e.g., as an object in a larger piece of artwork). So I would argue that pdflatex should probably not even bother specifying the /I key, especially given that it appears to trigger a bug--or at least a dramatically different code path--in Preview. This _should_ have no effect, as the value of the /I key for the page group is supposed to be ignored (and treated as if it were true). Furthermore even if Preview were ignoring that requirement, the page doesn't have any blend modes, so mathematically it shouldn't be producing a different result. But my guess is this: Preview is rendering page 4 into a nonisolated transparency group using an initial, opaque, all-white backdrop, when it should be completely ignoring the /I key and rendering into a completely transparent backdrop. This shouldn't lead to different results unless a blend mode is present. But,the isolated and nonisolated code paths are somehow sufficiently different that they generate different pixel values--due to precision or perhaps an actual bug. But most of what I say is conjecture. See chapter 7.3.6 ("Page Group") of the PDF Reference Manual, sixth edition. The Distiller version doesn't even have transparency group objects on the pages (which is normal). So I wouldn't expect it to have the same issues in Preview, and it doesn't. (This is LaTeX source for a paper, so though I know you'll need the source to do your investigations and bug fixes, kindly don't do anything else with it beyond that.) $ pdflatex --version pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009) kpathsea version 5.0.0 Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.2.39; using libpng 1.2.39 Compiled with zlib 1.2.3; using zlib 1.2.3 Compiled with xpdf version 3.02pl3 $ uname -a Darwin classico-2.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 i386 ---------------------------------------------------------------------- Comment By: John Owens (jowens) Date: 2009-11-17 01:33 Message: Quite sensible. Not reasonable to expect pdftex to analyze the PDF and decide if a page's group dictionary is unnecessary. I think you can close this out. Thanks for looking at it! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2009-11-16 01:08 Message: John, the display problem is most likely a problem of apple - I can't reproduce the effext with AR9 on Linux. The page group on page 4 comes from the included pdf (figures/multiValue.pdf). pdftex will copy a page group from an included pdf (or synthesize one for pngs with transparency). I don't think it should analyze the content of the page groups it copies. ---------------------------------------------------------------------- Comment By: John Owens (jowens) Date: 2009-11-16 00:46 Message: Just checkin' in. Thanks! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-10-23 18:41 Message: yes this is. Sorry for not replying, I will take a close look in about 2 weeks. ---------------------------------------------------------------------- Comment By: John Owens (jowens) Date: 2009-10-22 22:21 Message: Is this the right place to report pdftex issues? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4294&group_id=106

1 0