bug-gnu-music
[Top][All Lists]
Advanced

[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



reply via email to

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