July 2006 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-505 ] file with only \immediate\pdfobj stream results in garbage
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #505, was opened at 2006-04-06 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=505&group_id=106 Category: None Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: file with only \immediate\pdfobj stream results in garbage Initial Comment: The input \pdfcompresslevel=0 \immediate\pdfobj stream {xx} \end results in the message No pages of output. but produces the garbage pdf attached. Confirmed with 1.30.2 and the last 1.40.0-beta. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:18 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-08 08:45 Message: Logged In: YES user_id=929 tried 2 approaches: 1) try to make a complete PDF file without pages, like: << /Type /Pages /Count 0 /Kids [] >> Then xpdf shows a white background, but acroread complains. So this can't be done. 2a) silently delete faulty PDF. But one should give at least a warning. 2b) flag warning and delete faulty PDF. That's the current patch for 1.40.0-beta-20060213. Now it says: This is pdfTeXk, Version 3.141592-1.40.0-beta-20060213 (Web2C 7.5.5) (format=pdftex 2006.4.8) 8 APR 2006 07:41 %&-line parsing enabled. **test1 (./test1.tex ) No pages of output. Warning: pdftex: dangling objects discarded, no output file produced. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=505&group_id=106

1 0

manual issues
by Paweł Jackowski 26 Jul '06

26 Jul '06

Martin, the following primitives are not documented. Could you please comment a status? \pdfpxdimen \pdffirstlineheight \pdflastlinedepth \pdfeachlinedepth \pdfeachlineheight \pdfstrcmp, \pdfmatch % will be replaced by luatex? \pdfretval anything else? Best, -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

4 5

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #555, was opened at 2006-05-20 16:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 Category: hz Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Dag Leine (dag) Assigned to: Taco Hoekwater (taco) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-26 00:04 Message: Logged In: YES user_id=929 the value of temp_head seems to be right, but maybe it must be p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} p := find_protchar_right(link(temp_head), p); with link(temp_head) instead of temp_head, as "The current line to be justified appears in a horizontal list starting at |link(temp_head)| and ending at |cur_break(cur_p)|." wild guess only, seems to work. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-25 23:33 Message: Logged In: YES user_id=929 seems it happens at this line in pdftex.web: p := prev_rightmost(temp_head, q); {get |link(p) = q|} the temp_head before this call is 1499996 which seems to be wrong. Then after the call p = 1499996, and there is font f=-4096 attached to this node which is also wrong. So it seems that somehow temp_head got lost before call of prev_rightmost(). No clue how. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-07-25 23:06 Message: Logged In: YES user_id=1608 ok, will check tomorrow ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 21:30 Message: Logged In: YES user_id=421 This still happens with the latest beta (I've got an OpenBSD machine now myself): Program received signal SIGSEGV, Segmentation fault. 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; (gdb) bt #0 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 #1 0x1c053d53 in zpostlinebreak (d=1) at pdftex2.c:7715 #2 0x1c007659 in zlinebreak (d=1) at pdftexini.c:2136 #3 0x1c05bb11 in initmath () at pdftex3.c:141 #4 0x1c065091 in maincontrol () at pdftex3.c:4582 #5 0x1c0130a2 in mainbody () at pdftexini.c:5647 #6 0x1c069d9e in main (ac=2, av=0xcfbd239c) at pdftexextra.c:340 (gdb) l pdftex2.c:3191 3186 c = getlpcode ( f , mem [p ].hh.b1 ) ; 3187 lastleftmostchar = p ; 3188 } 3189 else { 3190 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; 3192 lastrightmostchar = p ; 3193 } 3194 if ( c == 0 ) 3195 return Result ; (gdb) p f $1 = -4096 (gdb) p p $2 = 999996 (gdb) p mem[p].hh $3 = {v = {LH = -268435455, RH = 675}, u = {B1 = 1, B0 = -4096}} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Bugs item #555, was opened at 2006-05-20 16:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 Category: hz Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Dag Leine (dag) Assigned to: Taco Hoekwater (taco) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-25 23:33 Message: Logged In: YES user_id=929 seems it happens at this line in pdftex.web: p := prev_rightmost(temp_head, q); {get |link(p) = q|} the temp_head before this call is 1499996 which seems to be wrong. Then after the call p = 1499996, and there is font f=-4096 attached to this node which is also wrong. So it seems that somehow temp_head got lost before call of prev_rightmost(). No clue how. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-07-25 23:06 Message: Logged In: YES user_id=1608 ok, will check tomorrow ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 21:30 Message: Logged In: YES user_id=421 This still happens with the latest beta (I've got an OpenBSD machine now myself): Program received signal SIGSEGV, Segmentation fault. 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; (gdb) bt #0 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 #1 0x1c053d53 in zpostlinebreak (d=1) at pdftex2.c:7715 #2 0x1c007659 in zlinebreak (d=1) at pdftexini.c:2136 #3 0x1c05bb11 in initmath () at pdftex3.c:141 #4 0x1c065091 in maincontrol () at pdftex3.c:4582 #5 0x1c0130a2 in mainbody () at pdftexini.c:5647 #6 0x1c069d9e in main (ac=2, av=0xcfbd239c) at pdftexextra.c:340 (gdb) l pdftex2.c:3191 3186 c = getlpcode ( f , mem [p ].hh.b1 ) ; 3187 lastleftmostchar = p ; 3188 } 3189 else { 3190 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; 3192 lastrightmostchar = p ; 3193 } 3194 if ( c == 0 ) 3195 return Result ; (gdb) p f $1 = -4096 (gdb) p p $2 = 999996 (gdb) p mem[p].hh $3 = {v = {LH = -268435455, RH = 675}, u = {B1 = 1, B0 = -4096}} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Bugs item #555, was opened at 2006-05-20 16:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 Category: hz Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Dag Leine (dag) Assigned to: Taco Hoekwater (taco) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2006-07-25 23:06 Message: Logged In: YES user_id=1608 ok, will check tomorrow ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 21:30 Message: Logged In: YES user_id=421 This still happens with the latest beta (I've got an OpenBSD machine now myself): Program received signal SIGSEGV, Segmentation fault. 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; (gdb) bt #0 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 #1 0x1c053d53 in zpostlinebreak (d=1) at pdftex2.c:7715 #2 0x1c007659 in zlinebreak (d=1) at pdftexini.c:2136 #3 0x1c05bb11 in initmath () at pdftex3.c:141 #4 0x1c065091 in maincontrol () at pdftex3.c:4582 #5 0x1c0130a2 in mainbody () at pdftexini.c:5647 #6 0x1c069d9e in main (ac=2, av=0xcfbd239c) at pdftexextra.c:340 (gdb) l pdftex2.c:3191 3186 c = getlpcode ( f , mem [p ].hh.b1 ) ; 3187 lastleftmostchar = p ; 3188 } 3189 else { 3190 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; 3192 lastrightmostchar = p ; 3193 } 3194 if ( c == 0 ) 3195 return Result ; (gdb) p f $1 = -4096 (gdb) p p $2 = 999996 (gdb) p mem[p].hh $3 = {v = {LH = -268435455, RH = 675}, u = {B1 = 1, B0 = -4096}} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

Re: [NTG-pdftex] [ pdftex-Bugs-565 ] ttf2afm fails to include characters specified with uniXXXX
by Thanh Han The 25 Jul '06

25 Jul '06

On Tue, Jul 25, 2006 at 11:16:49PM +0530, noreply(a)sarovar.org wrote: > Bugs item #565, was opened at 2006-05-29 16:37 > You can respond by visiting: > http://sarovar.org/tracker/?func=detail%26atid=493%26aid=565%26group_id=106 > > >Category: ttf2afm > Group: v1.30.0 > Status: Open > Resolution: None > Priority: 5 > Submitted By: Mike Spivey (spivey) > Assigned to: The Thanh Han (hanthethanh) > Summary: ttf2afm fails to include characters specified with uniXXXX > > Initial Comment: > If characters are specified in an encoding vector as > uniXXXX (with XXXX a hexadecimal unicode value), then > these characters are not included in the AFM output, > unlike characters that are specified by name. The same > goes for characters specifed by position. > > A suggested patch is attached. > > ---------------------------------------------------------------------- > > Comment By: Martin Schr�der (oneiros) > Date: 2006-07-25 19:46 > > Message: > Logged In: YES > user_id=421 > > Thanh, ttf2afm is your baby. :-) > Pleae check. yes sir :) I have looked at the patch and think you can accept it. Thanh

1 0

Re: [NTG-pdftex] manual issues
by Thanh Han The 25 Jul '06

25 Jul '06

On Tue, Jul 25, 2006 at 08:16:43PM +0200, Martin Schröder wrote: > 2006/6/18, Paweł Jackowski <P.Jackowski(a)gust.org.pl>: > > the following primitives are not documented. Could you please comment a > > status? > > > > \pdfpxdimen > > \pdffirstlineheight > > \pdflastlinedepth > > \pdfeachlinedepth > > \pdfeachlineheight > > Thanh's experimental? actually they were Han's requests. Don't know if they are helpful, but it doesn't hurt to have them there. Thanh

1 0

1.40.0-beta-20060725
by Martin Schröder 25 Jul '06

25 Jul '06

http://sarovar.org/download.php/1060/pdftex-1.40.0-beta-20060725.tar.bz2 --------------------------------------------------------------- pdfTeX 3.141592-1.40.0-beta-20060725 was released on 2006-07-25 --------------------------------------------------------------- - added patches by Christian Schenk forwarded by Hartmut - added patch 421 (popen) from Taco - added lots of (void) to writettf* and ttf2afm to silence the compiler - removed some unused variables from tounicode.c - add new code by Thanh (patch 580) - added security patch for xpdf :-( Yes, we are alive. :-) Before I go further, I wanted to release the stuff I have on my harddisc and found in my inbox. Most likely I've forgotten some patches; please check. Best Martin

2 1

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Bugs item #555, was opened at 2006-05-20 16:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 >Category: hz Group: v1.30.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Dag Leine (dag) >Assigned to: Taco Hoekwater (taco) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-07-25 21:30 Message: Logged In: YES user_id=421 This still happens with the latest beta (I've got an OpenBSD machine now myself): Program received signal SIGSEGV, Segmentation fault. 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; (gdb) bt #0 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 #1 0x1c053d53 in zpostlinebreak (d=1) at pdftex2.c:7715 #2 0x1c007659 in zlinebreak (d=1) at pdftexini.c:2136 #3 0x1c05bb11 in initmath () at pdftex3.c:141 #4 0x1c065091 in maincontrol () at pdftex3.c:4582 #5 0x1c0130a2 in mainbody () at pdftexini.c:5647 #6 0x1c069d9e in main (ac=2, av=0xcfbd239c) at pdftexextra.c:340 (gdb) l pdftex2.c:3191 3186 c = getlpcode ( f , mem [p ].hh.b1 ) ; 3187 lastleftmostchar = p ; 3188 } 3189 else { 3190 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; 3192 lastrightmostchar = p ; 3193 } 3194 if ( c == 0 ) 3195 return Result ; (gdb) p f $1 = -4096 (gdb) p p $2 = 999996 (gdb) p mem[p].hh $3 = {v = {LH = -268435455, RH = 675}, u = {B1 = 1, B0 = -4096}} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

[ pdftex-Bugs-565 ] ttf2afm fails to include characters specified with uniXXXX
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Bugs item #565, was opened at 2006-05-29 16:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106 >Category: ttf2afm Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Mike Spivey (spivey) Assigned to: The Thanh Han (hanthethanh) Summary: ttf2afm fails to include characters specified with uniXXXX Initial Comment: If characters are specified in an encoding vector as uniXXXX (with XXXX a hexadecimal unicode value), then these characters are not included in the AFM output, unlike characters that are specified by name. The same goes for characters specifed by position. A suggested patch is attached. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 19:46 Message: Logged In: YES user_id=421 Thanh, ttf2afm is your baby. :-) Pleae check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106

1 0