[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bar number position (direction) numerical definitions overlap

From: Mats Bengtsson
Subject: Re: bar number position (direction) numerical definitions overlap
Date: Wed, 02 Aug 2006 09:57:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417

Paul Scott wrote:

1. The documentation and/or implementation of BarNumber direction is incorrect: #RIGHT and #LEFT give the same result as #UP and #LEFT respectively. The documentation error may have just been the result of an unfinished cut-and-paste. As far as I am concerned there is no need for #RIGHT, #LEFT or #CENTER values for the direction variable. If others want bar numbers on any possible corner of a bar then maybe a new variable should be introduced.

As I have already tried to explain, several different layout objects have the "direction" property and for some objects it means UP/DOWN for others it means LEFT/RIGHT. For example, in the following score, we move the arpeggios from the default left
to right and the bar numbers from the default up to down.
\version "2.8.0"
 \new Staff \relative c' {
   \override Score.BarNumber #'break-visibility = #all-visible
   \override Score.BarNumber #'direction = #DOWN
   c1 |
   <c e g>\arpeggio |
   \override Arpeggio #'direction = #RIGHT
   <c e g>\arpeggio |

Ideally, we should have different documentation texts for these two situations. However, for technical reasons, the documentation of a property is the same for all objects where the property appears. This in turn means that the text has to cover all the situations, i.e. it has to mention both up/down and left/right. In this particular case it's possibly a bit confusing but all the information is there. However, for other
properties like "style", the current documentation text is
 "This setting determines in what style a grob is typeset. Valid
  choices depend on the @code{stencil} callback reading this property."
which doesn't really provide any useful information.

So, what you really ask for is that we can have different versions of the
documentation for a property depending on what object it applies to.
However, this would probably require a major modification to the current
functions that automatically compile the manual. Also, it would lead to more
job to keep all these almost identical pieces of text up to date. Finally, for over 90%
of the properties, it makes perfectly sense to have the same documentation
regardless of the layout object it applies to.


reply via email to

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