Ends of barlines are hidden in staff lines.

Ends of barlines are hidden in staff lines.

Barlines are made a little shorter, so that the end of the barline doesn't touch
the outer edge of staff line - it ends in the middle of staff line now.
This prevets artifacts in pdf viewing and printing.

[Janek Warchol, 2011-07-29 05:14:59]

http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01051.html
2011/7/27 Han-Wen Nienhuys <hanwenn@gmail.com>:
>
>>> Due to rounding, PDF viewers can err
>>> the placement of the barline by a pixel.
>>> [so that it looks like sticking out of staff]
>
> You can make the problem disappear by
>
> - hard coding the output to a certain resolution
> - making the bar go to the middle of the staffline,
>   rather than the outside.
>
> both have disadvantages.

This patch does the second thing.  What disadvantages do you see besides what
happens when barline and staff have different colors?

cheers,
Janek

[hanwenn, 2011-07-29 16:43:12]

On Fri, Jul 29, 2011 at 2:15 AM,  <lemniskata.bernoullego@gmail.com> wrote:
> Reviewers: hanwenn,
>
> Message:
>
> http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01051.html
> 2011/7/27 Han-Wen Nienhuys <hanwenn@gmail.com>:
>
>>>> Due to rounding, PDF viewers can err
>>>> the placement of the barline by a pixel.
>>>> [so that it looks like sticking out of staff]
>
>> You can make the problem disappear by
>
>> - hard coding the output to a certain resolution
>> - making the bar go to the middle of the staffline,
>>   rather than the outside.
>
>> both have disadvantages.
>
> This patch does the second thing.  What disadvantages do you see besides
> what happens when barline and staff have different colors?

I was worried that the left/right corners of the point where the
barline meets the outer staff line would start to look like this

****
****
*******
*******
*******

(right upper corner)


then again, if the barline is horizontally aligned, it may not be a
problem. I think the problem may still occur if you stop/start staves
half-way the page, but we may decide it's not important enough.

you can check for unexpected artifacts by blowing up both staffline
thickess and the barline thickness.

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[Janek Warchol, 2011-07-30 16:07:47]

2011/7/29 Han-Wen Nienhuys <hanwenn@gmail.com>:
> On Fri, Jul 29, 2011 at 2:15 AM,  <lemniskata.bernoullego@gmail.com> wrote:
>> Reviewers: hanwenn,
>>
>> Message:
>>
>> http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01051.html
>> 2011/7/27 Han-Wen Nienhuys <hanwenn@gmail.com>:
>>
>>>>> Due to rounding, PDF viewers can err
>>>>> the placement of the barline by a pixel.
>>>>> [so that it looks like sticking out of staff]
>>
>>> You can make the problem disappear by
>>
>>> - hard coding the output to a certain resolution
>>> - making the bar go to the middle of the staffline,
>>>   rather than the outside.
>>
>>> both have disadvantages.
>>
>> This patch does the second thing.  What disadvantages do you see besides
>> what happens when barline and staff have different colors?
>
> I was worried that the left/right corners of the point where the
> barline meets the outer staff line would start to look like this
>
> ****
> ****
> *******
> *******
> *******
>
> (right upper corner)

No, it doesn't look like this.  It's nicely rounded.
(you wrote it well, Master :D)

> then again, if the barline is horizontally aligned, it may not be a
> problem. I think the problem may still occur if you stop/start staves
> half-way the page, but we may decide it's not important enough.

Actually, there is a problem with stop/start staves already - see
attached.  Maybe staff lines shouldn't be rounded?  I know that we
round most things, but i think it's not that much important in case of
stafflines, and changing this would fix the problem...

> you can check for unexpected artifacts by blowing up both staffline
> thickess and the barline thickness.

Very good idea!

[c_sorensen, 2011-07-30 16:15:39]

On 7/30/11 10:07 AM, "Janek Warchoł" <lemniskata.bernoullego@gmail.com>
wrote:

> 2011/7/29 Han-Wen Nienhuys <hanwenn@gmail.com>:
> 
>> then again, if the barline is horizontally aligned, it may not be a
>> problem. I think the problem may still occur if you stop/start staves
>> half-way the page, but we may decide it's not important enough.
> 
> Actually, there is a problem with stop/start staves already - see
> attached.  Maybe staff lines shouldn't be rounded?  I know that we
> round most things, but i think it's not that much important in case of
> stafflines, and changing this would fix the problem...

I think that the stop/start staves is currently exactly what it should do.
It stops the staff at a location, and starts the staff at the same location.
It reflects the commands that have been issued.  If the staff is continuous,
there is no indication that the staff has been stopped and started.

