Re: Punctuation spacing

[Ludovic Courtès]

Hi Jeff,

address@hidden (Jeff Kingston) writes:

> Try &0.5su instead of |0.5s, and let me know how it goes.  You
> might also want to replace word ";" with word 1su ";" to prevent
> line breaks before the ";".
>
> The & symbol makes the result part of the enclosing paragraph, so
> it should participate in all the usual paragraph things, including
> hyphenation.  The u modifier introduces an unbreakable space.

Great, that apparently does the trick.  BTW, the `u' gap mode is
apparently not documented in the Expert's Guide, for instance in Figure
3.2.

Now, I believe that Lout ought to provide a means to enforce such
typographic rules ``out-of-the-box'' for support of languages other than
English to be complete.  English seems to have much simpler rules.
Currently, it seems that its only rule about spacing around punctuation
marks (namely, inserting one space after the end of a sentence) is
handled by adding ad hoc information at the level of `langdef'
definitions [0].

My question is: What was the rationale behind this design choice instead
of turning all the punctuation marks into definitions similar to the one
I posted?

I can think of one drawback of the `def' approach: there are places
where one doesn't want such definitions to be visible.  This includes
places where code is directly passed to the PostScript back-end (e.g.,
tick labels in an address@hidden'), but also, for instance, equation bodies.  I
believe this can be solved by importing those definitions only in
address@hidden', address@hidden', etc.  Any other issue with this approach?

OTOH, the current `langdef' approach seems overly specific: one can only
specify characters that determine the end of a sentence.  Then,
automatically, Lout adds one space after the end of each sentence.  In
order to describe rules used in actual typography (e.g., adding &0.5su
before a semi-colon and &1.0s after), we'd need to develop a whole new
description language, which may be quite difficult to implement.
Furthermore, from a design viewpoint, it seems that keeping Lout
primitives as simple and generic as possible is highly desirable.

Thoughts, opinions?

Thanks,
Ludovic.


[0] See Sections 3.10 (address@hidden'') and 3.5 (address@hidden'') of the
    Expert's Guide.