gmane.comp.gnu.lilypond.devel

Re: ugly: accidental reminders and ties

Eluze — 2013-05-23T11:39:45

Werner LEMBERG wrote

2.15.28 is the first to show this

Eluze



--
View this message in context: http://lilypond.1069038.n5.nabble.com/ugly-accidental-reminders-and-ties-tp146220p146223.html
Sent from the Dev mailing list archive at Nabble.com.

Re: ugly: accidental reminders and ties

Werner LEMBERG — 2013-05-23T11:17:03

Yes.  I don't have an older lilypond binary at hand, but I have a gut
feeling that (much?) older versions don't show this.


Indeed, especially since it is very easy to forget this behaviour.a


I vote for fixing that, even if hard-wiring is needed.


    Werner

Re: ugly: accidental reminders and ties

David Kastrup — 2013-05-23T10:57:38


Well, you presumably complain about the tie positioning.  I find myself
also annoyed with the repetition of the reminder accidental.  Since it
is merely a property on a note-event, the normal event-based
configurable filtering mechanism for repeat chords is not enough for
stripping this out: one would have to hardwire removing cautionary and
forced accidentals into copy-repeat-chord.

ugly: accidental reminders and ties

Werner LEMBERG — 2013-05-23T10:27:32

[release/2.17.18-1-25-gb2863ab]

This code

  \relative c' {
    <f! fis'>1 ~ | q |
    <f fis'>1 ~ | q |
  }

produces the attached image.  Is this a known issue?


    Werner
_______________________________________________
lilypond-devel mailing list
lilypond-devel< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Help with page breaking code

David Kastrup — 2013-05-23T09:42:47


That sounds to me like a problem of absolutistic tallying.  The cutters
for start of page and end of page keep separate and independent tallies
of the paper roll, and use their own tallying methods.  With -inf.0,
they don't manage resynchronizing ever.  But issue 3341
<URL:http://code.google.com/p/lilypond/issues/detail?id=3341> suggests
that resynchronization is flaky even in straightforward situations
involving forced breaks.

Re: Help with page breaking code

David Kastrup — 2013-05-23T09:32:54


Thanks, that's good to know.

Re: Help with page breaking code

Keith OHara — 2013-05-23T00:41:55



The page-breaker seems to be allowing for a markup that has something 100
staff-spaces away from its baseline.

The page-spacing seems to be doing its job, given the page-breaks, and
realizing that \ugly actually requires no space.

Page_breaking::compute_line_heights()
looks at the individual ends of the y-extent of a line of markup, and
uses the first line to initialize a set of variables that remember some
things about the previous line.

Re: Help with page breaking code

Thomas Morley — 2013-05-22T23:13:55

2013/5/22 David Kastrup <dak< at >gnu.org>:

FWIW, I can confirm with:
2.17.17
2.16.2
2.14.2

Though, 2.12.3 returns correct output.

-Harm

Re: Help with page breaking code

David Kastrup — 2013-05-22T20:54:08

And another one:

#(define-markup-command (ugly layout props) ()
  (ly:make-stencil (ly:stencil-expr (interpret-markup layout props "x"))
   '(0 . 0) '(0 . -100)))

\markup \ugly
\markup *
\markup *
\markup *
\markup *

This puts everything right after another on a single page.  If you
replace the -100 with -1000, it puts the last star on a page of its own
and spreads the other three starts widely on the first page.  If you
replace the -100 with -inf.0, it places every star on its own page.

Yes, we are talking about 2.16.0 as well.  This makes precious little
sense.

Re: Help with page breaking code

David Kastrup — 2013-05-22T19:08:10


Maybe related to issue 3341
<URL:http://code.google.com/p/lilypond/issues/detail?id=3341>?

That also looks like a bleedover problem with page breaking variables.

Re: Help with page breaking code

David Kastrup — 2013-05-22T18:21:47


Here is an even worse example:

