issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[torsten . haemmerle]

Reviewers: ,

Message:
Please review...

Thanks,
Torsten

PS: no new regression test needed, there are loads of key cancellations
in the existing regression tests.

Description:
issue 5312: Key cancellation glyph position inconsistent

file lily/key-signature-interface.cc

Using two intervals representing the "vertical skylines" of two
adjacent natural glyphs. This makes a better model of the actual
glyph shape than the original single point within an inverval.
Now we can distiguish between all three cases:
(1) no overlap -> no additional kerning needed
(2) just touching (overlap, but intesection length 0) -> kerning 0.15
(3) overlapping -> kerning 0.3

Case (2) is the new one that couldn't be handled before:
Just touching at the corners made the glyphs cling together.

Basically same  interval technique as before, but I
renamed the Slices from
  pos and overlap_pos
to
  ht_right and last_ht_left.
Using quarter stave-spaces as to get a better (integer) resolution.

Please review this at https://codereview.appspot.com/343020043/

Affected files (+20, -8 lines):
  M Documentation/changes.tely
  M lily/key-signature-interface.cc


Index: Documentation/changes.tely
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index  
96748ad84dd8f2d91ae058f6545d1697c793b9c9..defcd4f1daabe11cc5855497e51137290de6297e  
100644

--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -62,6 +62,16 @@ which scares away people.
 @end ignore

 @item
+Slight padding added between natural glyphs just touching at the corners
+in key cancellations.
+@lilypond[verbatim,quote]
+{
+  \omit Staff.TimeSignature
+  \key ces \major s1 \key c \major s
+}
+@end lilypond
+
+@item
 Two new ornaments have been added.
 @lilypond[verbatim,quote]
 {
Index: lily/key-signature-interface.cc
diff --git a/lily/key-signature-interface.cc  
b/lily/key-signature-interface.cc
index  
79e2bd99482d25b8e5eb1fb10e9fb1ce2255cae7..0c4180d194a283799ff62398be04a2dda2893377  
100644

--- a/lily/key-signature-interface.cc
+++ b/lily/key-signature-interface.cc
@@ -58,7 +58,7 @@ Key_signature_interface::print (SCM smob)
 the cancellation signature.
   */

-  Slice pos, overlapping_pos;
+  Slice ht_right, last_ht_left; /* ht intervals for natural glyph kerning  
*/

   SCM last_glyph_name = SCM_BOOL_F;
   SCM padding_pairs = me->get_property ("padding-pairs");

@@ -87,14 +87,15 @@ Key_signature_interface::print (SCM smob)
 me->warning (_ ("alteration not found"));
   else
 {
-  pos.set_empty ();
+  ht_right.set_empty ();
   Stencil column;
   for (SCM pos_list =  
Lily::key_signature_interface_alteration_positions

  (scm_car (s), c0s, smob);
scm_is_pair (pos_list); pos_list = scm_cdr (pos_list))
 {
   int p = scm_to_int (scm_car (pos_list));
-  pos.add_point (p);
+  ht_right.add_point (2*p - 6);  /* descender */
+  ht_right.add_point (2*p + 3);  /* upper right corner */
   column.add_stencil (acc.translated (Offset (0, p * inter)));
 }
   /*
@@ -108,14 +109,15 @@ Key_signature_interface::print (SCM smob)
   padding_pairs);
   if (scm_is_pair (handle))
 padding = robust_scm2double (scm_cdr (handle), 0.0);
-  else if (glyph_name == "accidentals.natural"
-   && !intersection (overlapping_pos, pos).is_empty ())
-padding += 0.3;
+  else if (glyph_name == "accidentals.natural")
+if (!intersection (ht_right, last_ht_left).is_empty ())
+  padding += (intersection (ht_right, last_ht_left).length ()
+  ? 0.3 /* edges overlap */
+  : 0.15);  /* just touching at the corners */

   mol.add_at_edge (X_AXIS, LEFT, column, padding);

-  pos.widen (4);
-  overlapping_pos = pos + 2;
+  last_ht_left = ht_right + 3;  /* shift up (change to left side)  
*/

   last_glyph_name = glyph_name_scm;
 }
 }



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Carl . D . Sorensen]

LGTM.  I am just a *little* bit concerned about having the dimensions of
the Emmentaler natural glyph hardcoded in the source, but we already
have magic numbers reflecting the characteristics of the Emmentaler
glyphs.

Maybe it would be good to put a FIXME in recognizing this fact.  Or
maybe we just go as-is.


https://codereview.appspot.com/343020043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[torsten . haemmerle]

On 2018/04/24 17:59:31, Carl wrote:

LGTM.  I am just a *little* bit concerned about having the dimensions

of the

Emmentaler natural glyph hardcoded in the source, but we already have

magic

numbers reflecting the characteristics of the Emmentaler glyphs.



Maybe it would be good to put a FIXME in recognizing this fact.  Or

maybe we

just go as-is.


Hi Carl,

The intervals are just *approximating* the outlines of a run-of-the mill
natural glyph. I even played around with the concept using squared
paper.
This approach more or less relies on the fact that the
square/parallelogram
part of a natural glyph will be one stave-space high independent of the
font
used, just like a notehead in *any* font will be one stave-space high.

Therefore, it will also work for Gonville, Bravura, all of Abraham's
fonts...
Funny enough, it works for the LilyJAZZ font, too, because even in this
pseudo
handwritten font the square/parallelogram part has the same (standard)
height.

All the best,
Torsten

https://codereview.appspot.com/343020043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Carl . D . Sorensen]

On 2018/04/24 18:43:45, Be-3 wrote:


The intervals are just *approximating* the outlines of a run-of-the

mill

natural glyph. I even played around with the concept using squared

