Re: Punctuation spacing

[Ludovic Courtès]

Hi Jeff,

address@hidden (Jeff Kingston) writes:

> I've never tried to do this systematically for the reason you
> mention, that then punctuation marks get that definition
> everywhere, even within equations etc., which I consider to
> be too tricky.

At some point, I was hoping that we might be able to make those
definitions visible only to, say, the body of address@hidden'.  But then, it
is still visible to the arguments of all the functions used within the
body of address@hidden'.

Is there no way to somehow limit the scope of those definitions?

[BTW, I couldn't find the explanation for the special-meaning `//' that
must follow address@hidden', address@hidden', etc.  Is it documented somewhere?]

> I'd be willing to cooperate if someone wanted to
> construct and test such a file.

Thanks, but so long as there is no way to escape the problems I
mentioned earlier (especially when it comes to passing invalid code to
the PostScript back-end), I'm not sure it's reasonable to include it in
the distribution.

OTOH, I'd really like to see this issue solved once for all.  What a
terrible dilemma.  ;-)

>>From a design viewpoint, I don't believe that tricky
> definitions that make what look like ordinary characters
> into symbols is the right approach.

Yes, I agree that it's not a very clean approach.

> Lout offers nothing
> else, but in an ideal system you would take a paragraph
> of literal text and apply a language-specific formatting
> algorithm to it.  This way you don't need a whole new
> description language, just a general-purpose programming
> language.  You basically have to do something like this
> anyway to handle right-to-left text, ligatures, and all
> the other weirdness documented in the Unicode book.

As far as Lout is concerned, I can't think of various possibilities.

  1. The broken `def's (what I proposed) that will inevitably yield
     hard-to-understand errors from time to time.

  2. Definitions of `;' et al. with limited scope so that most erroneous
     situations can be avoided.

  3. Per-language hard-wired C code.

  4. An extension of, say, `langdef', that allows everything we need to
     be described.

I'm afraid (2) is not achievable.  (4) would require way too much work.
(3) may require a fair amount of work as well, but perhaps it's doable
(and I think it touches the same area as margin kerning).

If we were to choose (3), we might even add new ad hoc primitives to
make it configurable, like:

  ";" @PunctuationSpacing before { 0.5s } after { 1s } {
     Some text; with a semi-colon.
  }

Or, at a higher level:

  Hungarian @PunctuationSpacing { Some text... }

What would you advise?

Thanks,
Ludovic.