Re: [NTG-pdftex] why is TeX breaking the line?
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi Péter, Szabo Peter wrote:
Dear Taco,
Do you have an idea why TeX is breaking the line at the \discretionary in the source file below, thus producing an Overfull \hbox -- but if it hadn't broken the line there, there would be no overfull boxes?
If you don't know the answer, could you please recommend a forum or mailing list?
CC the pdftex mailing list, perhaps Thanh or Bernd knows, even though it is not really a pdfTeX question. To me, it looks like it may even be a bug. Greetings, Taco
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Oops, sorry, I sent the wrong file. Taco
![](https://secure.gravatar.com/avatar/39c2e81c07187f15629693891664005b.jpg?s=120&d=mm&r=g)
An early Pascal reference implementation of TeX (V3.1415b) demonstrates exactly the same behaviour, and the behaviour can be demonstrated using a simpler example :
\vbox \bgroup \hsize=100 pt \noindent ............................ . {C} z z z\par \noindent ............................ . \discretionary {AAAAAA}{BBBBBBBBB}{C} z z z\par \egroup \end
I am as much at a loss as Taco to explain this. Philip Taylor -------- Taco Hoekwater wrote:
Oops, sorry, I sent the wrong file.
Taco
------------------------------------------------------------------------
%\hyphenpenalty=-1000 %\exhyphenpenalty=-1000
\vbox{\hsize=100pt \hrule width\hsize \noindent....................................\par \noindent............................... \discretionary{A}{B}{CCCCCC}\par \noindent............................ . \discretionary{AAAAAA}{BBBBBBBBB}{C} z z z\par \noindent............................ . C z z z\par } \end
![](https://secure.gravatar.com/avatar/c4fb1aecd98bbaa9856f8c421db294e0.jpg?s=120&d=mm&r=g)
On Tue, Oct 17, 2006 at 05:18:23PM +0100, Philip TAYLOR wrote:
\vbox \bgroup \hsize=100 pt \noindent ............................ . {C} z z z\par \noindent ............................ . \discretionary {AAAAAA}{BBBBBBBBB}{C} z z z\par \egroup \end
I am as much at a loss as Taco to explain this.
At least a smaller example (without different
spacefactors -- \discretionary does not change the spacefactor):
\tracingparagraphs=1
\nopagenumbers
\parindent=0pt
\setbox0=\hbox{C}
\hsize=\wd0
C\par
\discretionary{AA}{BB}{C}\par
\bye
Or
\tracingparagraphs=1
\nopagenumbers
\parindent=0pt
\setbox0=\hbox{ff}
\hsize=\wd0
ff\par
\discretionary{f-}{f}{ff}\par
\bye
Also \pretolerance=10000 doesn't help.
Yours sincerely
Heiko
![](https://secure.gravatar.com/avatar/ad5afbb91c8b5ec2b1199838461a8348.jpg?s=120&d=mm&r=g)
On Tue, 17 Oct 2006, Heiko Oberdiek wrote:
At least a smaller example (without different spacefactors -- \discretionary does not change the spacefactor):
\tracingparagraphs=1 \nopagenumbers \parindent=0pt \setbox0=\hbox{C} \hsize=\wd0
C\par
\discretionary{AA}{BB}{C}\par
\bye
yet another one (but not any idea): \tracingparagraphs=1 \nopagenumbers \parindent=0pt \setbox0=\hbox{C} \hsize=\wd0 C\par \discretionary{I}{W}{C}\par \discretionary{W}{I}{C}\par \bye Regards, Hartmut
![](https://secure.gravatar.com/avatar/9e26317de438b57b29863b88e2471ad2.jpg?s=120&d=mm&r=g)
Heiko Oberdiek wrote:
At least a smaller example (without different spacefactors -- \discretionary does not change the spacefactor):
\tracingparagraphs=1 \nopagenumbers \parindent=0pt \setbox0=\hbox{C} \hsize=\wd0
C\par
\discretionary{AA}{BB}{C}\par
\bye
Hi, I have made a variant of the example: \parindent=0pt \setbox0=\hbox{C} \hsize=\wd0%\advance\hsize7.8pt C\par \discretionary{AA}{BBB}{C}\par \bye TeX reports an overfull box of 7.7778pt for the AAs. If I advance the hsize by something less than this then the effect remains. If I advance the hsize by more (as included in comments above) the effect disappears and C is typeset. I concluded that in the handling of discretionaries the comparison is made against a width containing the width of pre_break instead of the replacement text. This seems to be a bug in TeX. I have traced it down to section 869. There the sum of the width of the nodes of pre_break is added to act_width. If I replace the first loop with a construction similar to the second loop the problem seems to disappear. I do not claim that I have completely understood what's going on. I just wanted to share my insights. Ciao Gerd
participants (5)
-
Gerd Neugebauer
-
Hartmut Henkel
-
Heiko Oberdiek
-
Philip TAYLOR
-
Taco Hoekwater