paper.

This approach more or less relies on the fact that the

square/parallelogram

part of a natural glyph will be one stave-space high independent of

the font

used, just like a notehead in *any* font will be one stave-space high.


So it's a reasonable approximation that the box part of the natural will
extend
about 3/4 staff spaces above the staff position of the natural, and the
descender
will  descend about 1.5 staff spaces below.

Seems like a reasonable estimate to me, even if it's not exact for a
particular font.
You can't get too far away from that and still fit in a staff.

Thanks,

Carl


https://codereview.appspot.com/343020043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[torsten . haemmerle]

On 2018/04/24 21:49:37, Carl wrote:

On 2018/04/24 18:43:45, Be-3 wrote:



> The intervals are just *approximating* the outlines of a run-of-the

mill

> natural glyph. I even played around with the concept using squared

paper.

> This approach more or less relies on the fact that the

square/parallelogram

> part of a natural glyph will be one stave-space high independent of

the font

> used, just like a notehead in *any* font will be one stave-space

high.


So it's a reasonable approximation that the box part of the natural

will extend

about 3/4 staff spaces above the staff position of the natural, and

the

descender
will  descend about 1.5 staff spaces below.



Seems like a reasonable estimate to me, even if it's not exact for a

particular

font.
You can't get too far away from that and still fit in a staff.



Thanks,



Carl


Agreed, Carl,

And, IMHO, there is no need for exaggerated exactness: as soon as two
corners get too close (no matter how close exactly), we need a wee bit
of extra padding.
The main reason for the 3/4 staff spaces, to be honest, was that the two

intervals will be just touching (with intersection length 0) for the
corner-to-corner constellation.

All the best,
Torsten

https://codereview.appspot.com/343020043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Joram]

Will it also look good for custom key signatures?

\relative {
  \set Staff.keyAlterations = #`((6 . ,FLAT)
 (5 . ,FLAT)
 (3 . ,SHARP))
  c'4 d e fis
  aes4 bes c2
  \key c \major
  c
}

Best,
Joram

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Torsten Hämmerle]

Joram Berger wrote
> Will it also look good for custom key signatures?

Hi Joram,

Well, in your example, there will be no difference between the old and new
coding:

The first two naturals with full overlap get a maximum extra padding of 0.3,
the second and third naturals are (vertically) so far apart that there will
be no extra padding at all.

In general, the algorithm can cope with custom key signatures as it compares
the individual vertical distance between neighbouring naturals and decides
whether to add extra padding (and how much) or not.

The following illustration (linked from issue #5312) compares the old and
new algorithm.


 

Even if not all constellations that may occur in custom key signatures are
directly shown, you can see that the algorithm (checking if the intervals
marked in green touch, overlap or don't overlap) generally will work for any
interval and thus for any custom key signature.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Noeck]

Hi Torsten,

I've confidence in your algorithm. I just thought I post a situation
which I would have neglected at first – without knowing what your
algorithm does.

Thanks for your explanation! It seems pretty robust and straightforward
to me, now. Are the two algorithms the equivalent if you make the green
line of the old algo ½ a staff space longer and add the "just touching"
case?

One more question: How do you produce those images? They look too
perfect to be drawn by hand (Inkscape etc.) but they're also too far
from music notation that I would want to produce them via LilyPond.

Cheers,
Joram

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Torsten Hämmerle]

Noeck wrote
> I've confidence in your algorithm. I just thought I post a situation
> which I would have neglected at first – without knowing what your
> algorithm does.

Hi Joram,

It's good have asked, it is just too easy to overlook things...



Noeck wrote
> Thanks for your explanation! It seems pretty robust and straightforward
> to me, now. Are the two algorithms the equivalent if you make the green
> line of the old algo ½ a staff space longer and add the "just touching"
> case?

Radio Yerevan's answer: "In principle, yes." ;) 
See illustration with the original algorithm adapted following your proposal
(additional interval length marked in light green), including two custom
cases that don't occur in standard key signatures.


 


*Why I didn't do it that way:*
Technically, even the "points" in the original algorithm were intervals,
e.g. a point at y = 5 was represented by the interval [5:5].
We use integer intervals (called "Slices" for an unknown reason) and in
order to get a finer resolution (half space), /every/ value assignment
changes, anyway.

But the main reason was the way to check the "touching" case:
If there's an intersection, it's easy to distinguish between "touching"
(intersection length 0) and "overlapping" (intersection length > 0).
Compared to this, a mere point (i.e. zero-length interval) will always yield
a zero length intersection even in the midst of the other interval and we
need to compare distances...

All in all, I considered it much more straightforward to represent the
neighboring edges as what they really are: intervals of a certain length
that either intersect, touch, or don't intersect at all.

And the original point solution had the same technical complexity, as the
"point" was nothing but another interval, albeit of zero length.



Noeck wrote
> One more question: How do you produce those images? They look too
> perfect to be drawn by hand (Inkscape etc.) but they're also too far
> from music notation that I would want to produce them via LilyPond.

I hardly dare to admit it, but all I used was Windows' infamous Paint
program (a simple raster graphics editor).
As a basis, I used a LilyPond screenshot, moved things around and inserted
pixel based elements.


All the best and thanks for your interest,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Karlin High]

On 4/26/2018 5:13 AM, Torsten Hämmerle wrote:

I hardly dare to admit it, but all I used was Windows' infamous Paint
program (a simple raster graphics editor).
As a basis, I used a LilyPond screenshot, moved things around and inserted
pixel based elements.



--
Karlin High
Missouri, USA

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Noeck]

Am 26.04.2018 um 12:13 schrieb Torsten Hämmerle:
> I hardly dare to admit it, but all I used was Windows' infamous Paint
> program 

:D


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel