Let horizontal-line be a straight-cut line rather than having rounded edges (issue 8685043)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Let horizontal-line be a straight-cut line rather than having rounded edges (issue 8685043)

Thomas Morley
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.
Though, I might change my mind once I understand the reason behind the
patch.

https://codereview.appspot.com/8685043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Let horizontal-line be a straight-cut line rather than having rounded edges (issue 8685043)

Thomas Morley
On 2013/04/11 23:44:03, thomasmorley65 wrote:

> 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.

Sorry, wrong link.
Should be:
http://lsr.dsi.unimi.it/LSR/Item?id=700



https://codereview.appspot.com/8685043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Let horizontal-line be a straight-cut line rather than having rounded edges (issue 8685043)

David Kastrup
In reply to this post by Thomas Morley
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel