gmane.comp.gnu.lilypond.devel

Re: fixing PNG images

Werner LEMBERG — 2013-05-23T16:42:36


This is a good question.  IIRC, the libpng people say that a
yet-to-be-identified program or library creates such faulty PNG
files.  From the manual:

  Libpng-1.6.0 and later use the CMF bytes at the beginning of the
  IDAT stream to set the size of the sliding window for reading
  instead of using the default 32-kbyte sliding window size.  It was
  discovered that there are hundreds of PNG files in the wild that
  have incorrect CMF bytes that cause libpng to now issue a "too far
  back" error and reject the file.  Libpng-1.6.3 provides a way to
  revert to the libpng-1.5.x behavior (ignoring the CMF bytes and
  using a 32-kbyte sliding window), and provides a tool
  (contrib/tools/png-fix-too-far-back) for optimizing the CMF bytes
  correctly.


    Werner

Re: fixing PNG images

David Kastrup — 2013-05-23T16:05:00


How did the problematic PNG files come about?

fixing PNG images

Werner LEMBERG — 2013-05-23T15:49:33

I've just been bitten by the following libpng `feature':

  IDAT: invalid distance too far back

(file `lily-ledger.png', while being processed by pdftex).
Apparently, libpng 1.6.x no longer accepts PNG images with this
problem out of the box.

Note that libpng comes with a tool called `png-fix-too-far-back' to
fix such errors in PNG files.  Is it OK to update all PNG files in the
lilypond repository?  I've been able to successfully continue
compilation with the current SVN TeXlive binaries after running this
program on all PNG images.


    Werner

Re: ugly: accidental reminders and ties

David Kastrup — 2013-05-23T13:31:00


Huh.  I've taken a look at the commits in between, and they contain doc
fixes, the big eventchord changes (including the reimplementation of
repeat chords) and basically not much else apart from

commit 05b311f14f39e5148ca93028a314a0bb2fe0dedd
Author: Carl Sorensen <c_sorensen< at >byu.edu>
Date:   Wed Jan 18 13:15:20 2012 -0700

    Add option for strictBeatBeaming
    
    This reverts to the default behavior from 2.14 that places a higher
    priority on avoiding beamlets than on beaming to the beat.
    
    At the user's option, beaming can be strictly to the beat.

which should not really be related.  So it would seem that the
EventChord thingies (issue 2240 I think) would be related, but those
should not actually affect the events seen by the engravers (possibly
their order?) here.  So maybe that is some cyclic evaluation dependency
thing again, and the shakeup from issue 2240 is enough to throw the
cycle into a different configuration.

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

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/