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.
Janek Warchoł [Sat, 7 Dec 2013 21:58:06 +0000 (22:58 +0100)]
CG: remove information about frogs and frog meister
frogs list is dead, and the frog meister was a good idea
but it gets out of touch from reality (since a few months
previous Frog Meister didn't actually participate in development).
David Kastrup [Tue, 23 Apr 2013 14:49:19 +0000 (16:49 +0200)]
Implement option -dstrokeadjust in order to get stroked stems and strokeadjustment
This makes the stroke drawing primitives for long rounded rectangles
dependent on the setting of currentstrokeadjust. As a result,
low-resolution bitmap devices (up to 150 dpi or so) will get stroke
adjustment applied automatically. The option needs to get invoked
explicitly to get stroke adjustment for PDF, giving a large file size
increase and markedly better previews on a number of PDF previewers.
projects / lilypond.git / log