lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Texinfo help, please


From: David Kastrup
Subject: Re: Texinfo help, please
Date: Wed, 11 Jul 2012 21:45:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Wed, Jul 11, 2012 at 03:50:21PM +0200, David Kastrup wrote:
>> Janek Warchoł <address@hidden> writes:
>> 
>> > On Wed, Jul 11, 2012 at 1:56 PM, David Kastrup <address@hidden> wrote:
>> >>
>> >> "Phil Holmes" <address@hidden> writes:
>> >> > It should wrap between the words "the file" and the filename.
>
> +1
>
>> > It would probably be less ugly that an overstretched line.  As for
>> > "rephrasing" strategy, i find it not suited to our needs.  It's good
>> > for publishers, whose job is to take care of such details when they
>> > have an almost-ready-to-publish material.  We are not a publishing
>> > house: we don't want to fiddle with typography in our manuals.  Also,
>> > the manuals change, and the "rephrasing" solution is not flexible
>> > enough.
>
> +1
>
>> Typography is not magic.  It has to obey the laws of physics.
>
> ...
>
> The "law" that I want TeX to do is this:
> - if a word would be printed in the right-hand margin, insert a
>   line-break before that word.
>
> That's it.

No, that isn't it.  What is supposed to happen to the line(s) before the
break?  If there is no answer meeting the configured constraints to that
question, TeX does not break.

> Sure.  So we're asking if TeX can be tweaked to consider
> additional solutions.  (namely, "always add a line-break before
> anything with an overfull hbox, regardless of what that makes the
> rest of that paragraph look lik")

Sure, that is what the emergencystretch stuff (and the @finalout command
explained in the Texinfo chapter I cited) are all about.  You can tell
TeX to go ahead and choose ugly rather than flag the problematic
paragraphs parts.

> The answer could be "no, TeX is not flexible enough to do that".  Fair
> enough; we're accustomed to living within the limitations of our
> tools.  But this isn't an "impossible" or "magical" request.

Phil already explained that he did not want to revert to the documented
solutions TeX considers too ugly for consideration without explicit
prodding.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]