Re: Section numbers, Emacs, Ghostscript & PlainText

[Marnix Klooster]

Jeffrey H Kingston said:

> Hi, I saw your list of questions/comments on the list.  Here are my views
> on them all...
>
> (1) Unnumbered subsections:  @SectionNumbers { None } in the setup file

I'm sorry I didn't make myself clear: What I'd like is to have most
sections numbered, but some unnumbered.  For instance, I can imagine
having a book that has an introduction, a couple of chapters, then an
interlude, more chapters, an interlude again, etc., ending with an
epilogue.  The chapters should be numbered consequtively, and the
introduction, interludes, and epilogue unnumbered.  Or another example: 
I have only one appendix, so I don't want it `numbered' A.  Would this 
be easy to add?

The simplest implementation (from the user's point of view) might be an 
extra parameter to large-scale structures that allows the user to give 
her own section number, *suppressing automatic numbering temporarily*. 
(This makes it different from @BypassNumber.)  If this user-provided
section number is empty or None, the section is unnumbered.

> (2) Start numbering sections from zero:  no option for that at present,
>     although it would be easy to add.  Convince me that it isn't a
>     barbaric innovation made by computer scientists who know nothing
>     about typesetting, and I will.

Do you have any specific computer scientist in mind ?-)  One argument
is the mathematical one: modern mathematics starts numbering from zero, 
which is usually results in the simplest formulations.  (If you want to 
start a flame war on this, e-mail me privately :-)  A more practical
one is that in some circles numbering from zero is simply preferred; a 
document formatter should therefore allow it.  Finally, I might want to 
produce only part of a document using Lout, so I want the first chapter 
to have number 7, say.

> (5) Ghostscript output looks worse for Lout than for troff and TeX.  I'm
>     not sure about this either, but I have a theory that Lout is more
>     likely to make GhostScript work hard at scaling fonts than the others.
>     If it's really bad GhostScript might be using the wrong fonts.  You
>     could look into what fonts it is using, exactly.  But if it looks
>     good under high magnifications, then it seems likely that the fonts
>     are right but the scaling is a bit off.

As others have already commented (thanks!) I seem to be using an
ancient version of ghostscript, and that its fonts are the problem.

> (6) I've been thinking about merging doc and pdoc myself.  There is a
>     problem with the symbol you use, in that it assumes that there are
>     exactly two back ends in the world.  In fact, one of my correspondents
>     is working on a third.  But I think this potentially large set of
>     back ends can be divided into two classes for most purposes - plain
>     text, with its many limitations, and the rest, with none; so that a
>     symbol offering two alternatives still makes sense.  But if someone
>     writes a back end offering, say, half-line-feeds like the old Diablo,
>     we'd be stuck.  I guess they're all scrap metal by now.

Just after I sent my original questions, I found out that @Plain does
exactly what I invented @BE for, except that @Plain is more elegant.
Picking a minor nit, however, wouldn't it be nicer to exchange @Plain's 
parameters?  This would allow reading  x @Plain y  as `x, or if in
PlainText y'.  The first should be the usual version (PostScript), and 
the second the plain-text alternative.

Regarding multiple back ends: maybe you could add a document parameter
that gives the `preferred back end' for this document.  @Plain would
be redefined to something like

  def @Plain
      left x
      right y
  {
      @BackEnd @Case {
          @PreferredBackEnd @Yield y  # As stated above, I'd prefer
          else              @Yield x  # to exchange x and y...
      }
  }

with @PreferredBackEnd being the new document parameter.  Finally, you
add a similar operator which has a named parameter for every existing
back end.  If a new back end is added, you then only need to change this
last operator.

This set-up gives the user a choice: either design the document for two
back ends, one of which is preferred; or design it for all needed back
ends.

> Hope all this helps.

It does, it does.

> Jeff Kingston
> address@hidden (until December)
> address@hidden (still works fine, is being forwarded automatically)

Groetjes,

  <><

Marnix
--
Marnix Klooster
address@hidden   //   address@hidden