Hartmut Henkel wrote:
On Mon, 13 Nov 2006, Werner LEMBERG wrote:
Problem now is that latex and dvipdfmx work, but pdflatex doesn't. And the PDF documents in all other languages are made with pdflatex. Strange thing as well is that it worked before with CJK v4.5.2.
Apparently, you've found a fatal bug in pdftex. I was able to reduce it to the attached document. Using the TeXLive SVN from today (which contains pdfeTeX 3.141592-1.30.4-2.2), the first run of
pdflatex zzzz.tex
works fine, but a second run crashes with
! pdfTeX error (arithmetic): divided by zero.
This is on a GNU/Linux box, BTW.
problem appears when font bsmiu59 is called, which happens to be font no. 256 in the 2nd run. Font size for this font is set to 717619. But then in pdf_begin_string() the value pdf_font_size[f] is zero, so the
s := divide_scaled(cur_delta_h - pdf_delta_h, pdf_font_size[f], 3);
crashes. It has nothing to do with this particular font, but it seems that pdftex can't handle more than 255 fonts, so that some wraparound seems to happen and there is no catch for this condition.
Obvious questions are: Does pdftex have this 255 limitation? Can this be extended? Or should pdftex quit with the remark that it can't handle this? Is this really the first time that somebody requests more than 255 fonts?
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. Taco