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.
David Kastrup [Thu, 11 Apr 2013 15:27:14 +0000 (17:27 +0200)]
Issue 2658: Be serious about setstrokeadjust in PostScript primitives
This particularly concerns draw_round_box which is used for drawing
lines with a rounded ending. If the width/height ratio or its inverse
exceeds 2, the box is considered to be a "line". In this case, first
a clipping path is established representing the whole shape and
extended widely in the area of the "main stroke". The reason for this
extension is to avoid both clip area and stroke competing for the
outline. While this is not a problem for the PostScript or PDF
rendering model, the Cairo bitmap rendering library employs
Porter-Duff compositing for antialiasing amounting to "cheap man's
antialiasing" not requiring a higher rendering resolution but relying
on edges affecting a single pixel to be independent.
Porter-Duff requires us not to have multiple parallel strokes or clip
areas if we want to avoid wrong sub-pixel grayness levels (and
consequently lines appearing too thick or thin) in Cairo-based
previewers like Evince.
After establishing the clip area, a stroke is drawn through. This
stroke may (at the PostScript device's discretion) employ
strokeadjustment further correcting the apparent thickness.
Ghostscript employs stroke adjustment when rendering at a resolution
below 150dpi. Stroke adjustment does not pass into PDF, however, when
ps2pdf runs.
Ghostscript performs sub-pixel rendering for antialiasing which
reduces the amount of discontinuities possibly caused by joining
stroke-adjusted shapes with full shapes.
It turns out that sharper contours can be achieved by using strokepath
and fill instead of a plain stroke. However, the resulting crisper
stems tend to combine worse with beams, so this approach has not been
pursued.
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ł [Fri, 29 Nov 2013 15:47:43 +0000 (16:47 +0100)]
let RhythmicStaff use default barline extent
There is no reason to make barlines in RhythmicStaff special.
The purpose of the deleted code was probably to ensure that
the barlines were visible at all (despite the fact that there
is just one staffline in a RhythmicStaff). However, currently
barline code takes care of this by default.
This makes barlines in DrumStaff and RhythmicStaff similar.
A comment by Keith:
The book by Kurt Stone happens to have some bar-lines in single-line percussion
staves that are as tall as a 4/4 time-signature. Other examples in the same
book have short bar-lines like these here, and looking at some scores the short
bar-lines are more common.
David Kastrup [Sun, 24 Nov 2013 23:59:55 +0000 (00:59 +0100)]
Issue 3675: Make convert-ly -d only ever update on changed files
Previously, it updated unconditionally whenever a new stable version
came out, leading to merge conflicts. When the final applied
conversion is to an unstable version and the following stable version
is not beyond the conversion target, the following stable version is
used.
Note that this rule does not make a factual difference for continuous
updates of a code base (the normal use case for
scripts/auxiliar/update-with-convert-ly.sh), but it makes a difference
for the conversion/import of code that may have fallen behind a lot
(like with the LSR import, or when converting archived files).
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 [Mon, 25 Nov 2013 18:33:34 +0000 (19:33 +0100)]
Issue 3676: Bar checks display the wrong location
This one is just embarrassing. The lexer used last_input_ where it
should have been using here_input (), resulting in music identifiers
and some other stuff to be located one token early.
David Kastrup [Mon, 18 Nov 2013 11:37:59 +0000 (12:37 +0100)]
Issue 3668: Let NullVoice have an existence in MIDI
Issue 3457 omitted to introduce the NullVoice context into MIDI. This
implementation is incomplete (see the TODO in performer-init.ly), but
at least it does not let the context structure go off the deep end in
MIDI.
David Kastrup [Sun, 17 Nov 2013 18:29:06 +0000 (19:29 +0100)]
Issue 3663: Crash with \repeat ... \alternative and \remove "Bar_engraver"
This approach is just poking around in the dark and removing Scheme
error messages. In particular substituting the original glyph for
left-bar-line and right-bar-line (when missing) in calls to
span-bar::compound-bar-line seems fishy, and the original logic
for setting left-bar-broken if left-bar-line is not even present
is also not clear to me.
The results for the example in the bug report:
form = \new Staff \with {
\remove "Bar_engraver"
} \repeat volta 2 {
s1
} \alternative {
s1 % first ending
s1 % second ending
} % form
\score {
<<
\form
>>
} % score
are also not identical with the 2.16 results: the volta brackets now
run into each other; before there was a gap.
It fixes the crash. I have no idea what a proper fix would look like.