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;