James Lowe [Tue, 31 Dec 2013 07:06:11 +0000 (07:06 +0000)]
Doc: Tidy up of chord-names-jazz.ly
Added a new context definitigon to remove the Bar Number Engraver
as it was clashing with the instrument names and looked messy.
As it was not actually pertinent to the example I thought this the
simplest method
Also tidied up the spacing of the information as per standard doc
guidelines
Mike Solomon [Mon, 16 Dec 2013 08:11:10 +0000 (10:11 +0200)]
Adds outside-staff-interface and outside-staff-axis-group-interface
When a property exists in an interface, the property should make sense for
a sensible of grobs that implement that interface. Otherwise, the property
should be part of a separate interface that applies to a sensibly-sized
group of grobs.
Various properties having to do with outside-staff calculations belong to
grob-interface. This does not make sense for many grobs (StaffSpacing,
NoteSpacing, SpacingSpanner, StaffSymbol just to name a few). There is a
limited collection of grobs for which outside-staff properties make sense.
The outside-staff-interface provides a separate interface to be implemented
by these grobs.
The same is true for axis groups that place outside-staff grobs, which form
a limited subset of grobs implementing the axis-group-interface. Rather than
putting the relevant properties in the axis-group-interface, we move
them to an outside-staff-axis-group-interface.
Devon Schudy [Sun, 15 Dec 2013 22:27:00 +0000 (17:27 -0500)]
Update documentation for what's supported in MIDI. (issue 3740)
Also clarify what articulate.ly supports.
Change the snippet for redefining a shorthand to use an ArticulationEvent
instead of an articulation name, so users who follow its example will have
their articulations work in MIDI.
Urs Liska [Fri, 20 Dec 2013 09:09:04 +0000 (10:09 +0100)]
Issue 3732: Web: Rewrite "Features" content
The "Features" page had some problematic content and structure.
This commit makes some points more clear, removes problematic
claims and introduces some more points pro LilyPond.
Additionally replace some "color2" divs by generic divClass
Carl Peterson [Thu, 12 Dec 2013 23:05:11 +0000 (18:05 -0500)]
fix sidebar colors in html documentation
Change the default color of the TOC sidebar when no manual-specific color has been specified. Because the text color was changed to white, the TOC was not legible in manuals like the glossary, which is not assigned a color currently.
Also, darkened most of the manual TOC sidebars to separate from header and footer colors. Lightened the header and footer for the Contributor's Guide since it is the "black book."
Carl Peterson [Mon, 9 Dec 2013 00:20:03 +0000 (19:20 -0500)]
CSS changes to color-code major manuals
Added styling to use a manual-specific class in the <body> tag to color code each of the major manuals.
Now:
* Learning Manual: Green book
* Notation Reference: Blue book
* Usage Manual: Yellow book
* Extending: Red book
* Internals Reference: Purple book
* Contributor's Guide: Black book
Carl Peterson [Sun, 8 Dec 2013 16:44:08 +0000 (11:44 -0500)]
Add classes to <body> tag of documentation files
To facilitate request from lilypond-user to facilitate differentiating among the various manuals, appending CSS classes to the <body> tag of the documentation files so that the main CSS stylesheet can be modified to look for those classes to specifically style each manual and development status.
The present solution for indicating development status is a hardcoded line in Documentation/lilypond-texi2html.init.
Urs Liska [Thu, 12 Dec 2013 10:16:10 +0000 (11:16 +0100)]
Web: Reword contactUsAbout macro
Providing information on new reviews/productions etc.
should be possible by simply writing an email to bug-lilypond.
Redirecting to the Bug Report guide is off-putting.
Janek Warchoł [Wed, 4 Dec 2013 14:26:03 +0000 (15:26 +0100)]
font: parametrize and cleanup sharp code
Changes:
* as much as possible is controlled by global parameters,
* variables have more consistent names,
* the functions are more consistently structured,
* stem ends are placed in one line using explicit beam direction.
The glyphs remain identical.
It would be good to extract one global procedure that would draw
all needed sharps (instead of having 6 similar ones), but i didn't
have enough time to do this.
Janek Warchoł [Wed, 4 Dec 2013 11:20:12 +0000 (12:20 +0100)]
font: rewrite and parametrize natural code
The logic remains virtually the same. List of changes:
* more descriptive variable names,
* removed surplus points (1', 3', 11', 21'),
* stem brushing is controlled in a simpler way,
* beam slant does no longer depend on stem thickness,
* all dimensions are explicitely and straightforwardly
derived from global parameters. This makes it trivial
to get a differently-looking natural by just changing
clearly defined values.
At size 20, the natural remains identical. At signifincantly
different sizes there are a few microscopic changes, but they
are too small to be noticeable:
* stem end thickness is defined in terms of stem thickness,
so regardless of design size the ratio between them is constant.
* beam slant is slightly more consistent. But you wouldn't notice
the change if i haven't told you ;-)
Janek Warchoł [Fri, 6 Dec 2013 16:45:59 +0000 (17:45 +0100)]
font: clean up staffline-display in testing mode
Previous testing code was a mix of hideous copy&paste with
non-obvious passing glyph outlines around, which attempted
to produce additional glyphs in testing mode, so that there
would be both on-staffline and on-staffspace variations.
That code was completely unreadable and unmaintainable.
Instead i've introduced a global variable that determines
how the stafflines will be printed relative to the glyphs.
To see alternative configuration, just change that value.
David Kastrup [Fri, 13 Dec 2013 05:01:43 +0000 (06:01 +0100)]
Parser: properly disambiguate pitches from music in function arguments
In many instances, function arguments were parsed greedily without
looking at the function argument predicates first. This did not allow
using subsequent function arguments of type pitch and duration since
they were combined into one music expression.
David Kastrup [Thu, 12 Dec 2013 14:34:33 +0000 (15:34 +0100)]
Parser: let MYREPARSE and MYBACKUP back up even in presence of lookahead
This implies that the lookahead token must not yet have made an impact
on the state stack other than causing the reduction of the current
rule, or switching the lookahead token while Bison is mulling it over
will cause trouble.
Since an LALR(1) works on the top of the stack, this can usually be
guaranteed. The "Too much lookahead" message is not produced. If
these constructs are misused, the parser should typically complain
about the replacement token being unexpected.
The advantage is the ability to vastly simplify syntax rules that up
to now have to avoid lookahead tokens with a lot of drudgework.
David Kastrup [Wed, 11 Dec 2013 20:35:53 +0000 (21:35 +0100)]
Move the extra_token mechanism out of the lexer proper
Calling lex->pop_extra_token explicitly in the parser's yylex function
makes things considerably more robust. It also allows pushing and
popping the EOF condition, necessary for backing up right at the end
of a file, like with ##{ \relative { c d e f } #} where the music
expression is checked against being a pitch, and then is backed up.
Devon Schudy [Fri, 6 Dec 2013 21:14:46 +0000 (16:14 -0500)]
Make parsing of articulation shorthands more robust. (issue 3664)
Allow articulation shorthands to be any post-event. Commit 6baa453 tried
to restrict them to ArticulationEvents, but actually allowed anything.
As opposed to previously, return a dummy PostEvents on error as
fallback rather than an incomplete ArticulationEvent causing followup
errors and a crash.