#5086 Fix dashed line errors

[David Nalesnik]

Issue 5086: Fix dashed line errors

There are two errors in lily/line-interface.cc which cause
dashed lines to be drawn inaccurately.

(1) Line-thickness is improperly subtracted from the "off"
value in Line_interface::make_dashed_line. This was done,
presumably, to account for the line cap of each dash. In fact,
PostScript discounts the line cap when constructing the pattern.

(2) Dashed lines are constructed so that they begin and end
with a dash. Thus, a dashed line is built of dash + whitespace
units and a last lone dash. Period is not adjusted in
Line_interface::line for this last dash, which can lead to a
noticeable difference in its length compared to other dashes.

Correcting these flaws ensures that dashed lines end with a
dash rather than whitespace, and that terminating dashes are
not clipped. Also, the number of dashes drawn reflects the
number calculated.

http://codereview.appspot.com/320320043

[David Nalesnik]

There are a number of regtests (42) which show differences as a result of this patch. This is to be expected, as the effect is to draw dashed lines more accurately. Note, for example, that the horizontal line in ottavas always touches the end vertical, which was not always the case before.

[David Nalesnik]

Here's a before and after for this snippet:

\header {
ragged-right = ##t
}

{
\override TupletBracket.style = #'dashed-line
\tuplet 3/2 { c''2 d'' e'' }
}

[David Nalesnik]

Hopefully, here are the images...

[David Nalesnik]

Here's the old:

[Anonymous]

Passes make, make check and a full make doc.

[Anonymous]

Patch on countdown for March 13th.

[David Kastrup]

Not intended to hold up the countdown but something I've been slightly worrying about, so maybe double-check?

(1) Line-thickness is improperly subtracted from the "off"
value in Line_interface::make_dashed_line. This was done,
presumably, to account for the line cap of each dash. In fact,
PostScript discounts the line cap when constructing the pattern.

LilyPond stencil metrics need not map 1:1 to PostScript: I think that there were some adjustments in this area either in the scm/output-ps.scm backend code or even in the definitions in ps/music-drawing-routines.ps.

So it might be a good idea to add a regtest with quite thick lines and possibly some tic marks/rulers/arrows added that would make it easy to verify the assumptions visually.

[David Nalesnik]

@David Kastrup

The following doesn't depend on behavior I've touched, but it should illustrate that LilyPond behaves consistently with what I've asserted about PS..

Is this what you had in mind?

[David Nalesnik]

Perhaps some whitespace between lines would be better..

[Anonymous]

@David Nalesnik
If you want to push this, go ahead and create a new tracker for a reg test as per David Kastrup's suggestion, or you can tag the reg test on this issue (in which case just make sure it goes to the correct state so I can spot it to test).

I'll set this to 'Counted down please push' for now.

James

[David Nalesnik]

Pushed to staging as commit ee1c498891ef92ebcd7d043b46e07ea2d3a9d3ae.

[David Nalesnik]

I've gone ahead and pushed this.

I will try to open an issue for a regtest soon, when I've given some thought how to formulate an issue. I'm in a little doubt, however, over what needs to be tested. There are many dashed lines in the regtests already, and a comparison of changes shows a general improvement (for example, the horizontal line of ottavas connecting with the vertical stroke at the end, not always the case before, and the number of dashes drawn matching the number calculated). Also, LilyPond's use of Postscript to draw these lines seems straightforward, so my example further above is simply verifying something about PS itself with which LilyPond doesn't tamper.

[Graham Percival]

Verified, looks beautilful, thanks for the example! :)