Re: [NTG-pdftex] [pdftex] SGML output fails with pdflatex
It is an oversight, the problem is that the global |f| is of the wrong type. In pdftex.web,
@@ -13795,7 +13795,8 @@ @!dead_cycles:integer; {recent outputs that didn't ship anything out} @!doing_leaders:boolean; {are we inside a leader box?} @# -@!c,@!f:quarterword; {character and font in current |char_node|} +@!c:quarterword; {character in current |char_node|} +@!f:internal_font_number; {font in current |char_node|} @!rule_ht,@!rule_dp,@!rule_wd:scaled; {size of current rule being output} @!g:pointer; {current glue specification} @!lq,@!lr:integer; {quantities used in calculations for leaders}
Should fix this problem as well as any potentially still lurking similar problems.
Is it special to Debian? In 1.40.0 beta, I think it does not remain in the final pdftex.p since in tex.ch, and thus in pdftex.ch, there are lines @x @!c,@!f:quarterword; {character and font in current |char_node|} @y {character and font in current |char_node|} @!c:quarterword; @!f:internal_font_number; @z Best regards, Akira
2006/11/15, Akira Kakuto
Is it special to Debian? In 1.40.0 beta, I think it does not
Seems to be, as 1.30.6 and 1.40.0-beta have f:internal_font_number; in pdftex-all.web (cd texk/web2c; make pdftex-all.web). Best Martin
Akira Kakuto wrote:
Is it special to Debian? In 1.40.0 beta, I think it does not remain in the final pdftex.p since in tex.ch, and thus in pdftex.ch, there are lines @x @!c,@!f:quarterword; {character and font in current |char_node|} @y {character and font in current |char_node|} @!c:quarterword; @!f:internal_font_number; @z
Oops, I missed that. Let me check that again (that'll teach me to attempt to debug stuff without running the test file :-/) Taco
Hi, This turned out to be something completely different from what I thought initially, and does not seem related to a font number limit at all ? My current analysis is that the internal base font defined in the vf file is not initialized yet (so pdf_font_size[f] is still zero) at the moment output_one_char() is called on it. I am surprised because if that really is the problem, should it not have happened earlier and more often? The attached patch makes the test document run without error on my machine. However, I am not sure whether this fixes the problem or just makes the message disappear while still generating wrong output. The important line is the 'if font_used[f]' test, the other change is just to avoid confusion (do_vf_packet used to assign to its 'f' argument). Best, Taco --- pdftex.web.org 2006-10-17 15:24:02.000000000 +0200 +++ pdftex.web 2006-11-15 14:40:20.818656564 +0100 @@ -17603,7 +17603,7 @@ packet_scaled := s; end; -procedure do_vf_packet(f: internal_font_number; c: eight_bits); {typeset the \.{DVI} commands in the +procedure do_vf_packet(ff: internal_font_number; c: eight_bits); {typeset the \.{DVI} commands in the character packet for character |c| in current font |f|} label do_char, continue; var save_vf, k, n: internal_font_number; @@ -17612,7 +17612,9 @@ char_move: boolean; w, x, y, z: scaled; s: str_number; + f: internal_font_number; begin + f := ff; incr(vf_cur_s); if vf_cur_s > vf_max_recursion then overflow("max level recursion of virtual fonts", vf_max_recursion); @@ -17622,6 +17624,8 @@ vf_replace_z; save_vf := f; f := vf_i_fnts[vf_default_font[save_vf]]; + if not font_used[f] then + pdf_init_font(f); save_v := cur_v; save_h := cur_h; w := 0; x := 0; y := 0; z := 0;
On Wed, 15 Nov 2006, Taco Hoekwater wrote:
This turned out to be something completely different from what I thought initially, and does not seem related to a font number limit at all ?
now it seems to be some kind of memory leak: Something spills over into the font_used[f] array, setting it successively true from the beginning. When font no. 90 is loaded, it's just full enough so that this font is never initialized. Then it crashes. Guarding the font_used[f] array in front by some additional dummy boolean foo_used[f] array helps, then it runs fine. One also sees that then array foo_used[] is filled with true. No idea yet what this leak is. Regards, Hartmut
Hi, Hartmut Henkel wrote:
On Wed, 15 Nov 2006, Taco Hoekwater wrote:
This turned out to be something completely different from what I thought initially, and does not seem related to a font number limit at all ?
now it seems to be some kind of memory leak: Something spills over into the font_used[f] array, setting it successively true from the beginning. When font no. 90 is loaded, it's just full enough so that this font is never initialized. Then it crashes. Guarding the font_used[f] array in front by some additional dummy boolean foo_used[f] array helps, then it runs fine. One also sees that then array foo_used[] is filled with true. No idea yet what this leak is.
I think I have found it from checking up your hint about font_used[] in the debugger: The arrays vf_i_fnts[] and vf_e_fnts[] are alloc as size font_max, but their indexes can easily overflow that because a vf font can contain more than one base font. I've added two cases of if vf_nf>font_max then overflow("virtual fonts",font_max); right after the two occurrences of increments of vf_nf in pdftex.web, and now I get: ! TeX capacity exceeded, sorry [virtual fonts=2000]. Cheers, Taco
participants (4)
-
Akira Kakuto -
Hartmut Henkel -
Martin Schröder -
Taco Hoekwater