#(define-markup-command (ugly layout props) ()
  (ly:make-stencil '() empty-interval empty-interval))

\markup \ugly
\markup *
\markup *
\markup *
\markup *

As you can see, just inserting the single \ugly markup poisons the page
breaker permanently, so that it will need one page per * afterwards.
This is for current master, not anything more special.

And while I tend to blame the new skyline spacing for everything under
the sun, it turns out that LilyPond 2.16.0 exhibits exactly the same
problem.

You might want to claim that this is a case of "don't do that then", but
I very much doubt that illegitimate carry-over will occur only for these
particular values.

PATCHES: Countdown for May 25 - 06:00GMT

James — 2013-05-21T18:25:21

Hello,

     *Countdown – May 25 – 06:00 GMT* *
* *
* *
* *
* *
* *
*  *
* *
* *
* *
* *
* *
* *
*






 3330<http://code.google.com/p/lilypond/issues/detail?id=3330&q=label%3APatch-review&sort=patch&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified>
Defect
David Kastrup push bracketify-stencil moves grob's refpoint 9 hours ago
<http://code.google.com/p/lilypond/issues/detail?id=3330&q=label%3APatch-review&sort=patch&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified>
 3368<http://code.google.com/p/lilypond/issues/detail?id=3368&q=label%3APatch-countdown&sort=patch&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Summary%20Modified>
Documentation
David Kastrup push Patch: Give additional info about Xpdf versions crashing
under Ubuntu moments ago
<http://code.google.com/p/lilypond/issues/detail?id=3368&q=label%3APatch-countdown&sort=patch&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Summary%20Modified>
   3360<http://code.google.com/p/lilypond/issues/detail?id=3360&q=label%3APatch-countdown&sort=patch&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Summary%20Modified>
Critical
Keith O'Hara push \balloonLengthOn doesn't work any more   Regression moments
ago
<http://code.google.com/p/lilypond/issues/detail?id=3360&q=label%3APatch-countdown&sort=patch&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Summary%20Modified>







 3255<http://code.google.com/p/lilypond/issues/detail?id=3255&q=label%3APatch-countdown&sort=patch&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Summary%20Modified>
Defect
Keith O'Hara countdown \with-dimensions doesn't affect the overall size of
a TextScript   Regression


Regards

James
_______________________________________________
lilypond-devel mailing list
lilypond-devel< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCH MERGING - notification of 'downtime'

James — 2013-05-21T11:36:01

Hello,

I am having some impromptu work done at home that will mean I will have
very intermittent (if any) internet access from my server for the next few
days.

So I will run the patch countdown tonight instead of tomorrow morning and
leave Patchy running overnight for any merges.

I'm not sure yet if I will be able to continue to run Patchy while this
work is being done, but the estimated _maximum_ downtime' is from Wednesday
AM until end of Friday when I get back from work - roughly 7-8pm GMT.

I do apologize for the short notice and inconvenience.

James
_______________________________________________
lilypond-devel mailing list
lilypond-devel< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: mpost assertion failure

Werner LEMBERG — 2013-05-21T04:56:33


I've just tested the updated i386-linux mpost binary in TeXLive
(rev. 30602), and I get exactly the same assertion, unfortunately.


    Werner

Re: [tex-live] mpost assertion failure

Werner LEMBERG — 2013-05-20T14:33:30


Thanks.  It seems to be a compiler issue, as Peter's e-mail indicates.


    Werner

mpost assertion failure

Werner LEMBERG — 2013-05-20T07:31:07

[This is the i386-linux 2013 binary of mpost, version 1.802,
 TeXLive SVN rev. 30584]

I've just got this while processing lilypond's fonts:

  mpost: ../../../texk/web2c/mplibdir/mp.w:2968:
    mp_free_value_node: Assertion `p->has_number==2' failed.

Attached are the input files to reproduce the assertion.  Note that
the code has always worked without any problems.


    Werner
_______________________________________________
lilypond-devel mailing list
lilypond-devel< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Give additional info about Xpdf versions crashing under Ubuntu (issue9437043)

2013-05-20T07:20:16

LGTM.  It's unfortunate that we need to add warnings for bugs like this
that Ubuntu has known about for years (and has already fixed once before
they broke it again!), but I think this case warrants it.

https://codereview.appspot.com/9437043/

Re: Beams: be transparent if the first stem is transparent; issue2866 (issue 9239046)

2013-05-20T06:53:40

Reviewers: dak,

Message:
On 2013/05/15 07:45:21, dak wrote:


https://codereview.appspot.com/9239046/diff/1/scm/music-functions.scm#oldcode1947

Probably so, but I think changing it with this unrelated change
complicates the history more than it would improve the clarity.

Description:
Beams: be transparent if the first stem is transparent; issue 2866

so that \hideNotes does not hide automatic beams that could have,
but did not, start on a hidden note.

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

Affected files:
   M ly/property-init.ly
   M scm/define-grobs.scm
   M scm/music-functions.scm


Index: ly/property-init.ly
diff --git a/ly/property-init.ly b/ly/property-init.ly
index  
1c97c04fabf096b6f496cfe9a1ad521fdd59b255..b7962ecf2c15c9a6be9786039d12c69f7fd5eb37  
100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
< at >< at > -265,14 +265,12 < at >< at > hideNotes = {
    \override NoteHead.no-ledgers = ##t
    \override Stem.transparent = ##t
    \override Flag.transparent = ##t
-  \override Beam.transparent = ##t
    \override Accidental.transparent = ##t
    \override Rest.transparent = ##t
    \override TabNoteHead.transparent = ##t
  }
  unHideNotes = {
    \revert Accidental.transparent
-  \revert Beam.transparent
    \revert Stem.transparent
    \revert Flag.transparent
    \revert NoteHead.transparent
Index: scm/define-grobs.scm
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index  
1b1df433c659a35c0695e8ba5820079e5a161684..0826d15203e9da4bc4658d530d7a4bf5dbb19c8b  
100644
--- a/scm/define-grobs.scm
+++ b/scm/define-grobs.scm
< at >< at > -410,6 +410,8 < at >< at >
  (positions . ,beam::place-broken-parts-individually)
  (springs-and-rods . ,ly:beam::calc-springs-and-rods)
  (X-positions . ,ly:beam::calc-x-positions)
+        (transparent . ,(grob::inherit-parent-property
+                         X 'transparent))

  ;; this is a hack to set stem lengths, if positions is set.
  (quantized-positions . ,ly:beam::set-stem-lengths)
Index: scm/music-functions.scm
diff --git a/scm/music-functions.scm b/scm/music-functions.scm
index  
16e035bcbbe1ea71b1afc0ae6869d238f7675837..b08ecb7fab13958552ee86cf640cd128b6f04862  
100644
--- a/scm/music-functions.scm
+++ b/scm/music-functions.scm
< at >< at > -1945,7 +1945,7 < at >< at > base onto the following musical context."
                  (blot (ly:output-def-lookup layout 'blot-diameter)))
             ; Hide spanned stems
             (map (lambda (st)
-                  (set! (ly:grob-property st 'transparent) #t))
+                  (set! (ly:grob-property st 'stencil) #f))
               stems)
             ; Draw a nice looking stem with rounded corners
             (ly:round-filled-box (ly:grob-extent root root X) yextent blot))

Re: Help with page breaking code

David Kastrup — 2013-05-20T05:05:13


Actually, the current code makes \line { } empty to match \fill-line.
If you make \fill-line { } non-empty, lots of page headers take up space
even when empty.  Not an option.



I can factor and/or leave this out since the bad code had no effect
previously, and it has no effect in the current iteration, but it's
peanuts.


Not really, because \hspace can (and should be able to) backspace, and
empty-stencil in its current definition is a backspacing stencil.

An any rate: Whatever code in the current code base requires
empty-stencil to not have empty-interval as extents will mess up page
size calculations: if it takes (+inf.0 . -inf.0) wrongly into account,
it will do so with (+1.0 . -1.0) as well since the latter is even less
conspicuous and thus will not get special treatment when it should.

We have reports about the general page breaking having become inferior
with 2.16 and/or 2.17.  Ignoring a bug in that area or even tampering
with new code until it for some unknown reason perhaps avoids it is not
a sane course.

Re: Help with page breaking code

Keith OHara — 2013-05-20T02:49:58



\paper {annotate-spacing = ##t}
indicates proper estimates for any scores after the \fill-line, and
indirectly shows zero space allowed for the \fill-line, so the
height estimations seem reasonable.

The problem appears only when \fill-line is the first markup, so maybe
a bad initialization in one of
page-breaking.cc  page-layout-problem.cc  page-spacing.cc

At some point, you made a change so that \line {} would return a
non-empty extent; possibly \fill-line needs that as well.

Of course I recommend first fixing the bugs you can with the existing
definition of "empty" stencil extents.  The redundant line in dots.cc,
the ref-point for \parenthesize, and having the spacing functions
recognize \hspace and space appropriately, can be resolved before
changing 'empty-stencil'.

Re: Help with page breaking code

David Kastrup — 2013-05-19T17:10:34


This one is likely easier to debug:

#(set! empty-stencil (ly:make-stencil '() empty-interval empty-interval))
\markup \fill-line { }
\markup *
\markup *
\markup *
\markup *
\markup *
\markup *
\markup *
\markup *