[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Too many bug complaints in one email
From: |
Mats Bengtsson |
Subject: |
Too many bug complaints in one email |
Date: |
Sun, 20 May 2001 16:48:43 +0200 |
During my small revision of the documentation, I found a number of
bugs/problems worth bringing up.
- The nomenclature for contexts is confusing. The \name declaration
specifies the name of the context type, not the name of the
instantiation. The \type specifies what category of context.
Why not rename:
\type -> \category (or \class)
\name -> \type
It would make it much easier to explain this in a concise way.
- We had a bug report some time ago that papersize didn't work
together with ly2dvi unless it was specified within a \paper block.
In 1.3.149, someone implemented the "smart" solution that I planned
to implement now, namely to add a papersize=\papersize definition
within the default \paper block. Unfortunately, this solution isn't
so smart since the paper variable \papersize will override the
global \papersize variable, meaning that changing the \papersize
at the global level has no effect at all.
Maybe the best solution is to officially make it a paper variable
also in the manual.
- Aren't there any ledger lines for EasyNotation?
- In the following example, I think the tie should be attached to the
bottom notes, not the middle ones.
\property Voice.sparseTies = ##t
<c' e' g'> ~ <c' e' g'>
- The collision handling for rests has (at least) two major problems:
* If you have a manually added beam, the rest is moved too far away,
see the reference manual examples in "Manual beams"
* If you specify staff-position manually, the collision handling
shouldn't move the rest. Now, staff-position is calculated
relative to the position it gets by the collision handling and
requires lots of trial-and-error to get correct.
- Why not try to invent a syntax for text spanners? They are currently
really clumsy to use.
- In the second example of Instrument names in the reference manual,
we see a collision between the TeX and Lilypond way of treating
spaces. (columns " (B" ,text-flat ")") gives the same effect as
(columns " (B " ,text-flat ")") which is not what we want.
- We don't tell people how to find the names of the feta font symbols.
It shouldn't be too hard to generate a list to include in the
documentation. Also, in the text markup, it would be better to use
the descriptive symbol names from the first argument of fet_beginchar
instead of the internal names used now in (named "...").
- You motivate that the autogenerated grob documentation is available
on-line, saying that this makes it more up-to-date. Don't we have
the opposite problem? People who install 1.4.13 (for example) and
stick to that, won't be able to access the documentation for their
particular version, since the web page is updated.
In the change log for 1.3.145, you mention a flat autogenerated list
of grob interfaces to be included into the refman. Is it available?
What alternatives do we have? The info version is built whenever
you build Lilyond, but I don't know if the RPM or Debian packages
install those into the standard info installation and I've never
seen the info version announced. Another disadvantage is the lack
of graphical illustrations.
Another alternative is to include the full HTML documentation into
the RPM and Debian packages (maybe it's done, I've never looked
into them) but that would make them significantly larger because
of all the gifs.
/Mats
- Too many bug complaints in one email,
Mats Bengtsson <=