Thanks,

Carl

[pkx166h, 2011-07-30 21:35:58]

On 2011/07/30 16:15:39, c_sorensen_byu.edu wrote:

> 
> I think that the stop/start staves is currently exactly what it should do.
> It stops the staff at a location, and starts the staff at the same location.
> It reflects the commands that have been issued.  If the staff is continuous,
> there is no indication that the staff has been stopped and started.
> 
> Thanks,
> 
> Carl

Err..why does there need to be an indication?

The 'LP code' indicates it, I'm trying to think of a musical reason why this
matters. Are we just splitting hairs here?

1) If squaring up the lines helps and resolves more fundamental issues why do we
care if I can't tell the difference when I've issued a stop and start
immediately one after the other?

2) Even if I did have a 'gap' between the lines why does it matter if they are
rounded?

I don't see your point Carl.

James

[pkx166h, 2011-07-30 21:40:14]

passes make and reg tests look fine.

[Janek Warchol, 2011-07-30 22:54:05]

2011/7/30 Carl Sorensen <c_sorensen@byu.edu>:
> On 7/30/11 10:07 AM, "Janek Warchoł" wrote:
>> Actually, there is a problem with stop/start staves already - see
>> attached.  Maybe staff lines shouldn't be rounded?  I know that we
>> round most things, but i think it's not that much important in case of
>> stafflines, and changing this would fix the problem...
>
> I think that the stop/start staves is currently exactly what it should do.
> It stops the staff at a location, and starts the staff at the same location.
> It reflects the commands that have been issued.  If the staff is continuous,
> there is no indication that the staff has been stopped and started.

I admit that i'm not experienced with staves that stop and start in
the middle of line.  I thought it looked weird, but i don't insist on
changing it; the most important thing is to make barlines look nice
on-screen.


2011/7/30  <pkx166h@gmail.com>:
> 2) Even if I did have a 'gap' between the lines why does it matter if
> they are rounded?

I guess it's (partly) because in LilyPond everything is rounded :)
It's the part of "Lily-looks".

cheers,
Janek

[c_sorensen, 2011-07-30 23:19:06]

On 7/30/11 3:35 PM, "pkx166h@gmail.com" <pkx166h@gmail.com> wrote:

> On 2011/07/30 16:15:39, c_sorensen_byu.edu wrote:
> 
> 
>> I think that the stop/start staves is currently exactly what it should
> do.
>> It stops the staff at a location, and starts the staff at the same
> location.
>> It reflects the commands that have been issued.  If the staff is
> continuous,
>> there is no indication that the staff has been stopped and started.
> 
>> Thanks,
> 
>> Carl
> 
> Err..why does there need to be an indication?

There probably doesn't.  But neither should we avoid having an indication
and drive the staff lines to be continuous.

> 
> The 'LP code' indicates it, I'm trying to think of a musical reason why
> this matters. Are we just splitting hairs here?
> 
> 1) If squaring up the lines helps and resolves more fundamental issues
> why do we care if I can't tell the difference when I've issued a stop
> and start immediately one after the other?

Squaring up the lines doesn't help.   Having the lines rounded works for
everything.  The rounded lines were proposed as a portential error when we
do stop/start at the same time.  I don't think they are an error.

> 
> 2) Even if I did have a 'gap' between the lines why does it matter if
> they are rounded?

Because in real engraving, all the outside corners are rounded.   It's a
characteristic of the tools used for engraving.

My point is only that this simultaneous start/stop should not be used as a
justification to eliminate rounding.

Thanks,

Carl

[James.Lowe_datacore.com, 2011-07-30 23:26:46]

Hello,
________________________________________
From: lilypond-devel-bounces+james.lowe=datacore.com@gnu.org
[lilypond-devel-bounces+james.lowe=datacore.com@gnu.org] on behalf of Carl
Sorensen [c_sorensen@byu.edu]
Sent: 31 July 2011 00:19
To: pkx166h@gmail.com; lemniskata.bernoullego@gmail.com; Han-Wen Nienhuys
Cc: reply@codereview.appspotmail.com; lilypond-devel@gnu.org
Subject: Re: Ends of barlines are hidden in staff lines. (issue4809057)

On 7/30/11 3:35 PM, "pkx166h@gmail.com" <pkx166h@gmail.com> wrote:

> On 2011/07/30 16:15:39, c_sorensen_byu.edu wrote:
>
>
>> I think that the stop/start staves is currently exactly what it should
> do.
>> It stops the staff at a location, and starts the staff at the same
> location.
>> It reflects the commands that have been issued.  If the staff is
> continuous,
>> there is no indication that the staff has been stopped and started.
>
>> Thanks,
>
>> Carl
>
> Err..why does there need to be an indication?

There probably doesn't.  But neither should we avoid having an indication
and drive the staff lines to be continuous.

>
> The 'LP code' indicates it, I'm trying to think of a musical reason why
> this matters. Are we just splitting hairs here?
>
> 1) If squaring up the lines helps and resolves more fundamental issues
> why do we care if I can't tell the difference when I've issued a stop
> and start immediately one after the other?

Squaring up the lines doesn't help.   Having the lines rounded works for
everything.  The rounded lines were proposed as a portential error when we
do stop/start at the same time.  I don't think they are an error.

>
> 2) Even if I did have a 'gap' between the lines why does it matter if
> they are rounded?

Because in real engraving, all the outside corners are rounded.   It's a
characteristic of the tools used for engraving.

My point is only that this simultaneous start/stop should not be used as a
justification to eliminate rounding.

---

OK I see (although I think we got off topic there) so why not make stop\start,
as an explicit command, rounded; and whatever you call 'end of barlines' that
are either \break-ed or whatever LP does when it starts a 'new line' squared?

James

[c_sorensen, 2011-07-30 23:30:59]

On 7/30/11 5:26 PM, "James Lowe" <James.Lowe@datacore.com> wrote:

> 
> OK I see (although I think we got off topic there) so why not make stop\start,
> as an explicit command, rounded; and whatever you call 'end of barlines' that
> are either \break-ed or whatever LP does when it starts a 'new line' squared?

No need to.  The rounded ends of staff lines work perfectly, as Janek's
tests showed.  The barline at the end works exactly right with the rounded
staff lines.

The patch Janek proposed, which makes the barlines end at the center of the
top and bottom staff lines, does exactly what we want.

Thanks,

Carl

[Neil Puttock, 2011-08-13 15:55:06]

http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc
File lily/bar-line.cc (right):

http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc#newcode40
lily/bar-line.cc:40: /* Due to rounding problems, barlines extending to the
outermost edges
bar lines

http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc#newcode43
lily/bar-line.cc:43: The solution is to extend barlines only to the middle
bar lines

http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc#newcode48
lily/bar-line.cc:48: SCM staff_color = Staff_symbol_referencer::color (me);
I think it's overkill to define a new method just to access 'color from a stave
(unless you plan on using it elsewhere)

SCM staff_color = staff->get_property ("color");

http://codereview.appspot.com/4809057/diff/1/lily/staff-symbol-referencer.cc
File lily/staff-symbol-referencer.cc (right):

http://codereview.appspot.com/4809057/diff/1/lily/staff-symbol-referencer.cc#...
lily/staff-symbol-referencer.cc:72: return ly_symbol2scm ("black");
'color is a list: (list R G B)

[janek, 2011-08-22 14:54:26]

Does this qualify for a regtest?

http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc
File lily/bar-line.cc (right):

http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc#newcode48
lily/bar-line.cc:48: SCM staff_color = Staff_symbol_referencer::color (me);
On 2011/08/13 15:55:07, Neil Puttock wrote:
> I think it's overkill to define a new method just to access 'color from a
stave
> (unless you plan on using it elsewhere)
> 
> SCM staff_color = staff->get_property ("color");

Of course!  I didn't know it was possible.
Good to have you in our team, Neil :)

So, everything looks pretty simple now.

[MikeSol, 2011-08-25 07:59:35]

Make sure to consider cases like:

\relative c'' {
  \stopStaff
  \override Staff.StaffSymbol #'line-count = #1
  \startStaff
  b1
  \stopStaff
  \revert Staff.StaffSymbol #'line-count
  \startStaff
  b1
}

I haven't tested it out to see if the result is meh, but if you think it leads
to a bad result, make sure to add a condition (like the color condition you
added) for barlines whose break direction is CENTER that have different
StaffSymbol grobs to the left and right.

Cheers,
MS

[janek, 2011-09-06 06:28:40]

On 2011/08/25 07:59:35, MikeSol wrote:
> Make sure to consider cases like:
> 
> \relative c'' {
>   \stopStaff
>   \override Staff.StaffSymbol #'line-count = #1
>   \startStaff
>   b1
>   \stopStaff
>   \revert Staff.StaffSymbol #'line-count
>   \startStaff
>   b1
> }

There are no problems with this example.

Pushed as b92ea16ef75d8aaa7bdb9f492b58d7af906e7945