- ntg-pdftex - NTG Mailing Lists

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

06 Apr '09

Bugs item #993, was opened at 2008-05-24 15: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: Wont Fix 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: Heiko Oberdiek (oberdiek) Date: 2009-04-06 05: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-06 00: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 18: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 18: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 17: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-Patches][3886] Fix for str_less_str (bug #993)
by pdftex-patches＠sarovar.org 06 Apr '09

06 Apr '09

Patches item #3886, was opened at 2009-04-06 05:38 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Fix for str_less_str (bug #993) Category: None Group: None Resolution: None Initial Comment: The patch is based on pdftex-1.40.9. It fixes the bug #993 `/Names array not sorted correctly' by correcting function `str_less_str'. In theory pdfTeX can still be fooled by * invalid pdf strings and * equal destination names that only differs in the way of escaping. But both problems can be solved at macro level by passing the name argument of \pdfdest through \pdfescapestring. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=3886&group_id=106

1 0

[pdftex-Bugs][3253] Bug in Type1 font subsetting
by pdftex-bugs＠sarovar.org 06 Apr '09

06 Apr '09

Bugs item #3253, was opened at 2009-03-23 22:39 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: Bug in Type1 font subsetting Category: Fonts Group: None Resolution: Accepted Initial Comment: see http://tug.org/mailman/htdig/pdftex/2009-March/007975.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 23:24 Message: this has been fixed in TL and pdftex (1.40.10) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=3253&group_id=106

1 0

[pdftex-Bugs][884] Letterspacing and non-autoexpanded fonts
by pdftex-bugs＠sarovar.org 06 Apr '09

06 Apr '09

Bugs item #884, was opened at 2007-11-27 09:53 >Status: Closed Priority: 2 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Letterspacing and non-autoexpanded fonts Category: hz Group: v1.40.5 >Resolution: Wont Fix Initial Comment: While auto-expanding letterspaced fonts works fine now, there still is a problem with non-automatic expansion. The following will complain about a missing tfm file. It doesn't make a difference whether the expanded font instance is created from an mf file (like below), via `ExtendFont' in the map file, or even whether it was created from a MM font (ie., the expanded instance actually exists as a pfb file). The latter case is what bothers me the most. \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr=cmr10 \cmr \letterspacefont\cmrls=\cmr 100 \pdffontexpand\cmrls 100 0 100 %autoexpand \cmrls Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye PS: what about the `invalid entry' complaint for the map lines? Are they not legal? ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 23:23 Message: Re: the invalid entry: it should be something like this: \pdfmapline{+cmr10+100 <cmr10+100.pfa} (the fontfile must be present, otherwise pdftex will complain) Re: the problem with \pdffontexpand: what happens here is as follows: \letterspacefont\cmrls=\cmr 100 => pdftex creates a font named cmr10+100ls in memory \pdffontexpand\cmrls 100 0 100 autoexpand => pdftex creates another font from cmr10+100ls, and name it cmr10+100ls+100 without "autoexpand", pdftex would look for a tfm file named cmr10+100ls+100.tfm, and henc cmr10+100 would not be loaded. yes this is a problem, however not a bug. And there is no easy way to get this work, I am sorry but have to close this as "won't fix". ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 16:42 Message: Logged In: YES user_id=2217 > A map line needs either a psname (for not-embedded fonts) > or the file name (for embedded fonts) The manual seems to suggest otherwise (re scalable Type 3 fonts). Also, older pdftex versions wouldn't throw a warning, but use the Type 3 font instead. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-11-27 10:05 Message: Logged In: YES user_id=421 A map line needs either a psname (for not-embedded fonts) or the file name (for embedded fonts) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=884&group_id=106

1 0

[pdftex-Bugs][2100] colors on page influenced by included pdf image
by pdftex-bugs＠sarovar.org 06 Apr '09

06 Apr '09

Bugs item #2100, was opened at 2008-10-08 22:18 >Status: Closed Priority: 3 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Nobody (None) Summary: colors on page influenced by included pdf image Category: PDF inclusion Group: v1.40.8 >Resolution: Rejected Initial Comment: I've got a problem with defined colors on a page when I include a pdf image. The original file (regression-org.pdf) is included on the second page: blue and red on that page are different from the blue and red on the other pages. However, if I convert the included pdf image to ps via pdftops and back to pdf via pstopdf (regression.pdf), there's no problem as shown on the last page. Is this a bug in pdftex, or am I using an "incorrectly" generated pdf image file, since a double conversion seems to produce the correct output? (I'm using texlive's 2008 pdftex 1.40.9) Best regards Stefan ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 23:10 Message: I confirm the problem, but this doesn't seem a bug of pdftex. We will reopen this if more evidence is provided. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-10-10 08:56 Message: I don't think the problem here is transparency (I don't find a /Group), but ICC, as regression-org.pdf uses an /ICCbased colorspace. Oh, and I get the same colours here with 1.40.9 and AR8 on Linux. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-10-10 08:13 Message: It's a known problem of later AR versions if transparency is involved. Then AR seems to be using a different method for displaying the page and colors may change. PostScript doesn't support transparency, thus converting to PS and back to PDF gets rid of the transparency. Tested with: * AR7/Linux, AR8/Linux: wrong displayed colors * AR5/Linux: correct colors * xpdf3.00: correct colors * gs8.54: correct colors, but warnings for second page: CS/cs (setcolorspace) operand not a name: [/ICCBased -dict-] * gs8.62: fails on page two with /unknownerror. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2100&group_id=106

1 0

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

05 Apr '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: Wont Fix 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-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-Patches][469] \currentexpansionmode + \ifalignscanning - \ifinedef
by pdftex-patches＠sarovar.org 05 Apr '09

05 Apr '09

Patches item #469, was opened at 2006-01-12 01:39 >Status: Closed Priority: 3 Submitted By: Morten Høgholm (morten) Assigned to: The Thanh Han (hanthethanh) Summary: \currentexpansionmode + \ifalignscanning - \ifinedef Category: Primitives Group: v1.40.0 >Resolution: Rejected Initial Comment: Here's a patch made against pdftex-1.40.0-alpha-20060111. It removes the \ifinedef primitive for a different primitive, namely \currentexpansionmode. This read-only register is 0 when doing regular typesetting, 1 when inside \edef or \xdef and 2 in other cases of full expansion with scan_toks. It could possibly be extended to distinguish between \marks and \write etc. Comments more than welcome on this one! I have also added an \ifalignscanning test. It is true whenever TeX is looking for \noalign etc. so is most useful for a \stopalignscanning function defined as \def\stopalignscanning{\ifalignscanning\relax\fi} ---------------------------------------------------------------------- Comment By: Frank Mittelbach (mittelbach) Date: 2006-02-15 17:38 Message: Logged In: YES user_id=3421 concerning register versus individual \if... primitves: I agree that numeric values are less easy to read but if the numeric codes are well chosen then they have the advantage of not cluttering the code, eg if you have to test for a number of different cases then a set of nested \if's is also not really helpful. Suppose for example you have to do different actions depending on the type of expansion. Then the register allows you to do this in a since \ifcase or in some \ifnum ...> . But of course this only works is the order is adjusted to typical usages. And non-numerical ones could still be implemented efficently at the macro level, eg \def\ifinedef{\ifnum 1=\currentexpansionmode} as to \stopalignscanning: this is not identical to \protected as protection prevents expansion in all cases which is not necessarily what you need my 2 cents frank ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-17 22:22 Message: Logged In: YES user_id=927 concerning alignments: - how about adding \everyaligncell (in addition to \everycr) - how about the other iftests? - (and \nospan -) ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-16 20:23 Message: Logged In: YES user_id=3333 @None: An \ifalignscanning primitive can also help macros like LaTeX's \multicolumn and other code that relies on seeing \noalign or \omit to recover gracefully with a comprehensible error message. ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-13 04:50 Message: Logged In: YES user_id=3333 Yes, just ideas here, which is why I asked for comments. We can discuss this on the list (once my subscription is accepted). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-01-12 10:22 Message: Logged In: YES user_id=1608 Like Hans, I also prefer separate if primitives, mainly because I do not want to have to remember the meanings of the possible integer values (for that reason, I'm not too happy about \currentgrouptype either). Taco ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-01-12 09:14 Message: Logged In: NO i wonder why we need \ifalignscanning or \stopalignscanner at all when eTeX already has this feature - any \protected macro stops the scanning. ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-12 08:08 Message: Logged In: YES user_id=927 somehow i think that if's are a better idea than a register because in your case the register only registers one case at the same time (when i saw this patch the first time, i wondered why not a complete set was implemented) - ifincsname - ifinedef - ifinwrite - ifinspecial - ifinpdfliteral - ifinannotbody - ifinmessage (special case of write) - ifinalign - ifinmark probably some more (ok, normally all those conditions can comfortably be catched in a macro package but if we add them, we should be complete in addition to this there can be a register which keeps track of the innermost one (we can have ifcsname inside an edef inside an align concerning the \stopalignscanner i think it's better to have something primitive like \crcr, say \endalign because using if's can have its own problem (we should not worry to much about a name clash, since one can always let it to another one); so, we should wait with adding this patches till (1) we agree and (2) it is complete remark: also, it's dangerous to add patched before a decent decission/interface is dediced upon; once it's in, we cannot change it any more Hans ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=469&group_id=106

1 0

[pdftex-Patches][2091] bugfix for #2090
by pdftex-patches＠sarovar.org 05 Apr '09

05 Apr '09

Patches item #2091, was opened at 2008-09-17 06:59 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: bugfix for #2090 Category: None Group: None >Resolution: Accepted Initial Comment: this patch is for 1.40.9 and the stable branch only. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-09-17 07:03 Message: update: don't forget to rerun autoconf after applying the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=2091&group_id=106

1 0

[pdftex-Bugs][829] TEX_HUSH not handled correctly
by pdftex-bugs＠sarovar.org 23 Mar '09

23 Mar '09

Bugs item #829, was opened at 2007-07-04 10:49 >Status: Closed Priority: 1 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: TEX_HUSH not handled correctly Category: web2c Group: v1.40.3 >Resolution: Wont Fix Initial Comment: This is from kpathsea.info: --------------------------- 4.4 Suppressing warnings ======================== Kpathsea provides a way to suppress selected usually-harmless warnings; this is useful at large sites where most users are not administrators, and thus the warnings are merely a source of confusion, not a help. To do this, you set the environment variable or configuration file value `TEX_HUSH' to a colon-separated list of values. Here are the possibilities: `all' Suppress everything possible. `checksum' Suppress mismatched font checksum warnings. `lostchar' Suppress warnings when a character is missing from a font that a DVI or VF file tries to typeset. `none' Don't suppress any warnings. `readable' Suppress warnings about attempts to access a file whose permissions render it unreadable. `special' Suppresses warnings about an unimplemented or unparsable `\special' command. `tex-hush.c' defines the function that checks the variable value. Each driver implements its own checks where appropriate. --------------------------- This is currently not handled by pdftex. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-04 11:01 Message: Logged In: YES user_id=421 Not Knuth's warnings. But pdfTeX in PDF mode is also a driver... The only one that IMHO matters is "special". OTOH nobody has complained about this yet... ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 10:56 Message: Logged In: YES user_id=1608 This only affects the backend driver, right? But not Knuth's warnings in the web source. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=829&group_id=106

1 0

[pdftex-Bugs][2242] typo in ttf2afm warning
by pdftex-bugs＠sarovar.org 23 Mar '09

23 Mar '09

Bugs item #2242, was opened at 2008-12-16 08:35 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: typo in ttf2afm warning Category: ttf2afm Group: v1.40.8 >Resolution: Fixed Initial Comment: ttf2afm has a typo in warning for glyphs with multiple encodings. Example: Warning: ttf2afm (file pala.ttf): glyph 108 have multiple encodings (the first one being used): uni0162 uni021A ("have" should be replaced by "has") ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2242&group_id=106

1 0