Reviewers: thomasmorley65,
Message:
On 2013/04/11 23:44:03, thomasmorley65 wrote:
Can't review C++ -code, though, from description, I do not understand
the reason
for it.
Well, ofcourse it will merge better with barlines, but can you give an
example
where the problem isn't solvable with at most medium effort?
Ah, wait, I just found
http://lsr.dsi.unimi.it/LSR/Search?q=color
Regarding it with very high zoom shows a greater disadvantage of
draw-line.
Nevertheless, I think it's more a problem of said snippet, worth
fixing.
In general, I'd prefer rounded boxes, but with a little blot-diameter.
There are several reasons. One reason is that the metrics for
horizontal-line are wrong: \draw-line (the markup command) accounts for
the rounded line ends by including them in the total width.
horizontal-line, using the same image, doesn't.
Another is that the staff lines with their current setting fail to
cooperate with
URL:http://code.google.com/p/lilypond/issues/detail?id=2658 in typical
viewing situations and normal bar lines. The reason is that draw-line
produces line ends that are a circle. Circles in drawing direction
color every pixel that they touch. The bar line is drawn with the same
thickness in perpendicular direction and now does _not_ color every
pixel that it merely touches, but rather only a number of pixels
appropriate for its thickness (on average, half a pixel less on each
side). So the circular ends tend to stick through the barlines at low
resolution.
Now cutting the horizontal lines off sharp might be overkill but it
saves making a decision about just how much rounding should be needed.
It also corresponds with the output of a rake, the engraving tool used
for staff lines.
Full circle rounding clearly is too much and it does not reflect the
output from actual engraving. Cut-off engraving also cooperates nicely
with the actual metrics.
Of course, another motivation was again issue 2658: it turns out that at
least with circular line ends on lineto stroke, Ghostscript does not
do the same kind of stroke adjustment than I now use for rounded
rectangles. As a result, staff lines tend to look inconsistent with
things like bar lines and note stems. Using draw_rounded_box accounts
for that, even though it would account for it with different rounding
settings as well.
Description:
Let horizontal-line be a straight-cut line rather than having rounded
edges
This actually should just affect staff lines and have them cut off
rather than rounded at their ends. They merge better into bar lines
that way. Since there is no support in the backends for lines with
cut edges as such, we use round-filled-box instead (with a rounding
diameter of 0).
Should combine well with issue 2658
Please review this at https://codereview.appspot.com/8685043/
Affected files:
M lily/lookup.cc
Index: lily/lookup.cc
diff --git a/lily/lookup.cc b/lily/lookup.cc
index
e903d5a9a403b18f1ce1192642f8f769619b741e..fbd38486ddb5a286191b77406506ca478cdc4406
100644
--- a/lily/lookup.cc
+++ b/lily/lookup.cc
@@ -103,14 +103,17 @@ Lookup::rotated_box (Real slope, Real width, Real
thick, Real blot)
Stencil
Lookup::horizontal_line (Interval w, Real th)
{
- SCM at = scm_list_n (ly_symbol2scm (draw-line),
- scm_from_double (th),
- scm_from_double (w[LEFT]),
- scm_from_double (0),
- scm_from_double (w[RIGHT]),
- scm_from_double (0),
- SCM_UNDEFINED);
+ // Somewhat counterintuitively, we use a rounded box here with
+ // corner diameter 0, resulting in a cleanly cut-off line.
+ // draw-line, in contrast, has rounded edges.
+ SCM at = (scm_list_n (ly_symbol2scm (round-filled-box),
+scm_from_double (-w[LEFT]),
+scm_from_double (w[RIGHT]),
+scm_from_double (th / 2),
+scm_from_double (th / 2),
+scm_from_double (0),
+SCM_UNDEFINED));
Box box;
box[X_AXIS] = w;
box[Y_AXIS] = Interval (-th / 2, th / 2);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
