Re: clef sign colliding with beam

[Mats Bengtsson]

> > > > On a side note, it would be really helpful if there was a master list of
> > > > class properties like this (Voice.Stem -> length, etc. etc.).
> > > 
> > > take a look at
> > > http://www.cs.uu.nl/~hanwen/lilypond/Documentation/user/out-www/lilypond-internals/LilyPond-backend-properties.html.
> 
> I saw this.  It's certainly helpful, but I was also looking for a master
> list of classes as well (Voice[.Beam, .Stem], Staff, ...).  Is there such a
> list?

The terminology is always a problem here, but I think you want to
find all properties corresponding to a specific type of ``context'', 
like 'Voice' or 'Staff'. These contexts are listed at the top of

http://www.cs.uu.nl/%7ehanwen/lilypond/Documentation/user/out-www/
lilypond-internals/lilypond-internals.html#lilypond-internals

and each page contains links to all the ``engravers'' included
in the specific context. For each engraver, you may find some
engraver properties plus a link to one or more ``grobs'' 
(graphical objects). Since many of the properties are shared
among several graphical objects, they have been grouped into
``interfaces''. For each grob you will therefore find a list
of interfaces and if you click on an interface, you finally
find a complete list of all the properties in that particular
interface. 
To make things more confusing, the information page for each 
grob also lists a subset of all the properties it understands, 
namely the properties that are set by default in this particular
object. The problem, in my opinion, is that often the most 
commonly used properties are not included in this list since
they are undefined by default. The selection of which property
is shown on the grob level and which is only shown in some 
interface description is more based on the implementation
than on the typical user.

I personally find this quite messy, it's often even more 
difficult to find a property in Lilypond than to find some 
command in MS Word. I mostly used grep in the scm/ 
directory instead of trying to navigate in this generated
documentation. 

The question is how to improve the situation.
I've argued before that the concept of ``interfaces'' is
more or less irrelevant for the end-user. In order to 
set a (backend) property, you have to know the context 
(to specify the scope of the setting), the grob, the 
property name and the set of allowable values. 
The interfaces are very convenient in the implementation
but you never specify an interface name in an .ly file. 
Also, I think a typical user will recognize the properties
that are common for several objects without seing these
interfaces explicitly stated in the documentation. 

A qustion: how long would each grob description be if
it listed all the properties? 

It looks as if all the information from each engraver
description is included verbatim in the context
descriptions where the engraver is used. If the full
interface descriptions were included on the grob 
descriptions, it would be enough with two levels of
.html pages instead of the four levels in the current
documentation. Of course, that would mean lots of
repeated information but that's maybe better than
getting a mouse arm when you click up and down to 
find the information your're looking for.

      /Mats




      /Mats