Please forgive me for bumping this discussion, but I was wondering if
Valentin,
I am sorry I have disappeared from the Lilypond scene for a while.
My work on Lilypond development has been temporarily put on the back
burner. Right now, we are concentrating on something slightly
different: w
Hi Richard,
I believe this is another manifestation of the bad patch for 1062 which
Joe reverted a few days ago. The fix is in Git.
Boris
On 06/29/2010 03:41 AM, Richard Sabey wrote:
I am not top-posting.
% If the music has at least one tall system and many vertically-short systems,
Is it not the same issue as this one?
http://article.gmane.org/gmane.comp.gnu.lilypond.bugs/18619
This bug has been poisoning my life since January -- I have had
different fixes in my repo, but hopefully that last patch is the Real
Fix. We have to wait for Joe to approve it.
Nicolas, can you
On 05/30/2010 03:52 AM, Joe Neeman wrote:
IIRC, tight-spacing just means to place lines as close together as
possible (which means a tight spring and a padding of zero).
That's what the code in page-layout-problem seems to be doing -- so I
based my patch to page-breaking on simply trying to ma
Hi Joe,
The fact that tight-spacing ignores padding is probably a bug. Do things
work better if you change minimum_distance to (minimum_distance +
padding) in page-layout-problem.cc:286?
As I had posted earlier, changing to (minimum_distance+padding) does
fix exactly the issue I was ref
On Sun, 9 May 2010 11:01:28 (UTC), Oliver Penrose wrote:
Please explain to me how to install the LILYPOND program on my X22
laptop, which
> is using UBUNTU.
Hi Oliver,
This question is best to ask on the lilypond-user list, not the bug
list; but here is an answer for you anyway:
Yo
Neil,
Is something further expected from me on this bug?
After I modified patch 908045 per your suggestions, I was expecting you
to approve and push it?
Boris
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/
On Sun, 25 Apr 2010 17:31:42 (UTC), Trevor Skeggs wrote:
Why should 3 not be a valid duration, mid-way between 2 and 4?
> (It would have the same value as a dotted 4).
>
> After all, if the program is going to the trouble of weeding-out
> these values and printing an
On Thu, 22 Apr 2010 13:39:35 -0700, Joe Neeman wrote:
Never mind, I just did that hunk manually and pushed.
Then, I am marking bug 1053 as fixed.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lily
What makes me really depressed about the situation with pure-height, is
that we have fixed a number of "reasonable" bugs in this area
(intersystem begin/rest, overridden stem length, deprecated space,
padding of markup -- these are the ones that I did in the immediate
past, -- the slur fix from Jo
On Wed, 21 Apr 2010 20:37:52 -0400, Boris Shingarov wrote:
not closer to having reasonable trouble-free page layout, but starting
> to look at page overfill/underfill problems which are very deeply
> rooted in the nature of pure-height estimation.
I meant Bug 1061 in part
Ok, latest patch is uploaded now.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
On Tue, 20 Apr 2010 07:28:49 0200 (CEST), Martin Tarenskeen wrote:
Did you start evince from the commandline ?
Yes, of course.
Which version of poppler do you use?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.
Hi Joe,
Have you seen the last patchset I uploaded to Rietveld 3 days ago? Is
there anything expected from me at this point to further the progress
on this bug?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinf
I am not getting anything abormal when viewing your example with my
local installation of evince (evince 2.28.1, poppler 0.12.0(cairo)).
Nor do Okular nor Acrobat report anything bad.
On Mon, 19 Apr 2010 21:58:38 0100, Neil Puttock wrote:
On 19 April 2010 18:01, Graham Percival wrote:
>
> >
Hi Neil,
It's measured in half staff-spaces, so the default length is 7 (i.e., 3.5
> staff-spaces).
Quite apart from the height estimation, what is the supposed correct
semantics of 'length anyway?
It looks like it's interpreted as the distance between the end of the
stem and the midline??
(T
Ah, you might want to install git-cl, which is a git interface to the
> upload.py script
Thanks -- this does make life a lot easier!!!
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Hi Neil,
If you use the same test branch as your original patch (which is
> associated with a particular issue on Rietveld), you can just apply
> the revised patch and upload again (git-cl will ask you for a
> description which becomes the title of the new patch set on Rietveld.)
I am not s
On Mon, 12 Apr 2010 20:57:00 0100, Neil Puttock wrote:
On 12 April 2010 18:46, Boris Shingarov wrote:
> > Ok, this patch is ready for code review:
> > http://codereview.appspot.com/872044
>
> Can you add this to the previous patch set so it's easier to see
>
Ok, this patch is ready for code review:
http://codereview.appspot.com/872044
On Thu, 08 Apr 2010 23:47:15 -0700, Joe Neeman wrote:
On Mon, 2010-04-05 at 03:00 -0400, Boris Shingarov wrote:
> > > >Grob *alignment = get_vertical_alignment (); //TODO check for null
> >
Alternatively, you could just check explicitly for an
> empty result in System::part_of_line_pure_height.
And if it's empty, then not do the translation at all, right?
Will do this right now and see how much better this
gets us.
BTW, what is the correct (supposed) way to run the
regtests? I
On Thu, 08 Apr 2010 23:47:15 -0700, Joe Neeman wrote:
> But what do we do if it's null?
> Maybe print a programming_error and return an empty extent? It doesn't
> particularly matter what you do, just don't crash.
But it's never null, on any input that I've seen. Not on any of the regtests
returns
an empty vector of offsets when called from
System::part_of_line_pure_height(),
but the corresponding vector of staves is non-empty, which causes
a segfault when trying to translate the 0th staff.
On Sun, 04 Apr 2010 11:47:48 -0700, Joe Neeman wrote:
On Wed, 2010-03-31 at 01:46 -0
Hi Joe,
You'll need to do something better here, rather than just leaving all
> the extent information out for markup blocks.
Right, this is exactly why that oldest version of the patch was segfaulting.
The second version (attached to the bug and formatted
on codreview.appspot, also linked
Ok, I changed the Owner, but I don't see how I am supposed to change
the Status, etc.
Becoming blind?
On Thu, 1 Apr 2010 07:42:08 0100, Graham Percival wrote:
On Thu, Apr 1, 2010 at 5:23 AM, Boris Shingarov wrote:
> > Ok, so I created Issue 1053. The next logical step would be to
Ok, so I created Issue 1053.
The next logical step would be to assign this to myself, indicating
that I am working on the code to fix it, and link from the bug report
to the patch. Can I do this?
On Wed, 31 Mar 2010 03:47:27 -0400, Boris Shingarov wrote:
Hi Dmytro,
>
> > where it
On Wed, 31 Mar 2010 01:46:12 -0400, Boris Shingarov wrote:
> Here is the patch for the "begin/rest-of-line" problem.
Wooo, hang on, my patch is sour! It segfaults if the system is not a
group of staves -- for example, this is the case of markup.
Hi Dmytro,
where it is a bug and where it is not. But if you can provide a minimal
> example, it will be easier.
The idea definitely is to provide a minimal example. Otherwise, it
does not count as a bug report, and shouldn't really even be posted on
the -bug list.
The problem is that our
Hi Dmytro,
If you will not add this issue at the tracker (as Graham mentioned), i
> guess i will.
I'll do it, but I'll ask you qustions if I stumble upon something
unclear, because I am new to the Lilypond bug procedure.
Boris
__
Hi Graham,
I'm doing everything I can to increase the number of people involved
> in lilypond, including the bug squad. If you would like to volunteer
> to help with this, I'd love to have you on board.
My involvement with Lilypond is pragmatic.
I am enabling the publication of a top-quali
Hi Graham,
If you send a minimal example to this list, and no developer
> responds within a few days to begin discussing a patch, then I
> would expect somebody to add it to the tracker. I'm not certain
> if that has always happened, though.
So in other words, not all bugs have bug report
s reports
here, but never actually saw it result in a tracked report.
What is the correct procedure?
--
Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/0419
diff --git a/lily/constrained-breaking.cc b/lily/cons
On Tue, 30 Mar 2010 08:08:41 -0400, Boris Shingarov wrote:
Ok, it's fully functional now.
> I am going to format and upload a patch.
Hmmm... still overestimates on my "real-life" manuscript, even though
several different scenarios (with and withou lyrics) which were
res
Ok, it's fully functional now.
I am going to format and upload a patch.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
dynamic_cast? (or maybe my mind is corrupted by 15 years
> of Smalltalk, and this is a standard C quirk?)
Oops, keyboard failure, obviously meant "C quirk"!
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailma
Replace constrained-breaking.cc:461 by
>
> Interval begin_extent = sys->begin_of_line_extent (start, end);
> Interval rest_extent = sys->rest_of_line_extent (start, end);
Ok, experimenting with this, I am inclined to *add* instead of
*replacing*. The extent_ member of Line_details is touche
Hi Joe,
Replace constrained-breaking.cc:461 by
>
> Interval begin_extent = sys->begin_of_line_extent (start, end);
> Interval rest_extent = sys->rest_of_line_extent (start, end);
>
> and replace constrained-breaking.cc:485 by something analogous.
Btw, it's not clear to me what the invers
I'd rather discuss this point now, because I don't like the extension of
> Interval (and I'd rather you didn't spend a whole lot of time getting it
> to work if there is a nicer way)
No kidding, neither do I like diluting Interval. One, it is an extremely
hacky way to do things. Two, it *do
On Mon, 29 Mar 2010 12:04:42 -0700, Joe Neeman wrote:
but I think you don't need to store an
> extra version of rod-height. Just define rod-height to measure the
> bottom of the last staff (whether that bottom comes from
> begin_of_line_extent or rest_of_line_extent). Each time you add a sta
Do we really need this to be included in every Interval? I'd have
> thought that the only data structure that needs to change is
> Line_details.
Right, but how do you get the actual value in there?
It's filled from calling the Y-extent Scheme function, which can be
anything, and in most cases
On Mon, 29 Mar 2010 08:48:35 -0700, Joe Neeman wrote:
Keep in mind that a lyric line is the same as a staff to the
> page-breaker. Don't your one-staffers have lyrics? If so, they are
> really two-staffers and so the problem could still be in the
> within-system estimation.
My one-staffe
Looking at Page_breaking::min_page_count(), I am thinking
> about the correct generalization of the concept of "rod_height",
> so that we would still have one "current position", but two
> "current bottom edges" (so the next current position is calculated
> by juxtaposing the next system's tw
First of all, thank you Joe for all the explanations -- now that it
has dawned on me what the source of confusion was, it all
makes sense. Thanks!!
I am now thinking about how to implement this TODO best.
> One idea that immediately comes to mind, is to replace the
> unified heights with be
On Wed, 24 Mar 2010 18:15:45 -0400, Boris Shingarov wrote:
Hmm, let me understand this better.
> Does it mean that Constrained_breaking::fill_line_details() gets
> called before the line breaks are calculated, and then again after
Oh, now I understand why!!! The hack addresses the
Right, the positions of the staff lines relative to each other are not
> yet computed, so each extent is relative to its own staff.
Hmm, let me understand this better.
Does it mean that Constrained_breaking::fill_line_details() gets
called before the line breaks are calculated, and then again a
On Wed, 24 Mar 2010 14:19:21 -0700, Joe Neeman wrote:
Right, but in align-interface.cc:118, we throw away that unite()d extent
> in favour of a begin_of_line_extent and a rest_of_line_extent.
But that, IIUC, is only happening one level (of the grob tree) above,
when it's too late, no? That
On Wed, 24 Mar 2010 16:08:51 -0400, Boris Shingarov wrote:
What happens in reality, is that pure_height() of the VerticalAxisGroup,
> calling ly:hara-kiri-group-spanner::y-extent in Scheme land,
> calling back Hara_kiri_group_spanner::pure_height(), ultimately
> e
The skylines are used as part of VerticalAlignment, to figure out how
> far apart the children of VerticalAlignment (ie. VerticalAxisGroups for
> staves, lyrics, etc) need to be. Once we compute the translations of the
> children of VerticalAlignment, we can compute the height of
> VerticalAl
The estimated height for the whole system _should_ take into account the
> fact that the lyrics can be squeezed between the systems. Have a look at
> the comment in align-interface.cc:104 (which should get called as a
> result of sys->pure_height()). The begin_of_line_extent should be zero
>
> The estimated height for the whole system _should_ take into account the
> fact that the lyrics can be squeezed between the systems. Have a look at
> the comment in align-interface.cc:104 (which should get called as a
> result of sys->pure_height())
Trying to make head or tail of which chi
On Fri, 19 Mar 2010 17:15:08 -0400, Boris Shingarov wrote:
> As to the call to get_skylines(), now I am really confused. All this
> (get_property("springs-and-rods") resulting in
> Spacing_spanner::set_springs() and all the other things down the road
> being
On Fri, 19 Mar 2010 13:39:36 -0700, Joe Neeman wrote:
The begin_of_line_extent should be zero
> for lyrics, which should allow the lines to be close together in the
> height-estimation procedure.
The difficulty of debugging this, is how do I tell which grob is
which. They are Scheme poi
Hi Joe,
Thanks for the tips, and have a nice and safe trip!
> The estimated height for the whole system _should_ take into account the
> fact that the lyrics can be squeezed between the systems. Have a look at
> the comment in align-interface.cc:104 (which should get called as a
> result
Here are the two illustrative examples.
On Fri, 19 Mar 2010 11:05:30 -0400, Boris Shingarov wrote:
On Wed, 13 Jan 2010 19:37:14 1100, Joe Neeman wrote:
>
> > It's nice to see someone else touching the page-breaking code
>
> The more I dig into it, the more questi
On Wed, 13 Jan 2010 19:37:14 1100, Joe Neeman wrote:
> It's nice to see someone else touching the page-breaking code
The more I dig into it, the more questions I have.
Back in January, we talked about vertical space estimation in the case of Prob
(i.e. markup); now I am investigating vert
hough only in terms of stencils), and what is yet to be built,
looking forward (although only in terms of markups).
Quoting Boris Shingarov :
Ok, I created a patch:
http://codereview.appspot.com/207105
___
bug-lilypond mailing list
bug-lilypond@gn
>> Of course, combine-score-stencils needs a real implementation, not just
>> (reverse stencils).
Ok, I created a patch:
http://codereview.appspot.com/207105
Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Projec
Quoting Neil Puttock :
recent changes to the markup code (not least that there's no
define-builtin-markup-command any more).
Uh oh. Means I have to catch up with the latest master asap, otherwise
I am producing obsolete, unmergeable code.
Funny that I have not seen any discussion around th
Quoting Nicolas Sceaux :
Why not defining e.g. a score-lines markup list command, which can be
used in situations where it is preferable to get one stencil per system.
Hmm, this is certainly an interesting idea; I am going to experiment
with it to see where it leads us.
My only possible obj
eal implementation, not just
(reverse stencils).
But unfortunately, I do not understand what you mean by space-lines.
Could you explain in a little more detail?
Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/041
Quoting Neil Puttock :
If you do this, you'll have to change the \score command to a
markup-list command, since a markup command can only return a single
stencil
Well, you just described all the problems this leads to; so why not
relax the rule of markup command returning a single stencil?
Neil's recent modification to
(define-builtin-markup-command (score ...) ...), in
scm/define-markup-commands.scm, fixes the bug where only the first system was
printed, and now we can have multi-line embedded scores, by vertically stacking
the stencils instead of just selecting the first one.
> Maybe all that's needed is a simple
> ability to change the default?
I don't see how that's possible, bearing in mind that the font-tree
cannot be changed once created (it's locked to a specific font-scale).
I meant, changing the global default. So the font-tree gets created
with the wante
]
This looks like a complex workaround.
Maybe all that's needed is a simple ability to change the default?
Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/0419
__
riable now causes this. (I do it by measuring
the distances in the final PDF and comparing them to what the estimator
feeds into the page breaker -- this is how I narrowed down the padding
issue and hopefully this debugging strategy will help with this other
case too).
Boris Shingarov
Work o
Quoting Joe Neeman :
> > Thanks for finding this. next-space is deprecated, so this is a bug.
> What's the correct fix then? Remove the whole mention of next-space in
> the Page Spacer altogether?
Yes. I already made a patch for this, so don't worry about it.
Is there a public discussion pl
When typesetting a large volume of markuplines, the Page Spacer gets
confused by the setting of next-space (1.0 by default). It does
take it into account when calculating the forces, but ignores it when
actually placing the lines on the page. This leads to horrible layout.
For example, if line he
67 matches
Mail list logo
