ANN: outerhbox.sty - collect horizontal material, for unboxing into a paragraph
Jonathan Fine
<http://cvs.sourceforge.net/viewcvs.py/pytex/pytex/texmacros/outerhbox.sty?view=markup>
and has been uploaded to CTAN
Collects horizontal mode material into an \hbox, suitable for later
\unhbox'ing into a paragraph. For use with plain, LaTeX, ConTeXt, etc.
Provides \outerhbox, which is roughly similar to \hbox, except that
material is set in outer horizontal mode. This prevents TeX from
optimising away math penalties and the like, that are needed when the
material is \unhbox'ed.
Donald Arseneau and Heiko Oberdiek have made useful comments during
the development of this package.
Based on code I posted to comp.text.tex
Message-ID: <43399D5...@pytex.org>
Date: Tue, 27 Sep 2005 20:28:26 +0100
Newsgroups: comp.text.tex
Subject: Re: overlong lines in List of Figures
<http://groups.google.com/group/comp.text.tex/msg/56ea490ad6d13dae>
--
Jonathan
David Kastrup
> This package is available from sourceforge
> <http://cvs.sourceforge.net/viewcvs.py/pytex/pytex/texmacros/outerhbox.sty?view=markup>
> and has been uploaded to CTAN
>
>
> Collects horizontal mode material into an \hbox, suitable for later
> \unhbox'ing into a paragraph. For use with plain, LaTeX, ConTeXt, etc.
>
> Provides \outerhbox, which is roughly similar to \hbox, except that
> material is set in outer horizontal mode. This prevents TeX from
> optimising away math penalties and the like, that are needed when the
> material is \unhbox'ed.
I took a look at it. Unfortunately, unsuitable for my purposes. The
following are the shortcomings (probably pretty much inherent to TeX):
a) it only works up to a total length of \maxdimen. Less than 50
lines of text, about a page of material, will bust it.
b) it does not work with explicit line breaks.
c) it does not work with marks, insertions, vadjusts.
In short: it does not appear useful except for academic purposes.
Apropos academic: this has already been treated in EDMAC, and you'll
find in ednotes' mfparptc.sty the following reference:
% (EDMAC.doc refers to Michael Downes, `Line breaking in \unhboxed
% Text', TUGboat 11 (1990), pp. 605--612.)
Personally, I consider the road taken infeasible. And that is because
I can't see any way to cure all of the three above points. EDMAC and
relatives try to cater at least for point b, but in a way I can't find
satisfactory. You'd have to disable hyphenation, and in fact any
discretionary breaks, to make point a work, and then you'd have to
reassemble possible multiple lines, and there is no way to get back
the post-break material. And c is simply hopeless.
One also has to note that the motivation to do this is not as strong
as the references would indicate: language switching nodes _are_
inserted into the list, and so are discretionaries, except for
discretionaries for explicit hyphen characters, and you can turn those
into active characters if you really must, which might help in a few
cases.
So I'd recommed you take a look at the work done 15 years ago. It is
quite more advanced than what you are trying to do here, and still I
consider it unsuitable except in very restricted circumstances.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
>
>
>>This package is available from sourceforge
>><http://cvs.sourceforge.net/viewcvs.py/pytex/pytex/texmacros/outerhbox.sty?view=markup>
>>and has been uploaded to CTAN
>>
>>
>>Collects horizontal mode material into an \hbox, suitable for later
>>\unhbox'ing into a paragraph. For use with plain, LaTeX, ConTeXt, etc.
>>
>>Provides \outerhbox, which is roughly similar to \hbox, except that
>>material is set in outer horizontal mode. This prevents TeX from
>>optimising away math penalties and the like, that are needed when the
>>material is \unhbox'ed.
>
>
> I took a look at it. Unfortunately, unsuitable for my purposes. The
> following are the shortcomings (probably pretty much inherent to TeX):
>
> a) it only works up to a total length of \maxdimen. Less than 50
> lines of text, about a page of material, will bust it.
> b) it does not work with explicit line breaks.
> c) it does not work with marks, insertions, vadjusts.
Work arounds exist for these problems.
a) Don't accumulate so much material all at once.
b) Modify the method to produce several lines of material.
c) As with (b).
> In short: it does not appear useful except for academic purposes.
Well, it was (and maybe still is) used in production by the AMS.
Who are a major league TeX-based math publisher.
Sorry it doesn't work for your problems.
> Apropos academic: this has already been treated in EDMAC, and you'll
> find in ednotes' mfparptc.sty the following reference:
>
> % (EDMAC.doc refers to Michael Downes, `Line breaking in \unhboxed
> % Text', TUGboat 11 (1990), pp. 605--612.)
<snip>
David, thank you very much for this reference.
I read Michael's article when it came out, but since then it
probably slipped my mind. (BTW, Michael made many great
contributions to the TeX community. I know the only one that
misses him, now that he is no longer with us.)
Anyway, Michael came up against the same problem. And he
wrote to Don Knuth. "In response Knuth outlined an
interesting alternative: If instead of a \hbox you use a
\vbox with \hsize set to \maxdimen [...]".
And then the process is as in \unouterhbox.
BTW, Michael's article also covers the issue you raise, of
explicit line breaks. And describes a solution.
Quite a few TeX macro experts contributed to the discussions
that lead up to the formulation of this problem, and the
solution that I presented (which is, as above, originally
due to Knuth).
I concerns me somethat that the already published solution
was not mentioned until very late in the day. It seems that
there is a certain amount of collective amnesia in the
TeX community.
Thank you, David, for reminding us of the valuable contribution
made by Michael Downes.
--
Jonathan
Jonathan Fine
> I read Michael's article when it came out, but since then it
> probably slipped my mind. (BTW, Michael made many great
> contributions to the TeX community. I know the only one that
> misses him, now that he is no longer with us.)
Sorry. Typo. Should be
I read Michael's article when it came out, but since then it
probably slipped my mind. (BTW, Michael made many great
contributions to the TeX community. I'm not the only one that
misses him, now that he is no longer with us.)
--
Jonathan
David Kastrup
> David Kastrup wrote:
[outerhbox]
>> I took a look at it. Unfortunately, unsuitable for my purposes.
>> The
>> following are the shortcomings (probably pretty much inherent to TeX):
>> a) it only works up to a total length of \maxdimen. Less than 50
>> lines of text, about a page of material, will bust it.
>> b) it does not work with explicit line breaks.
>> c) it does not work with marks, insertions, vadjusts.
>
> Work arounds exist for these problems.
> a) Don't accumulate so much material all at once.
> b) Modify the method to produce several lines of material.
> c) As with (b).
Uh, what? "As with b)"? Marks, insertions and vadjusts are not
accessible with \lastbox, \unpenalty and their ilk. They migrate out
of their lines, losing the connection with their point in the
horizontal list, and they cause the resulting list to be
nondeconstructible, except possible by \vsplit, and then the pieces
are opaque and not open to analysis anymore.
Jonathan Fine
Please exercise a little indirection (and imagination).
If you have an vadjust, store its content in a special box.
And then add that special box to the 'list of lines'.
And then this 'list of lines' can be 'unboxed' to give the
required output.
TeX is not well-suited for this sort of thing, but it
can be done.
I know the above is sketchy, but I'm sure David can
fill in the details.
--
Jonathan
David Kastrup
How do you establish the connection between a point in the horizontal
list and the "special box"?
> And then this 'list of lines' can be 'unboxed' to give the
> required output.
>
> TeX is not well-suited for this sort of thing, but it
> can be done.
In trivial cases without other code interacting, at best. And I don't
see a viable approach in that case even.
I don't even want to start thinking about what you'd want to do about
display math.
> I know the above is sketchy, but I'm sure David can
> fill in the details.
Well, the details are what renders this approach academical. If you
have to modify basic primitives to do something different from what
they are intended for (and primitives like \insert do not even parse
their arguments in a manner replicable by macros), then you can't hope
to have any nontrivial package working with the result, because all
expectations about TeX's behavior are off when the primitives don't
have the expected effects.
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
<statement of problems snipped>
>>Please exercise a little indirection (and imagination).
>>
>>If you have an vadjust, store its content in a special box.
>>And then add that special box to the 'list of lines'.
>
> How do you establish the connection between a point in the horizontal
> list and the "special box"?
Store a sequence of 'line portions' in hboxes.
Use the dimension of the line portion to code its type.
Roughly
\vbox{
\setbox 0\hbox{Ordinary stuff}
\wd 0 0sp
\box 0
\setbox 0\hbox{\vbox{<stuff to vadjust>}
\wd 0 1sp
\box 0
% etc
}
>>And then this 'list of lines' can be 'unboxed' to give the
>>required output.
>>
>>TeX is not well-suited for this sort of thing, but it
>>can be done.
>
> In trivial cases without other code interacting, at best.
TeX is Turing complete, and has sufficient primitives.
The task if fairly simple. I don't see how other code could
interfere. After all, it is just unboxing and so forth.
> And I don't see a viable approach in that case even.
Well, there is one. Please look harder.
> I don't even want to start thinking about what you'd want to do about
> display math.
You have, effectively, asked for help with a problem.
And now you say you don't want to think about it.
>>I know the above is sketchy, but I'm sure David can
>>fill in the details.
>
> Well, the details are what renders this approach academical.
It seems me me that here you are agreeing that the problem can
be solved, but that it won't be easy.
And I am not willing to solve the details of your problem for
you. This is something you are well capable of doing.
> If you
> have to modify basic primitives to do something different from what
> they are intended for
<snip>
This is not at all what I was suggesting. I don't know where you
get that idea from.
Many people post to the newsgroup saying, in effect, "I have this
problem. How do I solve it?" And then help is given.
You seem to be posting saying, in effect, "I have this problem, and
TeX cannot solve it."
Well, Heiko started by saying that TeX could not do what, in normal
use, the \outerhbox macro does.
Please take my word for it. Your problem, as I understand it, can
be solved in TeX.
If you disagree, please start a new thread, and provide a minimal
example.
--
Jonathan
David Kastrup
> David Kastrup wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>>>
>>>TeX is not well-suited for this sort of thing, but it
>>>can be done.
>> In trivial cases without other code interacting, at best.
>
> TeX is Turing complete, and has sufficient primitives.
> The task if fairly simple. I don't see how other code could
> interfere. After all, it is just unboxing and so forth.
Go ahead. It's your package, and you won't mind it becoming more
useful, I guess.
No need to do the "it's easy" handwaving here. Just implementing it
will be a more powerful argument than any you could come up with here.
I am not convinced, because I tried my hand at it, having an actual
need, and learnt pretty much the hard way that this was not feasible.
Feed me humble pie and prove me wrong in deeds instead of words.
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
>
>
>>David Kastrup wrote:
>>
>>>Jonathan Fine <jf...@pytex.org> writes:
>>>
>>>>TeX is not well-suited for this sort of thing, but it
>>>>can be done.
>>>
>>> In trivial cases without other code interacting, at best.
>>
>>TeX is Turing complete, and has sufficient primitives.
>>The task if fairly simple. I don't see how other code could
>>interfere. After all, it is just unboxing and so forth.
>
>
> Go ahead. It's your package, and you won't mind it becoming more
> useful, I guess.
>
> No need to do the "it's easy" handwaving here. Just implementing it
> will be a more powerful argument than any you could come up with here.
>
> I am not convinced, because I tried my hand at it, having an actual
> need, and learnt pretty much the hard way that this was not feasible.
>
> Feed me humble pie and prove me wrong in deeds instead of words.
In the message quoted above, but snipped, I suggested that if you
wanted help with this problem, you should start a new thread and
post a minimal example. Please do so.
--
Jonathan