[ pdftex-Bugs-292 ] protuding leads to "This can't happen (paragraph)."
Bugs item #292, was opened at 2005-02-14 15:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106 Category: hz Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel)
Summary: protuding leads to "This can't happen (paragraph)."
Initial Comment: The input --------------------- \pdfoutput=1 \input edmac \input protcode \font\eightrm=ptmr8t \setprotcode\eightrm \pdfprotrudechars=2 \linenummargin{outer} %% left|right|inner|outer \footparagraph{A} \tracingall\tracingonline=0 \beginnumbering \pstart \text{There}\Afootnote{Habent sua fata libelli. (Der Satz wurde auf Wunsch der Redaktion von »Living Marxism« gestrichen; siehe Korsch an P.~Mattick am 3.10.1938.)}/ is a striking contrast between the impression produced in the minds of West"=European revolutionaries by those short pamphlets of Lenin and Trotsky which appeared in poorly translated and poorly printed editions during the final stage and the aftermath of the war, and the response called forth in Europe and U.S.A. by the belated appearance, in 1927, of the first extra"=Russian versions of Lenin's philosophical work of 1908, on »Materialism and Empirio"=Criticism«. \pend \endnumbering \bye --------------------- (all input files are in the attached archive) leads to --------------------- ! This can't happen (paragraph). <recently read> \par \do@feet ...s \else \Afootstart {A}\Afootgroup {A} \fi \ifvoid \Bfootins \els... \pagecontents ...p \@cclv \unvbox \@cclv \do@feet \ifr@ggedbottom \kern -\di... \pagebody ...\boxmaxdepth \maxdepth \pagecontents } \edmac@output ...e \vbox {\makeheadline \pagebody \makefootline }\fi }\advan... <output> {\edmac@output } ... l.30 \bye I'm broken. Please show this to someone who can fix can fix --------------------- ----------------------------------------------------------------------
Comment By: Hartmut Henkel (hhenkel) Date: 2005-02-14 20:42
Message: Logged In: YES user_id=929 Now we know which side effects patch-274 has. When it's reverted, the file is processed without error, but margin kerning is missing (which was the original problem before patch-274). Following experiment is done _with_ patch-274. The "this can't happen" error happens within the line_break routine, which chokes on a margin_kern_node (which was filtered out before patch-274).If one adds margin_kern_node to the do_nothing list, like: mark_node,ins_node,adjust_node,margin_kern_node: do_nothing; othercases confusion("paragraph") it apparently works ok, and margin kerning is fine also (requires patch in hz.ch). But i need to understand how the line_break routine works, whether a do_nothing is the right thing to do... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-14 15:30 Message: Logged In: YES user_id=421 The submitter used the attached edmac.doc; the error is the same. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106
Hi Hartmut, this probably has to do with the issue whether to copy or not margin_kern_node when unboxing a box we discussed a while ago. Perhaps edmac typesets some text, unboxes it and typesets it again and in this second phase the margin_kern_node ends up with error, as the only place where margin_kern_node makes sense is in the post line-breaking phase. I have no idea how to solve it yet. Ignoring margin_kern_node during line-breaking seems to be the right thing to do, but I am afraid it's not enough. Leaving margin_kern_node nodes pass unboxing means that they can end up anywhere, hence we also need to handle them everywhere (which is very fragile). Regards, Thanh
----------------------------------------------------------------------
Comment By: Hartmut Henkel (hhenkel) Date: 2005-02-14 20:42
Message: Logged In: YES user_id=929
Now we know which side effects patch-274 has. When it's reverted, the file is processed without error, but margin kerning is missing (which was the original problem before patch-274).
Following experiment is done _with_ patch-274.
The "this can't happen" error happens within the line_break routine, which chokes on a margin_kern_node (which was filtered out before patch-274).If one adds margin_kern_node to the do_nothing list, like:
mark_node,ins_node,adjust_node,margin_kern_node: do_nothing; othercases confusion("paragraph")
it apparently works ok, and margin kerning is fine also (requires patch in hz.ch). But i need to understand how the line_break routine works, whether a do_nothing is the right thing to do...
Regards, Hartmut
----------------------------------------------------------------------
On Thu, 17 Feb 2005, The Thanh Han wrote:
this probably has to do with the issue whether to copy or not margin_kern_node when unboxing a box we discussed a while ago.
Yes, seems so. Meanwhile i have temporarily reverted the status to _before_ patch-274, and then it shows here that even this example \font\testfont=cmr10 \testfont \pdfprotrudechars=2 \rpcode\font`\-=1000 \parindent0pt \hsize=126pt \newbox\testline \newbox\testbox \setbox\testbox\vbox{Margin kerning is the adjustments $\dots$} \setbox\testline=\vsplit\testbox to\baselineskip \unvbox\testline \setbox\testline=\lastbox \unhcopy\testline \bye gives an error: "! This can't happen (paragraph)" (wondering why this case wasn't detected before). So if one goes the way of removing margin_kern_node, it needs to be done _both_ for \unhbox and \unhcopy cases.
I have no idea how to solve it yet. Ignoring margin_kern_node during line-breaking seems to be the right thing to do, but I am afraid it's not enough. Leaving margin_kern_node nodes pass unboxing means that they can end up anywhere, hence we also need to handle them everywhere (which is very fragile).
It looks like after patch-292 one actually would be rather safe against "confusion" cases since it seems that \hboxes anyway can't be unhboxed or unhcopied into a vlist or into a math list; this is caught early by TeX. I couldn't yet find a case, where after patch-292 it would still give such an error. But patch-292 introduces typographic problems, weird breaks, and letters are running into each other, see the catastrophies in the following test file (which should run through smoothly after patch-292): \font\testfont=cmr10 \testfont \pdfprotrudechars=2 \rpcode\font`\-=1000 \parindent0pt \hsize=126pt \newbox\testline \newbox\testbox % \setbox\testbox\vbox{Margin kerning is the adjustments $\dots$} \beginsection --- 1 --- \hrule \copy\testbox \hrule \beginsection --- 2 --- \hrule \setbox\testline=\vsplit\testbox to\baselineskip \unvbox\testline \setbox\testline=\lastbox \line{\unhcopy\testline} ABC \unhcopy\testline XYZ\break \bye \unhcopy\testline\break \unhcopy\testline XYZ \hrule \beginsection --- 3 --- \rlap{\vbox{ \halign{#\unskip\hfil\cr A\cr \unhcopy\testline X\cr \noalign{\hrule} B\cr}}} \beginsection --- 4 --- \rlap{\vbox{ \halign{#\unskip\hfil\cr A\cr Margin kerning is the adjust-\cr Margin kerning is the adjust-C\cr \noalign{\hrule} B\cr}}} \bye And sorting these cases out so that they are right (after one knows what "right" should be) doesn't look straightforward to me. Regards, Hartmut
Hartmut Henkel wrote:
On Thu, 17 Feb 2005, The Thanh Han wrote:
this probably has to do with the issue whether to copy or not margin_kern_node when unboxing a box we discussed a while ago.
Yes, seems so. Meanwhile i have temporarily reverted the status to _before_ patch-274, and then it shows here that even this example
\font\testfont=cmr10 \testfont \pdfprotrudechars=2 \rpcode\font`\-=1000 \parindent0pt \hsize=126pt \newbox\testline \newbox\testbox \setbox\testbox\vbox{Margin kerning is the adjustments $\dots$} \setbox\testline=\vsplit\testbox to\baselineskip \unvbox\testline \setbox\testline=\lastbox \unhcopy\testline \bye
gives an error: "! This can't happen (paragraph)" (wondering why this case wasn't detected before). So if one goes the way of removing margin_kern_node, it needs to be done _both_ for \unhbox and \unhcopy cases.
i wonder where it originates, .\kern-10.00002 (right margin) % prelast node in box .\glue(\rightskip) 0.0 % last node in box the prelast node is only present when protruding; so i suppose that it is the protruding specific node? also, \hbox(6.94444+1.94444)x126.0, glue set 1.20831 the glue set is positive here (negative in non prot case) so, is this kern the troublemaker? Also, fails : \unhcopy\testline succeeds : \unhbox \testline so, maybe the bug is in the copying routine Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (4)
-
Hans Hagen -
Hartmut Henkel -
noreply＠sarovar.org -
The Thanh Han