overlong lines in List of Figures
Damian Menscher
LaTeX, but I wanted to get some extra features on a more recent
version, so I upgraded.
Now I discover that very long figure captions are not line-wrapping
in the List of Figures. Instead, they just stretch the line way out
into the margins. The only thing google found on this was someone
who had long equations there, but I'm seeing this even with relatively
short words, so I think it's a different problem.
latex -v reports I'm using
TeX (Web2C 7.4.5) 3.14159
kpathsea version 3.4.5
Any advice on how to proceed (I've already tried the obvious stuff
like blowing away the .lof file) would be greatly appreciated.
Damian Menscher
--
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <mens...@uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-
Jonathan Fine
> I have a file that printed up just fine under an older version of
> LaTeX, but I wanted to get some extra features on a more recent
> version, so I upgraded.
>
> Now I discover that very long figure captions are not line-wrapping
> in the List of Figures. Instead, they just stretch the line way out
> into the margins. The only thing google found on this was someone
> who had long equations there, but I'm seeing this even with relatively
> short words, so I think it's a different problem.
>
> latex -v reports I'm using
> TeX (Web2C 7.4.5) 3.14159
> kpathsea version 3.4.5
>
> Any advice on how to proceed (I've already tried the obvious stuff
> like blowing away the .lof file) would be greatly appreciated.
First, latex -v is not giving you the information you need.
It is most likely that one of your inputs has changed. But which?
Do you have the log file for a run of the older version of LaTeX?
Or a minimal example that someone else can run?
It would help to know which input is controlling the line-wrapping.
Hope this helps.
--
Jonathan
Damian Menscher
> Damian Menscher wrote:
>> I have a file that printed up just fine under an older version of
>> LaTeX, but I wanted to get some extra features on a more recent
>> version, so I upgraded.
>>
>> Now I discover that very long figure captions are not line-wrapping
>> in the List of Figures. Instead, they just stretch the line way out
>> into the margins. The only thing google found on this was someone
>> who had long equations there, but I'm seeing this even with relatively
>> short words, so I think it's a different problem.
>>
>> latex -v reports I'm using
>> TeX (Web2C 7.4.5) 3.14159
>> kpathsea version 3.4.5
>>
>> Any advice on how to proceed (I've already tried the obvious stuff
>> like blowing away the .lof file) would be greatly appreciated.
> It is most likely that one of your inputs has changed. But which?
No, I am quite certain that the input files are the same. To check,
I just copied a source tree to the old machine and the new machine.
Ran latex 3 times on each, then looked at output using xdvi. Old
machine wrapped the long lines, the new machine did not.
If there is a difference in the input, it's something about the
installation of TeX, not in my document.
> Do you have the log file for a run of the older version of LaTeX?
Yes, but unfortunately it's quite long.
> Or a minimal example that someone else can run?
I'll work on minimizing it.
> It would help to know which input is controlling the line-wrapping.
Of course, that's the key. But I don't know how to figure it out
other than hoping someone recognizes it. FWIW, the .lof file the two
versions created are identical, as are all other files other than the
.log and the .dvi.
About the biggest difference in the .log is that on the old machine
hyperref used driver hypertex, while on the new machine it is using
driver hdvips. I suppose I could check into changing that driver
around (it's not specified in my document, so apparently the machines
simply have different defaults). There are, of course, a lot of
other minor changes in version numbers between all the extra packages
I include. It's going to make this a nightmare to track down, if the
hyperref driver change doesn't solve it. :(
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> wrote:
<snip>
>>It is most likely that one of your inputs has changed. But which?
>
> No, I am quite certain that the input files are the same. To check,
> I just copied a source tree to the old machine and the new machine.
> Ran latex 3 times on each, then looked at output using xdvi. Old
> machine wrapped the long lines, the new machine did not.
>
> If there is a difference in the input, it's something about the
> installation of TeX, not in my document.
It's really helpful that you have the old machine still available.
A difference in your LaTeX installation is exactly what I had in mind.
>>Do you have the log file for a run of the older version of LaTeX?
>
> Yes, but unfortunately it's quite long.
Yes, they do get quite long.
And we need better tools for analysing them.
>>Or a minimal example that someone else can run?
>
> I'll work on minimizing it.
Great. That will help reduce the size of the log file (smile).
>>It would help to know which input is controlling the line-wrapping.
>
> Of course, that's the key. But I don't know how to figure it out
> other than hoping someone recognizes it. FWIW, the .lof file the two
> versions created are identical, as are all other files other than the
> .log and the .dvi.
It is very helpful to eliminate that.
> About the biggest difference in the .log is that on the old machine
> hyperref used driver hypertex, while on the new machine it is using
> driver hdvips.
Well, that's your prime suspect. Well done.
> I suppose I could check into changing that driver
> around (it's not specified in my document, so apparently the machines
> simply have different defaults).
This would be the simplest explanation that could possibly work.
> There are, of course, a lot of
> other minor changes in version numbers between all the extra packages
> I include. It's going to make this a nightmare to track down, if the
> hyperref driver change doesn't solve it. :(
Fingers crossed.
Here's a trick (not tested)
=== testfile.tex
\documentclass{article}
\begin{document}
\def\jobname{realfile}
\listoffigures % (or whatever the command is)
\end{document}
===
The idea is to trick LaTeX into setting the lof in minimal document.
The separates generating the lof from formatting it.
I hope you are now close to the solution.
Please let us know what happens next.
--
Jonathan
Damian Menscher
> Damian Menscher wrote:
>> Jonathan Fine <jf...@pytex.org> wrote:
>>
>> About the biggest difference in the .log is that on the old machine
>> hyperref used driver hypertex, while on the new machine it is using
>> driver hdvips.
>
> Well, that's your prime suspect. Well done.
I think I can elevate it from suspect to culprit. Commenting
out the \usepackage{hyperref} line fixes the lof formatting.
The new (broken) version of hyperref is:
2003/01/22 v6.73n
The old (working) version of hyperref is:
2002/01/14 v6.72d
The changelog at
ftp://tug.ctan.org/pub/tex-archive/macros/latex/contrib/hyperref/ChangeLog
indicates there were a couple of "fixes" to multiline support between
those versions.
>> I suppose I could check into changing that driver
>> around (it's not specified in my document, so apparently the machines
>> simply have different defaults).
> This would be the simplest explanation that could possibly work.
Changing the driver from hdvips to hypertex fixes the line-break issue,
but at the cost of losing all of the hyperlinks!
It's worth noting (for historical purposes) that it also eliminated
some warnings that the hdvips driver had issued:
Package hyperref Warning: Token not allowed in a PDFDocEncoded string:
(hyperref) \hskip 10.95003pt
(hyperref) replaced by space on input line 1.
I can't compare on the older machine, as that one does not accept
hdvips as a hyperref driver option.
> Here's a trick (not tested)
> === testfile.tex
> \documentclass{article}
> \begin{document}
> \def\jobname{realfile}
> \listoffigures % (or whatever the command is)
> \end{document}
> ===
> The idea is to trick LaTeX into setting the lof in minimal document.
> The separates generating the lof from formatting it.
I don't understand the purpose of this, since I've already proven that
the lof files are identical on the two installs.
Anyway, now that the problem has been identified as a buggy hyperref
package, I'm going to try upgrading to the latest version, just in
case something was fixed that isn't shown in the ChangeLog.
Here's a quick proof-of-bug, running on a default install of RHEL4.1:
$ cat demo.tex
\documentclass{book}
\usepackage{hyperref}
\begin{document}
\listoffigures
\begin{figure}
\caption{The quick red fox jumped over the lazy brown dogs, and now is also a good time to come to the aid of your country.}
\end{figure}
\end{document}
$ latex demo
This is TeX, Version 3.14159 (Web2C 7.4.5)
(./demo.tex
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/book.cls
Document Class: book 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/bk10.clo))
(/usr/share/texmf/tex/latex/hyperref/hyperref.sty
(/usr/share/texmf/tex/latex/graphics/keyval.sty)
(/usr/share/texmf/tex/latex/hyperref/pd1enc.def)
(/usr/share/texmf/tex/latex/config/hyperref.cfg)
Implicit mode ON; LaTeX internals redefined
(/usr/share/texmf/tex/latex/html/url.sty))
*hyperref using default driver hdvips*
(/usr/share/texmf/tex/latex/hyperref/hdvips.def
(/usr/share/texmf/tex/latex/hyperref/pdfmark.def)) (./demo.aux)
(/usr/share/texmf/tex/latex/hyperref/nameref.sty) (./demo.out) (./demo.out)
(./demo.lof
Overfull \hbox (219.9177pt too wide) in paragraph at lines 1--1
[][] [] []
) [1] (./demo.aux) )
(see the transcript file for additional information)
Output written on demo.dvi (1 page, 2784 bytes).
Transcript written on demo.log.
Changing the \usepackage line to
\usepackage[hypertex]{hyperref}
does the linewrap properly, but no hyperlink, making the hyperref
package completely useless.
Anyway, I'll try upgrading hyperref tomorrow before filing bug reports.
Donald Arseneau
> Now I discover that very long figure captions are not line-wrapping
> in the List of Figures.
Probably you are using hyperref along with dvips.
Use option [linktocpage]
--
Donald Arseneau as...@triumf.ca
Morten Høgholm
<mensche...@uiuc.edu> wrote:
> I think I can elevate it from suspect to culprit. Commenting
> out the \usepackage{hyperref} line fixes the lof formatting.
> The new (broken) version of hyperref is:
> 2003/01/22 v6.73n
> The old (working) version of hyperref is:
> 2002/01/14 v6.72d
>
> The changelog at
> ftp://tug.ctan.org/pub/tex-archive/macros/latex/contrib/hyperref/ChangeLog
> indicates there were a couple of "fixes" to multiline support between
> those versions.
>
>>> I suppose I could check into changing that driver
>>> around (it's not specified in my document, so apparently the machines
>>> simply have different defaults).
>
>> This would be the simplest explanation that could possibly work.
>
> Changing the driver from hdvips to hypertex fixes the line-break issue,
> but at the cost of losing all of the hyperlinks!
What do you think people who produce a dvi file with latex+hyperref could
possibly want to do with it? Convert it to pdf via dvips+ps2pdf? It makes
perfect sense to have dvips be the default driver in dvi-mode.
Rather than claiming hyperref is buggy one could assume that Heiko
Oberdiek is not a moron and that if a lot of people thought this was a big
problem, it would have been fixed by now.
> Changing the \usepackage line to
> \usepackage[hypertex]{hyperref}
> does the linewrap properly, but no hyperlink, making the hyperref
> package completely useless.
Pretty good reason to use the dvips driver then.
--
Morten
Ulrike Fischer
> I think I can elevate it from suspect to culprit. Commenting
> out the \usepackage{hyperref} line fixes the lof formatting.
> The new (broken) version of hyperref is:
> 2003/01/22 v6.73n
> The old (working) version of hyperref is:
> 2002/01/14 v6.72d
>
hyperref isn't broken. dvips can't break links and so hyperref doesn't
break them if you use the driver dvips.
Use breakurl.sty or linktocpage like Donald suggested.
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=breaklinks
--
Ulrike Fischer
e-mail: zusätzlich meinen Vornamen vor dem @ einfügen.
e-mail: add my first name between the news and the @.
Jonathan Fine
> On Fri, 23 Sep 2005 10:07:07 +0200, Damian Menscher
> <mensche...@uiuc.edu> wrote:
>
>
>> I think I can elevate it from suspect to culprit. Commenting
>> out the \usepackage{hyperref} line fixes the lof formatting.
>> The new (broken) version of hyperref is:
>> 2003/01/22 v6.73n
>> The old (working) version of hyperref is:
>> 2002/01/14 v6.72d
<snip>
> Rather than claiming hyperref is buggy one could assume that Heiko
> Oberdiek is not a moron and that if a lot of people thought this was a
> big problem, it would have been fixed by now.
This is, in my opinion, completely uncalled for.
The original poster worked diligently to solve his own problem.
And succeeded. (Well done, Damian.)
He did not mention Heiko, nor call him a moron.
(Which he is not.)
It seems to me that the user knows what he wants.
And that for him the old version works, and the new is broken.
BTW, the old version works because it breaks ... lines.
BTW, there are many big problems that have not been fixed.
--
Jonathan
Heiko Oberdiek
> And that for him the old version works, and the new is broken.
Nonsense. The default driver is the same exactly. But it
can now be controlled by the configuration file. My recommendation
is to use "dvips" instead of "hypertex", because most people
seem and want to use dvips and ps2pdf.
If the OP doesn't want to have "dvips" he can adjust his
configuration file "hyperref.cfg" to his needs.
> BTW, the old version works because it breaks ... lines.
The programm dvips does not support broken links.
Other do (pdfTeX, dvipdfm).
| Workarounds:
| * For long section or caption titles in the table of contents
| or list of figures/tables option "linktocpage" can be used.
| Then the page number will be a link, and the overlong section
| title is not forced into an one line link with overvull \hbox
| warning.
| * "\url"s are catched by package "breakurl".
| * The option "breaklinks" is intended for internal use. But it
| can be used to force link wrapping, e.g. when printing a
| document. However, when such a document is converted to PDF
| and viewed with a PDF viewer, the active link area will be
| misplaced.
| Another limitation: some penalties are "optimized" by TeX,
| thus there are missing break points, especially within
| \url. (See thread "hyperref.sty, breaklinks and url.sty 3.2"
| in comp.text.tex 2005-09).
> BTW, there are many big problems that have not been fixed.
For example, look at the thread
"hyperref.sty, breaklinks and url.sty 3.2.".
Perhaps you have an idea to get rid of TeX's limitation
without going into the sources of TeX.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Damian Menscher
> Morten Hogholm wrote:
>> On Fri, 23 Sep 2005 10:07:07 +0200, Damian Menscher
>> <mensche...@uiuc.edu> wrote:
>>
>>> I think I can elevate it from suspect to culprit. Commenting
>>> out the \usepackage{hyperref} line fixes the lof formatting.
>>> The new (broken) version of hyperref is:
>>> 2003/01/22 v6.73n
>>> The old (working) version of hyperref is:
>>> 2002/01/14 v6.72d
>>
>> Oberdiek is not a moron and that if a lot of people thought this was a
>> big problem, it would have been fixed by now.
> This is, in my opinion, completely uncalled for.
> The original poster worked diligently to solve his own problem.
> And succeeded. (Well done, Damian.)
Well, mostly succeeded, anyway, with some helpful suggestions from this
group. I am now using
\usepackage[breaklinks,draft=false]{hyperref}
\usepackage{breakurl}
and things seem to be mostly working with latex + dvipdf.
> It seems to me that the user knows what he wants.
> And that for him the old version works, and the new is broken.
Well, I was awfully confused because I'm not exactly an expert on the
difference between dvipdf and dvipdfm and so on. And I still don't
feel that I understand what's going on, but at least now I seem to be
able to produce reasonable output (which was a LOT harder than it
should have been!).
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> wrote:
<snip>
>>BTW, there are many big problems that have not been fixed.
>
>
> For example, look at the thread
> "hyperref.sty, breaklinks and url.sty 3.2.".
There's no 'sty' in the thread subject
Here's a google url for the thread.
<http://groups.google.co.uk/group/comp.text.tex/msg/c2115e1752db7bd9?hl=en&>
> Perhaps you have an idea to get rid of TeX's limitation
> without going into the sources of TeX.
It's not clear to me what the limitation might be.
But I'd be happy to discuss the matter.
Heiko, you're the maintainer of hyperref.sty.
Suppose the discussion finds a way to solve the problem.
Would you then be willing to make changes to hyperref?
--
Jonathan
Heiko Oberdiek
> Heiko Oberdiek wrote:
>
> > Perhaps you have an idea to get rid of TeX's limitation
> > without going into the sources of TeX.
>
> It's not clear to me what the limitation might be.
> But I'd be happy to discuss the matter.
http://groups.google.co.uk/group/comp.text.tex/msg/c3de369460238d05
> Heiko, you're the maintainer of hyperref.sty.
> Suppose the discussion finds a way to solve the problem.
> Would you then be willing to make changes to hyperref?
It depends on the solution of course.
(quality of solution, compatibility, maintenance, ...)
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> wrote:
>
>
>>Heiko Oberdiek wrote:
>>
>>
>>>Perhaps you have an idea to get rid of TeX's limitation
>>>without going into the sources of TeX.
>>
>>It's not clear to me what the limitation might be.
>>But I'd be happy to discuss the matter.
>
>
> http://groups.google.co.uk/group/comp.text.tex/msg/c3de369460238d05
This states, correctly, that in an \hbox TeX does not insert implicit
math penalties.
Here's an example of omitted implicit penalties.
===
*\setbox0 \hbox{$2 + 2 = 4$}
*\showbox 0
{\showbox}
> \box0=
\hbox(6.44444+0.83333)x40.5554
.\mathon
.\tenrm 2
.\glue(\medmuskip) 2.22217 plus 1.11108 minus 2.22217
.\tenrm +
.\glue(\medmuskip) 2.22217 plus 1.11108 minus 2.22217
.\tenrm 2
.\glue(\thickmuskip) 2.77771 plus 2.77771
.\tenrm =
.\glue(\thickmuskip) 2.77771 plus 2.77771
.\tenrm 4
.\mathoff
===
This optimisation can be avoided. Set the material in a paragraph.
===
$ cat mathpenalty.tex
\setbox0 \vbox{\noindent $2 + 2 = 4$}
\setbox0 \vbox{
\unvbox 0
\global\setbox 1 \lastbox
}
\setbox 0 \hbox{%
\unhbox 1
\unskip
\unskip
\unpenalty
}
\tracingall
\tracingonline = 1
\nonstopmode
\showbox 0
\end
$ tex mathpenalty.tex
This is TeX, Version 3.14159 (Web2C 7.4.5)
(./mathpenalty.tex
<snip>
{\showbox}
> \box0=
\hbox(6.44444+0.83333)x40.5554
.\mathon
.\tenrm 2
.\glue(\medmuskip) 2.22217 plus 1.11108 minus 2.22217
.\tenrm +
.\penalty 700
.\glue(\medmuskip) 2.22217 plus 1.11108 minus 2.22217
.\tenrm 2
.\glue(\thickmuskip) 2.77771 plus 2.77771
.\tenrm =
.\penalty 500
.\glue(\thickmuskip) 2.77771 plus 2.77771
.\tenrm 4
.\mathoff
! OK.
l.16 \showbox 0
{\end}
)
(see the transcript file for additional information)
No pages of output.
Transcript written on mathpenalty.log.
===
There we are. A math \hbox, with implicit penalties.
>>Heiko, you're the maintainer of hyperref.sty.
>>Suppose the discussion finds a way to solve the problem.
>>Would you then be willing to make changes to hyperref?
>
> It depends on the solution of course.
> (quality of solution, compatibility, maintenance, ...)
So there's my solution. What do you say?
--
Jonathan
Heiko Oberdiek
> This optimisation can be avoided. Set the material in a paragraph.
>
> ===
> $ cat mathpenalty.tex
> \setbox0 \vbox{\noindent $2 + 2 = 4$}
> \setbox0 \vbox{
> \unvbox 0
> \global\setbox 1 \lastbox
> }
> \setbox 0 \hbox{%
> \unhbox 1
> \unskip
> \unskip
> \unpenalty
> }
Good idea, but this mechanism fails if the stuff is set in more than
one line (eg. overlong url). Perhaps it helps to set \hsize to
\maxdimen.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Donald Arseneau
> Good idea, but this mechanism fails if the stuff is set in more than
> one line (eg. overlong url). Perhaps it helps to set \hsize to
> \maxdimen.
Something like...
Use \spbox something like \setbox.
\spbox <box_number>{contents}
It makes an \hbox appropriate for \unhboxing, by typesetting
material in a paragraph. Some things are not handled:
\vadjust, $$, etc.
\newbox\spb@gbox
\def\spbox{% Get user's box number:
\afterassignment\spb@A\mathchardef\spb@box
}
% We read the balanced text as a macro argument, so different from \setbox.
\long\def\spb@A#1{\setbox\spb@box\vbox{%
\hsize\maxdimen
\pretolerance\m@ne
\@parboxrestore
\let\par\relax
\parfillskip \fill
\noindent #1 \@@par
\unskip\unpenalty\unkern
\setbox\spb@box\lastbox
\unskip\unpenalty\unkern
\global\setbox\spb@gbox\hbox{\unhbox\spb@box\unskip\unskip\unpenalty}%
}%
\setbox\spb@box\box\spb@gbox
}
--
Donald Arseneau as...@triumf.ca
Jonathan Fine
Heiko was complaining that TeX did not have a suitable _primitive_.
In my previous post I showed how one could work around it.
Thank you, Heiko, for point out the need to set \hsize.
Donald has developed my solution, and wrapped it as a macro.
And added a LaTeX'ism or two. Such as \@parboxrestore.
And I'd like to know why the \unkern is required.
Here's the way I would wrap it. If we
\let \innerbox \hbox
then the macro provides an \outerbox macro that behaves
somewhat like an \outerbox _primitive_ in an extension of
TeX.
===
\long\def\outerbox #1%
% like \hbox, but sets material in outer horizontal mode
% #1 - horizontal material, to be set in outer horizontal mode
% Note: inappropriate commands in #1 can cause an \outerboxerror
{%
\hbox{%
\setbox0 \vbox{%
\hsize\maxdimen
\pretolerance -1
\rightskip 0pt
\parfillskip 0pt plus 1fil
\noindent #1\endgraf
\global\setbox1 \lastbox
}%
% check that size of \box 0 is 0.0+0.0x0.0
\ifcase
% skip to \else if any dimension is non-zero
\ifcase\wd0 \else 1 \fi
\ifcase\ht0 \else 1 \fi
\ifcase\dp0 \else 1 \fi
0 % satisfy the \ifcase
%
% place material into \hbox
\unhbox 1
\unskip % remove \rightskip glue
\unskip % remove \parfillskip glue
\unpenalty % remove paragraph ending \penalty 10000
\else
% there's something left in \box 0
\outerboxerror % default handler is to be \undefined
\fi
}%
}
===
(The \ifcase trickery is in fact an OR statement.)
Here are some use cases
===
\tracingall
\tracingonline = 1
% \nonstopmode
\setbox 0 \hbox{$2+2=2$} \showbox 0
\setbox 0 \outerbox{$2+2=2$} \showbox 0
\setbox 0 \outerbox{a\par b} \showbox 0
===
Jonathan Fine
<snip>
> ===
> \long\def\outerbox #1%
> % like \hbox, but sets material in outer horizontal mode
> % #1 - horizontal material, to be set in outer horizontal mode
> % Note: inappropriate commands in #1 can cause an \outerboxerror
> {%
> \hbox{%
> \setbox0 \vbox{%
> \hsize\maxdimen
> \pretolerance -1
> \rightskip 0pt
One must also set \leftskip to zero.
For example, look at
{ \leftskip 1in \setbox0\outerbox{x}\showbox 0 }
There may be more such mistakes.
--
Jonathan
Heiko Oberdiek
In real live (LaTeX), \color@begingroup and
\color@endgroup must be added, because
color commands can emit \aftergroup macros.
And the color \special{} need to be set in
horizontal mode, too. Otherwise the method
would be seriously disturbed by the additional
\special{} nodes in the vertical list.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Donald has developed my solution, and wrapped it as a macro.
Thank you both for developing the method.
> And added a LaTeX'ism or two. Such as \@parboxrestore.
> And I'd like to know why the \unkern is required.
What happens, if #1 is empty? Then "\noindent\@@par" does not generate
a paragraph. Thus I think, Donald has added a space after #1 to
ensure, there is something that end up as line.
To have some error checking is a good idea. However you can
put whole pages into boxes with dimensions 0.0+0.0x0.0.
(If the dimensions are violated, we have an error.
On the other hand, a box with 0.0+0.0x0.0 does not
proof that there isn't an error.)
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Donald Arseneau
> Jonathan Fine <jf...@pytex.org> wrote:
> > Donald Arseneau wrote:
> > > Heiko Oberdiek <ober...@uni-freiburg.de> writes:
> > > \def\spbox{% Get user's box number:
> > > \afterassignment\spb@A\mathchardef\spb@box
That is a vestige of originally targetting a \setbox equivalence,
which I abandoned, so it should probably just be
\newcommand\spbox[2]
or \newcommand* to give errors on unintended \par in the arg.
There are more things to set, as I do in shapepar.sty (redefine
\vadjust, set \everydisplay to give an error...).
> > > \@parboxrestore
Yes, just a collection of the settings that we need, so I used it.
One could easily make the settings explicitly here for plain TeX.
> > And I'd like to know why the \unkern is required.
Just paranoia, should a kern get there. In other cases I've done:
\unskip\unkern\unskip\unpenalty
and
\unskip\unkern\unpenalty\unskip\unkern\unpenalty
> > > \noindent #1 \@@par
> What happens, if #1 is empty? Then "\noindent\@@par" does not generate
> a paragraph. Thus I think, Donald has added a space after #1 to
> ensure, there is something that end up as line.
More generally, it prevents the \par from eating terminal glue from #1.
You wouldn't want {\hspace{5in}} to give a measurement of zero!
--
Donald Arseneau as...@triumf.ca
Jonathan Fine
<snip>
>>Donald has developed my solution, and wrapped it as a macro.
>
> Thank you both for developing the method.
I hope that when finished it will be used where appropiate.
For example, hyperref.sty.
> What happens, if #1 is empty? Then "\noindent\@@par" does not generate
> a paragraph. Thus I think, Donald has added a space after #1 to
> ensure, there is something that end up as line.
Heiko, this you can find out for yourself.
But as I did not know for sure, I've done it myself.
===
> \box0=
\hbox(0.0+0.0)x0.0
! OK.
l.90 \setbox 0 \outerbox{} \showbox 0
?
===
This is indeed what we want.
<snip>
> To have some error checking is a good idea. However you can
> put whole pages into boxes with dimensions 0.0+0.0x0.0.
> (If the dimensions are violated, we have an error.
> On the other hand, a box with 0.0+0.0x0.0 does not
> proof that there isn't an error.)
I was not claimed that the error-checking was immune against
devious attack. Or that there was a proof of its completeness.
I think the error checking is sufficent. If you doubt this,
please construct an example where the error checking is not
sufficient.
--
Jonathan
Jonathan Fine
These are _LaTeX_ commands. As so they should be added
_by LaTeX_.
By the way, colored/virtual fonts provide another way of
doing color. Which is, in my opinion, much better. (Which
is why I develop it.)
My objective is to write a macro that emulates a primitive
in an extension to TeX.
Additions such as you suggest would violate the documentation
>>>\long\def\outerbox #1%
>>>% like \hbox, but sets material in outer horizontal mode
>>>% #1 - horizontal material, to be set in outer horizontal mode
>>>% Note: inappropriate commands in #1 can cause an \outerboxerror
If you wish to make such additions, please suggest a revision to the
documentation (specification) first.
However, I think such additions are a very bad idea. They result in
'everything knowing about everything else', and complicate
testing.
--
Jonathan
Jonathan Fine
<snip>
> That is a vestige of originally targetting a \setbox equivalence,
> which I abandoned, so it should probably just be
> \newcommand\spbox[2]
> or \newcommand* to give errors on unintended \par in the arg.
What do you think of my syntax, that \outerhbox be roughly
equivalent to \hbox?
BTW, previously I wrote \outerbox. This is a mistake.
It should be \outerhbox.
> There are more things to set, as I do in shapepar.sty (redefine
> \vadjust, set \everydisplay to give an error...).
Why does \outerhbox need these things? Please give an example.
<snip>
> Yes, just a collection of the settings that we need, so I used it.
> One could easily make the settings explicitly here for plain TeX.
I'd like examples of wrong output before making additions to the
code. As I said, I want to create something that emulates a
primitive. So it cannot know anything about LaTeX, for example.
>>>And I'd like to know why the \unkern is required.
>>
>
> Just paranoia, should a kern get there. In other cases I've done:
>
> \unskip\unkern\unskip\unpenalty
>
> and
>
> \unskip\unkern\unpenalty\unskip\unkern\unpenalty
I'd rather get it right than add \unxxx commands 'just in case'.
Do that, and sooner or later they'll bite off something they
should not.
<snip>
> More generally, it prevents the \par from eating terminal glue from #1.
> You wouldn't want {\hspace{5in}} to give a measurement of zero!
This I accept. It is an error - see below.
==
> \box0=
\hbox(0.0+0.0)x0.0
! OK.
l.91 \setbox 0 \outerbox{\ } \showbox 0
==
--
Jonathan
Heiko Oberdiek
> Heiko Oberdiek <ober...@uni-freiburg.de> writes:
>
> > Jonathan Fine <jf...@pytex.org> wrote:
> > > Donald Arseneau wrote:
> > > > Heiko Oberdiek <ober...@uni-freiburg.de> writes:
> > > > \def\spbox{% Get user's box number:
> > > > \afterassignment\spb@A\mathchardef\spb@box
>
> That is a vestige of originally targetting a \setbox equivalence,
> which I abandoned, so it should probably just be
> \newcommand\spbox[2]
> or \newcommand* to give errors on unintended \par in the arg.
>
> There are more things to set, as I do in shapepar.sty (redefine
> \vadjust, set \everydisplay to give an error...).
Unhappily \vadjust, \par, ... are perfectly legal in an \hbox, they
can be used in a \vbox inside the \hbox.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Donald Arseneau
> Donald Arseneau wrote:
>
> What do you think of my syntax, that \outerhbox be roughly
> equivalent to \hbox?
It's good.
> > There are more things to set, as I do in shapepar.sty (redefine
> > \vadjust, set \everydisplay to give an error...).
>
> Why does \outerhbox need these things? Please give an example.
First, I wasn't talking about \outerbox. Moreover, it is not true that
"Donald has developed my solution, and wrapped it as a macro." (Guffaw!)
Second, the reason \outerhbox could use such niceties is to be user-
friendly... unless you think
\outerboxerror % default handler is to be \undefined
(used for all types of failure) is the epitome of helpful interaction.
> > [\@parboxrestore] just a collection of the settings that we need,
> > so I used it. One could easily make the settings explicitly here
> > for plain TeX.
>
> I'd like examples of wrong output before making additions to the
> code.
Where does that come from??? \@parboxrestore encapsulates the settings
\leftskip=0pt \rightskip=0pt \everypar{} \parfillskip=0pt plus 1fil,
all of which are used even in your \outerbox, plus others that need to
be included for LaTeX. It isn't to fix "wrong output", it is a
convenient shorthand.
> As I said, I want to create something that emulates a
> primitive. So it cannot know anything about LaTeX, for example.
Definitely, son't use LaTeX internals if you want a more generic macro.
It is nonsense to call it a "primitive" though, or emulating a primitive.
(You'll never fix the expandability difference, but it might be possible
to allow box-syntax for delimiting the text. Use a \vbox to gather the
argument!)
\def\outerhbox{\hbox\bgroup \afterassignment\OBsetup \setbox0 \vbox}
\def\OBsetup{%
\aftergroup\OBfinish
\hsize\maxdimen
\pretolerance -1
\rightskip 0pt \leftskip\rightskip
\everypar{}%
\parfillskip 0pt plus 1fil
\noindent
}
\def\OBfinish{%
\setbox0 \vbox{\unvbox0 \global\setbox1 \lastbox}%
\tracingall\showbox1
...etc...
\egroup
}
But that prevents the "#1 \endgraf" trick to preserve glue. Maybe you have
a solution for that while still allowing
\outerbox\bgroup...\egroup
\def\outerbox{\hbox\bgroup \afterassignment\OBsetup \setbox0 \vbox}
\global\setbox1 \lastbox
> I'd rather get it right than add \unxxx commands 'just in case'.
Depends on the definition of "right"! You are welcome to declare \vadjust
is a fatal error in your macro, and then die, but I prefer not to.
I am just sorry that there are inocuous items (whatzits) that break the
\lastbox and can't be passed through.
> Do that, and sooner or later they'll bite off something they
> should not.
Your macro bites too. It is quite feasible for diasllowed vertical
material to remain, yet give zero size to box 0. When sifting through
a vbox I usually use a "unique" marker at the top, which can be
tested.
--
Donald Arseneau as...@triumf.ca
Heiko Oberdiek
> Additions such as you suggest would violate the documentation
> >>>\long\def\outerbox #1%
> >>>% like \hbox, but sets material in outer horizontal mode
> >>>% #1 - horizontal material, to be set in outer horizontal mode
> >>>% Note: inappropriate commands in #1 can cause an \outerboxerror
>
> If you wish to make such additions, please suggest a revision to the
> documentation (specification) first.
>
> However, I think such additions are a very bad idea. They result in
> 'everything knowing about everything else', and complicate
> testing.
\par is silently ignored in an \hbox. Now \hbox{...} should
be replaced by something that generates an error message then.
Therefore this is a (real?) problem.
Because this cannot be handled, this is a limitation of the
method.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Heiko Oberdiek wrote:
> > Jonathan Fine <jf...@pytex.org> wrote:
> >>Donald Arseneau wrote:
>
> <snip>
>
> >>Donald has developed my solution, and wrapped it as a macro.
> >
> > Thank you both for developing the method.
>
> I hope that when finished it will be used where appropiate.
I have prepared a package that merges code and ideas from
us and will mail it to you and Donald. (266 lines are probably
too long for the newsgroup). I intend to put it on CTAN.
> For example, hyperref.sty.
It is very difficult to decide, because it is not just an improvement.
There can be situations, where error messages are generated.
I don't think that the "normal" user will follow the theory behind
these error messages. And I don't want to have an option.
Writing documentation for it would be a nightmare.
Therefore, when I go back to the sources of pdfTeX,
I want to try a switch first that disables the problematic
optimization of TeX. If this succeeds I would have a solution
that improves the current situation without adding new disadvantages.
> > To have some error checking is a good idea. However you can
> > put whole pages into boxes with dimensions 0.0+0.0x0.0.
> > (If the dimensions are violated, we have an error.
> > On the other hand, a box with 0.0+0.0x0.0 does not
> > proof that there isn't an error.)
Error checking is easy with eTeX: \lastnodetype
I have used it in the package, if eTeX is available.
Otherwise Jonathan's dimensions checks combinded
with Donald's marker method are used.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Donald Arseneau
> I want to try a switch first that disables the problematic
> optimization of TeX.
I think that is an important request for e-TeX too.
--
Donald Arseneau as...@triumf.ca
Morten Høgholm
> Heiko Oberdiek <ober...@uni-freiburg.de> writes:
>
>> I want to try a switch first that disables the problematic
>> optimization of TeX.
>
> I think that is an important request for e-TeX too.
Write Thanh, he'll probably look at it.
--
Morten
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> wrote:
>
>
>>Heiko Oberdiek wrote:
>>
>>>Jonathan Fine <jf...@pytex.org> wrote:
>>>
>>>>Donald Arseneau wrote:
>>>
>><snip>
>>
>>>>Donald has developed my solution, and wrapped it as a macro.
>>>
>>>Thank you both for developing the method.
>>
>>I hope that when finished it will be used where appropiate.
>
>
> I have prepared a package that merges code and ideas from
> us and will mail it to you and Donald. (266 lines are probably
> too long for the newsgroup). I intend to put it on CTAN.
<snip>
I was busy all yesterday, and did not see this posting until now.
Heiko, I am both flattered and offended.
I am flattered, and pleased, that you wish to take my idea
forward. And, I hope, use it in hyperref.
I am offended that you are doing what I should be doing.
The definition of \outerhbox that I posted earlier is now
in the style file outerhbox.sty, which I've uploaded to CTAN.
I welcome bug reports, and suggestions for improvements.
--
Jonathan
David Kastrup
> Heiko, I am both flattered and offended.
>
> I am flattered, and pleased, that you wish to take my idea
> forward. And, I hope, use it in hyperref.
>
> I am offended that you are doing what I should be doing.
Just send everybody willing to commit similar offenses over to me. I
can make use of a _lot_ of people doing what I should be doing, and
won't be offended at all.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
Robin Fairbairns
>Heiko Oberdiek wrote:
>> I have prepared a package that merges code and ideas from
>> us and will mail it to you and Donald. (266 lines are probably
>> too long for the newsgroup). I intend to put it on CTAN.
>
><snip>
>
>I was busy all yesterday, and did not see this posting until now.
>
>Heiko, I am both flattered and offended.
>
>I am flattered, and pleased, that you wish to take my idea
>forward. And, I hope, use it in hyperref.
>
>I am offended that you are doing what I should be doing.
it would be silly for you to mail yourself, which is what heiko would
appear to have done so far.
>The definition of \outerhbox that I posted earlier is now
>in the style file outerhbox.sty, which I've uploaded to CTAN.
>
>I welcome bug reports, and suggestions for improvements.
i note you don't care to credit heiko and donald in your upload
announcement. i wonder if they're offended that you're claiming joint
work as your own.
--
Robin (http://www.tex.ac.uk/faq) Fairbairns, Cambridge
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
<snip>
>>The definition of \outerhbox that I posted earlier is now
>>in the style file outerhbox.sty, which I've uploaded to CTAN.
>>
>>I welcome bug reports, and suggestions for improvements.
>
> i note you don't care to credit heiko and donald in your upload
> announcement.
I agree that it would have been better if I had. They both made
useful and helpful comments.
However, I think that they will both agree that the main idea
was mine.
Donald, Heiko: If you do not, please send me an email.
I hope in a later revision of the file to document better
the origin of the key ideas.
> i wonder if they're offended that you're claiming joint
> work as your own.
I would not describe what happened as joint work, although
it certainly was co-operation (as opposed to indifference
or worse).
If Heiko or Donald are offended, please would they let me
know. I do want to be on good terms with them.
I also want to be on good terms with you, Robin.
--
Jonathan