Re: developer IRC or skype chat

2011-06-07 Thread Boris Shingarov

On 11-06-07 03:28 PM, Graham Percival wrote:

Anybody interested in setting up a weekly chat?

I'd be in, although 19:00UTC on a weekday does not really work for me.


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


Re: Coredump and orphan avoidance code.

2011-02-27 Thread Boris Shingarov

Hi Han-Wen,

Thank you for pointing out this defect.
I have created patch 4236027 to address it:
http://codereview.appspot.com/4236047

To answer your question, what the "if" was supposed to be doing: the 
idea was to guard against the situation where there the whole paragraph 
consists of only one line, because a one-line paragraph is allowed to be 
orphaned.  But what I was not seeing, was that the increment-statement 
of the "for" had already advanced "list" to point to EOL by the time we 
reached that "if".  Quite embarrassing actually.


Boris

On 11-02-22 09:33 AM, Han-Wen Nienhuys wrote:

Hi Boris,

I was looking at why

   \markuplines{}

is dumping core, and came across code committed in

commit 4878fcdb04b335041f1440c8d31b0b4b80ecaea9
Author: Boris Shingarov

   Prob *ps;
   SCM list;
   for (list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
 ...
if (list == texts)
{


complaints:

1. this code leaves ps and list uninitialized. Always initialize *all*
local variables.

2. the if never fires, unless tests==SCM_EOL in the first place

3. Given that the if never fires, do we have a regression test that
covers this code,  and are you sure this actually does something
useful?

Can you please fix this, both the esthetics and the functionality; it
is a release blocking problem.




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


Re: markup to string function?

2011-01-27 Thread Boris Shingarov

On 11-01-26 10:32 AM, Reinhold Kainhofer wrote:

I need a function that extracts only the text (in this
case "Title of the piece").
Many times, I also find myself in need of such function -- it would be 
absolutely awesome to have one.  I have never gotten around to actually 
implementing one; but maybe now is the time.  Maybe attach an 
object-property to the markup, called 'text, and then in 
interpret-markup-list, concatenate them?



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


Re: critical issues

2011-01-23 Thread Boris Shingarov

On 11-01-01 03:24 AM, Graham Percival wrote:

or an
art history / research grant.  I think the latter is more
likely... for example, if somebody got a grant to typeset 17th
century Norweigan folk songs, and decided to use lilypond, and
spent x% of the grant towards "improving community-oriented tools
for folk music archival", etc.

This is exactly what we have been doing here for a while.  In
act, it absolutely amazes me how closely you are describing our
project.  Only 100 years off (16th century instead of 17th),
and only a few hundred kilometers off.

But as I was trying to explain last summer, there are some problems.

The Lilypond project has a very specific set of objectives.  There
is a defined set of procedures, a roadmap, a set of criteria of
what is acceptable to go into the codebase, etc.

The music history research project, has its own set of objectives.
And its own set of rules.  And procedures.  And criteria of what
is acceptable.  When these rules contradict Lilypond rules, I
follow the history research project's rules, not the Lilypond
project's rules, because it is the music history research project
that pays me.  How contradictory are these rules, and how big is
the problem?

Well on one hand, none of today's Critical Issues in Lilypond,
are on the list of priorities for our project.  So even if we had
20 full-time developers, it wouldn't help with releasing the next
stable version.

On the other hand, we have implemented some major new
functionality.  Seamless markup-to-embedded-score integration,
automatic endnotes, merging and visual indication of used sources,
and a lot of other things.  Can it be contributed back?  Hardly
in its current form.  It causes a ton of regressions: basically,
it does not work on anything but Gregorian plainchant.  It will
immediately crash on any piano music or orchestral music.  Will
I fix it?  Not unless someone pays me to, and I know the music
historians will not, because they don't care.  What they (and
your Norwegian friends with their 17th century songs) care about,
is whether or not it is possible to typeset Norwegian lyrics.
Which it isn't -- and it's not even Lilypond's fault: SRFI-13
in Guile does not work with Unicode.

So we have all this work done, but it would be an even bigger
effort to merge it back.  Who will do it?  In the current
situation, I don't know.

However, I am making aggressive steps to change this.  As we
attract more attention from serious organizations, we get into
position to bring forward some conditions for the next project.
Namely, it will become imperative that all contributions get
merged back into the community codebase.  It still does not
mean helping with things like releasing the next stable version
of Lilypond, or similarly, with any part of Lilypond agenda;
although I am not sure if it is a bad thing -- if we want to
transition from being "a volunteer project with limited
resources" to "professional open-source", we will need to face
the fact that there are things which customers are willing to
pay for, and things which no-one finds important enough to
either work on themselves or pay for.

But first we will have to be successful to engage in the new
project.  It is still unclear whether it will happen or not.
I will keep you posted.

Boris



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


Re: Black mensural notation

2011-01-23 Thread Boris Shingarov
This looks like Issue 1098.  That one was closed due to lack of 
reproducible scenario: my scores, too, were crashing Lilypond after 
growing above a certain size, but just like in your case, I can not 
reproduce it with a simple \repeat.


On 11-01-16 12:57 PM, Benkő Pál wrote:

following up myself:

[ after complaining about my large scores ]


This seems to work (at least, the regtests are OK and it doesn't
appear to break the interaction between page-count and
systems-per-page):

[...]

I don't know why, though. :)

it works for me in the sense that there's no memory problem,
but doesn't work in the sense that now I get an overflow message.

those larger scores mean about 30 pages, chunked into 14 \score's.
when I comment them out one by one, there's a stage (at about 10
\score's over 27 pages) when compilation with the official version
achieves similar results: gets through without swapping but with
overflow messages.  when compiling, about 30 seconds are needed to
reach the "Fitting music on 26 or 27 pages..." message, then for
3 more minutes nothing happens (even memory usage is at the same
level (minus a slight increase from 864m to 906mat half time)),
then it's over in about 10 seconds.  adding one more score induces
immediate swapping in the "Fitting music..." stage - I've killed
compilation at 44 seconds after eating 3600m.
after applying your patch the breaks are different, the overall
result is of about the same quality, but the middle section takes
3 seconds instead of minutes.

unfortunately I couldn't reproduce this behaviour with a file
with \repeat unfold music copy-pasted into 20 \score's.  I'll
try to understand what goes on, but am not too confident.

if needed, I can post my .ly files.

p

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





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


Re: Installing ddd on LilyBuntu

2010-12-12 Thread Boris Shingarov

On 10-12-12 01:13 PM, Phil Holmes wrote:
I thought it'd be interesting to install the ddd graphical debugger on 
my LilyBuntu instance.  I downloaded it OK, but when I run ./configure 
I get:


"configure: error: The X toolkit library '-lXt' could not be found."


You are missing the libxt-dev package.

But, why do you want to build DDD yourself?  If you simply want to use 
it to debug LilyPond, you can just install it from the repository.  A 
lot easier, and will save you a lot of headache in the future.


Also, is there a particular reason to prefer DDD for C++ debugging?  I 
find Eclipse CDT a lot better in any thinkable respect.  (But then 
again, I am biased, being one of the founders of the Eclipse project).



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


Re: Simplification of live-elements-list, why not?

2010-11-16 Thread Boris Shingarov

 On 10-11-16 05:37 PM, Neil Puttock wrote:


I'm not sure what I'm guilty of here; in the absence of an exported
function which turns grob-arrays into lists (which I did contemplate
adding at the time), the code I added seems unobjectionable.


That's it: you are basically saying "it's perfect except there is a 
hugely better way" :-)





http://codereview.appspot.com/3104044/


Looks perfect to me.



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


Re: Simplification of live-elements-list, why not?

2010-11-14 Thread Boris Shingarov

 On 10-11-14 11:59 PM, Joe Neeman wrote:


Any specific reason why not just filter on the is-live? predicate?



Doesn't filter just work on plain scheme lists? elements is a 
grob-array object. Of course, if filter doesn't work on such objects 
it might be better to write a version of filter rather than 
replicating it many times.


filter works on things that understand car and cdr; which elements 
clearly doesn't, because it's just a "boxing" wrapper around 
Grob_array*.  What I am doing is go to a list first, and then filtering:


(define (live-elements-list me)
  (filter grob::is-live? (grob-array->list (ly:grob-object me 'elements

where grob-array->list is a function which I just made.

The reason I am asking, is because even after spending 10 minutes 
looking at the procedural-style code in the current live-elements-list, 
I am still not sure what the answer is to the question, "what does this 
function do?"  Does it just filter the elements according to 
grob::is-live??  Or does it do something more / less / different?  Quite 
seriously, it's just hard to be sure.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Simplification of live-elements-list, why not?

2010-11-14 Thread Boris Shingarov
 In scm/output-lib.scm, the (internally used) function 
live-elements-list  is defined like this:


  (define (live-elements-list me)
(let* ((elements (ly:grob-object me 'elements))
   (elts-length (ly:grob-array-length elements))
   (live-elements '()))

  (let get-live ((len elts-length))
(if (> len 0)
(let ((elt (ly:grob-array-ref elements (1- len

  (if (grob::is-live? elt)
  (set! live-elements (cons elt live-elements)))
  (get-live (1- len)
  live-elements))

Any specific reason why not just filter on the is-live? predicate?

Also, is there a real difference between grob::is-live? and ly:is-live? 
predicates?  (I would be inclined to get rid of grob::is-live? version...)


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


Re: Lyrics break estimation of vertical spacing

2010-11-14 Thread Boris Shingarov



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: we are working to secure a very large Lilypond-based 
contract, for a major series of critical editions by a major publisher 
(I'm not allowed to divulge any details yet including who the publisher 
is, but I am sure everyone on this list is familiar with the name).  IF 
we are successful, it will mean a radical breakthrough in acceptance for 
Lilypond.  Some time ago, I was talking about how I wanted to transform 
Lilypond from "a volunteer project with limited resources" (Graham's 
definition), into a professional open-source project where at least some 
of the core people can afford to spend non-trivial amounts of time on 
their passion.  I'll come back as soon as I have something to announce 
(either good or bad).


Boris


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


Re: vertical spacing: Rename dimensions. (issue2505041)

2010-10-17 Thread Boris Shingarov

 But, it breaks all my scores!  Those which use the old names, I mean.

On 10-10-17 01:20 PM, percival.music...@gmail.com wrote:

LGTM, and compiles cleanly from scratch.

http://codereview.appspot.com/2505041/



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


Re: scheme night-mare...

2010-07-11 Thread Boris Shingarov

On 07/11/2010 07:22 PM, Arno Waschk wrote:
Thanks again, that wokrs at least for some displaying, buit still i 
need that handy conversion from this type of scheme list into 
something i can deal with with c.

Please!!!


No, no, the main question is, what are you going to do with that 
"something"?  Ok, the keys are probably Scheme strings, so you can 
transform them into UTF byte-arrays which you can then feed into 
functions like "printf".  But in Scheme, you frequently work with lists 
of things (lists themselves, or atoms) -- this is what a "data 
structure" looks like.  So when you say "something i can DEAL with with 
c", what exactly is this DEALing you want to do?  And with which 
objects?  some of them are Scheme wrappers around C structs.  For those, 
there is smob/unsmob.  But for true Scheme data structures, you really 
want to deal with them using Scheme code -- that is, using scm_call_X(), 
as Carl already suggested.


Boris


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


Re: scheme night-mare...

2010-07-11 Thread Boris Shingarov

On 07/11/2010 06:47 PM, Arno Waschk wrote:
okay, what are arg1 and arg2, and what is the type of result beyond 
being called "SCM"?


An ID for a Scheme entity.  This is a fundamental concept in languages 
such as Scheme, Smalltalk, Self of Java.  The value of the SCM itself is 
completely opaque to the client of the VM.  It can be an index into a 
table, or it can be a direct address.  The entity that it refers to, can 
in turn be any Scheme object: it can be a pair, or an atom, or the 
entity may even be immediately encoded in the SCM itself (for example, 
in Guile, #f is encoded in a special SCM).


If you are familiar with JNI, then you can think of SCM as something 
similar to "jobject".

In Smalltalk, the equivalent concept is "OOP".

If you want to understand the communication between the Scheme and C++ 
code, the best reading explaining the underlying concepts are books on 
implementation of functional programming languages.  But any VM book 
will do just as well (I started from Goldberg&Robson's Smalltalk Blue 
Book back in 1994; Simon Jones is more directly applicable to Scheme).


Boris


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


Re: Vertical spacing regression !?

2010-06-30 Thread Boris Shingarov

On 06/30/2010 01:04 AM, David Kastrup wrote:



until after line-breaking. Also, the vertical collision avoidance means
that in { c1^"long long markup" c1^"long long markup" }, we cannot
calculate the height of the second bar without considering the first bar
too (and the answer will change if they are on different lines).
 

Maybe I am dull, but we need the line heights (or skyline) for a given
line breakpoint sequence, and a given line breakpoint sequence has a
given skyline for each line.
   
Correct.  And there is O(2^N) breakpoint sequences for N possible 
breakpoint places (roughly, for N bars); so we need O(2^N) 
heights/skylines and page breakings.  The dynamic programming algorithm 
deals with this complexity, but even though there are less than O(2^N) 
actual configurations to calculate a demerit score for, it is still 
prohibitively expensive to perform a full layout every time we need a 
demerit score.



Maybe the problem can be alleviated by not associating a fixed line
height/skyline with each bar, but something that is dependent on the
current breakpoint sequence being considered.
   
Not sure what you mean.  We do not and can not have a fixed line height 
/ skyline for each bar -- as Joe just explained.  For example, consider 
music in the G clef; if a particular bar comes after a line break, it 
will have a clef, making the bar much taller.  So I am not sure what you 
have in mind here... something else that I do not see?


Originally, the skyline was approximated by its bounding rectangle.  In 
other words, there was only one measurement: the "line height".  About a 
year ago, to address the problem with G clefs, Joe added the distinction 
between "begin-" and "rest-of-line", for inter-staff, intra-system 
space.  (So instead of one point we have two).  This worked reasonably 
well for music with many staves per system; but for music on one staff 
(e.g. instrument parts, or monody) this does no good, because all the 
space is inter-system.  So about two months ago I introduced the 
"begin/rest" distinction for inter-system space (i.e. for computing 
pure-height of a whole system).  This still left some unaddressed things 
like 1062, which is what today's discussion is about.


Boris


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


Re: Vertical spacing regression !?

2010-06-28 Thread Boris Shingarov

On 06/27/2010 01:25 PM, Joe Neeman wrote:

On Sun, 2010-06-27 at 06:56 -0400, Boris Shingarov wrote:

> This was discussed on this list only a few weeks ago.  I think we 
are on

> our way to get rid of global page*line breaking.

Although I am happy to have an option to do full line-breaking before
page-breaking, I am very much against getting rid of the line and
page-breaking interaction. For example, if we did that then we would
have to scrap the new vertical layout since it relies on being able to
stretch the systems after the pages are determined. And while I have a
personal bias against scrapping the vertical layout (since I wrote it),
I do think that it is a big improvement over the previous layout
algorithm and I have heard comments to that effect on the lists too.
Also, the page-turn-breaker can't function without some interaction
between line- and page-breaking.
I understand the bad effects of divorcing line- from page-breaking.  
Another one (of those which I personally care about) is that it will 
negate the window/orphan handling feature I added.  At least to my 
users, this is important.  And yes, I do agree that the new layout 
algorithm *is* a big improvement over the previous one.


But what do we do about the height estimation problems?  No matter how 
important the positive effects of line/page-breaking interaction are, a 
score with staves cut at the bottom, is unusable.  And a score with the 
opposite problem, is equally unusable.  Can we realistically hope to fix 
enough bugs so that real publications will look usable?  I don't know.  
I started working on the estimations because the user's book suffered 
the problem.  I fixed five, and pulled your fixes for a few.  And yet 
the book is still suffering the same problem.  I know what causes it 
*now*, but I do not know if this is going to be the last one *for this 
book*, and I am now facing problems of customer value when talking about 
fixing height estimation bugs.


So what are we going to do, keep fixing these bugs, under the theory 
that there is only finite number of them?  One thing that makes me 
nervous is that a lot of the time the fixes involve increase of 
computational complexity.  We are moving from simple height estimation 
to more and more complex height estimation; can it be that as we 
approach being more and more correct in our estimation, the complexity 
also approaches that of full layout?



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


Re: Vertical spacing regression !?

2010-06-27 Thread Boris Shingarov

Hi Arno,

Here are some design remarks about what I understood from my work on the 
breaker.  Hopefully a sum of a few [dozen?] of mails like this will 
together constitute something to transform into a chapter in the CG...



Thanks, I've reverted the patch in the meantime. However, the
information that you see in annotate-spacing is actually computed after
line-breaking,


ok, so why can't it then be taken into account for page-breaking?
The problem is that page-breaking does not come *after* page-breaking.  
Well, conceptually, it sort of does.  But the optimization of breaking 
is global over the product space of all line breaking possibilities by 
all page breaking possibilities.  It is done in the hope to get more 
optimal breaks.   The downside is that we are forced to use "height 
estimations" instead of real heights of things; otherwise we would need 
to do page layout for every possible break configuration, which would be 
prohibitively expensive.


This was discussed on this list only a few weeks ago.  I think we are on 
our way to get rid of global page*line breaking.  Height estimation is 
just too inaccurate, so you either have music running off the page at 
the bottom, or (no less ugly) empty space.  We did fix a bunch of height 
estimation issues, but I do not know how many more are left.  This one 
we are discussing right now, is another example of problem caused by 
height estimation.


Since it more than doubles the computation time (often by far) there 
must be something redundant, no?
No, because the height used in page breaking, is not the actual height; 
it is just an estimate (often wrong).  This is what Joe means when he 
says, "...and they aren't actually correct to begin with".


Boris


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


Re: Presentation: "Publisher-grade LilyPond" in Ottawa

2010-06-15 Thread Boris Shingarov

On 06/09/2010 10:52 AM, David Kastrup wrote:

Uh, am I by now in everybody's killfile


I do not know why you keep saying these things, but to avoid any 
misunderstanding I must publicly state that David is in the top 
half-dozen on *my* list of most respected LilyPond people.


On 06/13/2010 09:22 AM, David Kastrup wrote:


So if of three examples you give, one is in reference to a posting of
mine (and I don't agree with the sentiment of it, but that's a different
issue), and two are of postings of mine, it would appear that all
Lilypond needs for becoming more developer-friendly would be to get rid
of me.
   

David, if what I said made you feel bad, I sincerely apologize.

Let me try to clarify what I meant by those quotes:
Interestingly, if we mentally take away those postings for a moment, all 
we then have left is no other help.  So, those posts are the only real 
attempt at an analysis of the problem and possible solutions.  So 
actually, they were the best constructive answer.  But that's exactly 
the problem I am describing: a major critical-edition project asked for 
a couple of features, offering non-trivial rewards for them, and the 
best answer was a (very good) technical analysis concluding with an 
explanation why these features are unworkable.  The request, with the 
bounty offered, did not even make it into the bug-tracker.


Neil Puttock  writes:


"Your post is absolutely unnecessary"
http://www.mail-archive.com/lilypond-u...@gnu.org/msg52334.html
 

That comment wasn't directed at Jiříi; it was part of a reply to David
Kastrup.
   


I put that link to Jiri's reply, instead of to the original Nicolas' 
post, for a reason.
The post has created the impression for the end-user (willing to pay for 
development) that it was directed at him; this is proven by the reply.



But if you actually look at the _original_ postings from which those
quotes from me were pulled, you'll notice that the quotes have been
rather carefully pruned in order to construct something unconstructive
that has not been there in the original posting.
   


The message I tried to construct, is this: the user's requests did not 
result in solutions which would help the publication of the book.  The 
user was even under the impression that he was told that his posts were 
completely unnecessary.  Even though your original postings do contain a 
rather excellent technical analysis of many sides of the problem.


If you think this message is "unconstructive" and do not agree with the 
original postings, tell me how.


On 06/13/2010 10:55 AM, Carl Sorensen wrote:

Where are the thousands of Euros bounties for the LaTeX-based solution?  I'm
not aware of *any* thousands of Euros bounties for anything on LilyPond.
This is a serious question, not a rhetorical question, by the way.  I have
looked at the issues with Bounty tags, and the only one I can find that
seems to be relevant to this discussion is "support for footnotes and/or
endnotes".  That issue makes no mention of a LaTeX-based solution.
   
On the mailing list, and when that didn't help, even around a bunch of 
music-related forums.  There were several requests with such bounties.  
As you just mentioned, none of them even got into the tracker.


Boris


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


Re: Outstanding patches

2010-06-15 Thread Boris Shingarov

Hi Joe,


Could you send me a list of the unreviewed patches that you have on
rietveld? I should have time in the next week or so to review them.
   


This issue is not so much the patches being "unreviewed" but rather 
"sitting stuck missing an ingredient like a test case".  And this is 
partly a practical and partly a philosophical issue for us here: as I am 
trying very hard to explain (in the presentation and many posts on the 
lists), *my* focus is not advancing LilyPond along its main direction 
(there already is an excellent team doing that), but taking it to other, 
orthogonal, dimensions -- such as making it useful to a musicologist 
preparing a major critical edition.  In this work, we have our own 
limitations which make it very difficult to do proper disciplined 
software development.  Right now, when presented with a technical 
requirement, I have to take the shortest path to satisfy the requirement 
*for this book only*.  I have very limited time to care if the solution 
breaks all other books.  Not that I have a low code standard, but many 
times I have to consciously go against my own standards.  This exercise 
going against developer values is deliberate.  It has to do with being 
customer-centric vs software-centric.


If the solution happens to be close enough to being useful for everybody 
else (this is what I earlier called "10% extra work to get the patch 
accepted"), I submit the patch for review.  But sometimes, "the shortest 
way" differs from the "proper" say by 500%; these are the patches I 
classify within the "future work" category.


This is going to change.  Hopefully, with the success of the work on the 
first volume of the book, will be able to launch a project supporting 
proper mainline LilyPond development.


Now, on to the actual list.  Off the top of my head, there are three.

"Page-spacer gets confused", sits wanting a test case:
http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/17443/focus=18865
This issue has a duplicate, "Vertical spacing: over-estimation of 
markups height", recently reported by Nicolas:

http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/18831/focus=18857

"Pure-height of stems", sits wanting a test case:
http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/18449/focus=18450

Homogeneous treatment of markup and markup-list things, discussed back 
in February and again recently:

http://lists.gnu.org/archive/html/lilypond-devel/2010-02/msg00268.html
http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/28717/focus=28813
http://codereview.appspot.com/207105
With this one, the situations is somewhat more complex because I can see 
the reasons for Nicolas' assessment that the patch makes one markup 
command behave differently from all other markup commands.  I am not yet 
sure if this is ok or bad.  The whole idea of the patch is that a markup 
command can return either a stencil or a list of stencils, and the code 
consuming the result, automatically decides on how to deal with what 
came from the command.  If we take this standpoint, then the patch only 
needs those minor formatting fixes that Carl pointed out.  But one could 
also take Nicolas' standpoint.



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


Re: Presentation: "Publisher-grade LilyPond" in Ottawa

2010-06-12 Thread Boris Shingarov

Hi Graham and all Lilyponders,

I was quite astonished to hear that my slides were understood to mean 
anything pessimistic or negative.  If they give people this impression, 
then it is a defect of the slides which I will fix.


But right now, let me address some of the apparent misunderstandings.


Are you seriously going to submit a paper to CMJ saying "a volunteer
open-source project has limited resources for fixing bugs" ???
   

This is not what we are saying in our presentation and/or paper.
What we are saying is: "We attempted a publication of a major critical 
edition through a major publishing house, using software from a 
volunteer open-source project with limited resources.  We first hoped 
that this software would be immediately (or almost immediately) suitable 
for critical-edition work.  We found issues blocking this work.  These 
issues are orthogonal to the main direction of the LilyPond project.  We 
fixed them, making the book possible.  Future work includes making these 
solutions useful for the wide LilyPond audience, not just for the 
immediate needs of this particular book".



Oh, and I hope that this "paper to appear" includes an excellent
reason why you didn't use lilypond-book and LaTeX, which unlike
lilypond itself is*designed*  to mix music and text.
   

Two reasons, really.

Reason one, we did investigate that route.  Lilypond-book and LaTeX do 
not achieve the kind of music/text integration that the editor 
demanded.  Another issue was integrating with their existing database of 
variant readings.  And for me, there was the obstacle that it was not 
what the end user was asked for.


Reason two, the cry for help was heard all over the mailing list 
starting many, many months ago.  Anyone with a LaTeX-based solution 
yet?  Anyone even *suggesting* a LaTeX-based solution yet?  After a year 
and non-trivial (thousands of Euros) bounties offered?


I agree that the presentation has a disproportionately large first 
(introductory) part, which makes it seem like a "presentation about 
LilyPond", while it is really the second part which is the essence.  
There is a background why I chose to extend this first part to be 
somewhat detailed.  Before the presentation at OCLUG, there were two 
"micro-presentations" I did in a more informal setting.  They ended in 
somewhat curious Q&A discussions.


The first question -- asked by a guy who is well-known to everyone in 
the digital typography and content engineering field through dozens of 
papers and monographs -- he couldn't believe that today, in 2010, when 
everything programmable into a computer had already been programmed, 
today there are still books that can not be printed using already 
written software.  He demanded examples of problems (in music 
typesetting) which still waited for their programming solutions.  So 45 
minutes were devoted to these examples.


At another micro-presentation, there was another question.  "I thought 
music typography was completely solved by Unicode?  That is, all you 
need to publish any score, is LaTeX and a font with all the music 
symbols in it?"  So, another 15 minutes to explain why LaTeX+Feta != 
music engraving system.


So this is the kind of questions typically asked by those in the 
audience who care at all.  This is why I felt an extended introduction 
to LilyPond was needed -- although the real subject of the presentation 
is mostly orthogonal to LilyPond per se.



his slides would discourage any potential
developers from joining
If there is a person who gets this impression from the slides, then the 
slides are definitely defective and need fixing ASAP.  I am not sure if 
the presentation had the same defect or it's just the slides (there 
certainly was a lot more explaining of the reasons and the background), 
but they are most definitely not supposed to convey any negative ideas.


"The community showed no interest in addressing these issues", well I am 
certainly not saying it's the community's *fault* -- the point is that 
there are other dimensions, which are of concern to [at least one] top 
publisher, in connection with [at least one] type of book, and which are 
orthogonal to the dimension of the direction of work of the LilyPond 
project.  After all, none of these issues originated from me; they 
originated from the musicologist doing the chant research, and the 
editor of the book -- before I even started looking at LilyPond -- and 
were rejected as not even being valid LilyPond problems.  The typical 
answers were,


"I think that you'll be better served by others"
http://www.mail-archive.com/lilypond-u...@gnu.org/msg52031.html

"Your post is absolutely unnecessary"
http://www.mail-archive.com/lilypond-u...@gnu.org/msg52334.html

"I recommend magic"
http://www.mail-archive.com/lilypond-u...@gnu.org/msg52026.html

Does this represent a problem enough to "discourage" people?  I think it 
does not, for two reasons.  First, people are smart to take such things 
with a grain 

Re: before-title-spacing mess up with automatic page breaks

2010-06-09 Thread Boris Shingarov

Thanks Xavier,

I opened Bug 1112.  I have been fixing bugs and implementing new 
features in the area of page breaking for some past while, so in all 
probability I'll end up being the one fixing this, too -- because it is 
the kind of bug which is likely to affect our book here, too.




BTW should I send this to bug-lilypond, at least to keep a track of
this issue


Since both Joe and I are subscribed to both -bug and -devel, and to keep 
track of issues there is the tracker which now contains the bug anyway, 
I'd say re-posting in -bug would not be very useful.  But for the 
future, yes, -bug is the more natural place for reports like yours.


Boris


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


Re: [PATCH] Initialize interval in grob_stencil_extent().

2010-05-23 Thread Boris Shingarov



There is a chance of returning garbage values from grob_stencil_extent()
due to this uninitialized variable issue.
   

No there is not: because this is C++, not C.
The existing code is guaranteed to initialize e to the empty interval 
(i.e., the special interval [+inf, -inf]); your code initializes it to a 
different interval -- the single-point interval [0,0] -- which is not a 
difference in "uninitialized garbage" but a question of semantics.



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


Re: GUB and mipsel architecture

2010-05-17 Thread Boris Shingarov



I'm wondering if it is worth having a mipsel package on lilypond.org
(when 2.14 comes out, maybe).
I'd be happy to do it, if I can. A chance to help and learn something
new.
 

This should be discussed on -devel rather than -user.

I would be happy to build+include mipsel packages, as long as
somebody else modifies GUB to handle it, and they fix any breakage
in those packages.  If they stop GUB from compiling a release, I
would simply comment out the mipsel compilation and release the
rest.

However, cross-compiling is a fairly involved process and requires
a great deal of technical knowledge.  Don't expect much help,
because very few people have any experience with it.
   


The main question is, does anyone really want it done.

I did a lot of mipsel development in the past, so cross-compilation is 
not a problem, but it all comes to user value.  A few months ago, I had 
a pressing request, from a real-life user for whom I do custom features 
in Lilypond, to produce Win32 builds, and I started looking at digging 
inside GUB; but when I presented to them an estimate of how many days it 
would take to have a functional GUB platform, it became clear that my 
time would be much wiser spent on actual Lilypond development (score 
layout functionality), rather than GUB, and that using Linux instead of 
Windows was not *that* unsurmountable a problem to justify potentially 
up to two weeks lost to GUB work.


So if one is about to do something with a real purpose (mipsel Lilypond 
appliance?? completeness of a distro??) I would expect many people with 
the right skills to be able to do it; on the other hand, as an academic 
exercise I personally would not find it the most attractive to jump on 
-- there are many other interesting problems to solve.


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


Re: Aligning single systems?

2010-05-08 Thread Boris Shingarov

On Fri, 07 May 2010 21:53:54  0200, David Kastrup  wrote:

If we had something like that, one would not need to meddle with

 > paddings and the resulting spurious spacings.

Like in the old joke of a composition student being given advice to
take the easy route and just write his professor's Praeludien
backwards: "I already tried, Songs by Schubert come out".
 
I already tried a number of ways to improve the vertical alignment of
embedded scores, including \vcenter.  The resulting alignment is good,
but having good alignment does NOT solve the spurious spacing.  The
problem of spurious spacing is that the shape of the staff is
approximated by its bounding box.  In the case of text, such
approximations work ok, because the optical "density distribution" is
reasonably close to rectangular.  But for music, it is far from
rectangular, we have things sticking out of the staff, like the tip of
the G clef.  So visually, the white space above a staff begins from
the 5th line, but the machine starts measuring it from the highest
point of the clef.
 
 
 
 
 
 



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


Re: Aligning single systems?

2010-05-07 Thread Boris Shingarov

Hi David,


for theoretical work it often is necessary to write several short

 > systems in one line, interspersed with text.
 
This is exactly what we are doing.

 > I don't manage to have
 > a) new systems continue aligned to the previous system in a line, like
 > when doing
 > \line { \score { ... \layout {} } some text \score { ... \layout {} } }
 
I am not sure I understand what the problem is.
Do you mean having several embedded scores on one line?  Like this:
\markuplines {
  \justified-lines {
    some text
    \score { ... \layout {} }
    more text
    \score { ... \layout {} }
  }
}
What is the functionality missing from this?
 

b) to have interspersed text appear at useful height with relation to

 > the surrounding score.
 
We were able to obtain nice looking results via a combination of
adjustments to baseline-skip, minimum-Y-extent, staff-space, and other
similar standard settings, I can't remember off the top of my head what
they were, but the idea is, achieving it did not require any custom
programming work, nor even Scheme scripting.  What I am struggling
with right now, is the crappy vertical spacing of lines that results. 
Because the "padding" / "spacing" specifications are only specific to
text lines, and embedded scores *are* text lines to the page layout
algorithm, my text-only lines are spaced visually much more tightly
than lines containing embedded scores.  I think the G clef is (at
least partly) to blame.

 > Would it be possible to have some Staff property, say, baseline-height
 > that specifies a Staff line to be aligned with the baseline of
 > surrounding constructs?

Hmm... so it would be relative to what, the bottom of the bounding
rectangle?  Or I think more usefully, to the middle staff line?  so
one could say: "the middle lines of all embedded staves are always 1mm
above the baseline of the text".  That would be way cool, and I don't
see why it would be too hard to implement.
 
Boris
 
 
 
 
 
 
 



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


Re: markup-command and markup-command-list signatures

2010-05-03 Thread Boris Shingarov

On Mon, 03 May 2010 09:02:55  0200, David Kastrup  wrote:
"Boris Shingarov"  writes:

> Markup functions being able to return a list of stencils.

 >
 > Markup lists don't do the trick here?
 
No; if you look at patch 207105, you'll see what I mean.
 

I don't see that you stand a chance with the standard processes here.

[...]
 > Basically you'll be on your own going against the tide until you are
 > finished.  The work flows here are designed to achieve code quality by
 > making it harder for a would-be contributor to get sub-par code through,
 > not by making others participate with the work.

I guess even that assessment is overly optimistic.
 
The real problem here is not of process, but of fundamental
interests.  I am scratching *my* itch, which is, make
top-publication-grade work possible with Lilypond.  Lilypond did not
reach this grade before.  So this work is beneficial to the Lilypond
community in two ways: proving we can go on that territory, as well as
purely technical contributions.  Now, with technical contributions
that are easy enough to integrate back upstream, ok I can spend the
extra 30% effort to integrate; but 500% does not seem justifiable and
then we take the GPL as the guideline: here is the new code, enjoy
doing whatever you please with it.  But I am open to any suggestion
how to make it more useful to the community.
 
Boris
 
 
 
 
 
 



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


Re: markup-command and markup-command-list signatures

2010-05-02 Thread Boris Shingarov

I am working on a system of markups which allows to specify more
flexible formatting rules.  WE are using it for things like multi-line
embedded scores, mixing them with markup lines, rules about what things
/ combinations of things should not start / end a line, also there are
rules like "no line break between certain words and beginning ebmbedded
score", that kind of formatting rules.  I had described some of these
ideas in my earlier posts on this list.  Markup functions being able
to return a list of stencils.  Much more importantly, markups need to
be aware of what was placed before, and what is to follow, therefore
when processing the markup-list, we need to pass a continuation at each
step, instead of iterating over the list.  This kind of ideas.
 
It even sort of works.  Well, works enough for production use by
non-programmer users.  But still far from being a general Lilypond
improvement.  The other, easier improvements (orphan-avoiding
functionality, page-breaking fixes), are making it fine into the
upstream repo: for those, going from the happy state of having the
user's problem fixed, to the happier state of fixing it for everyone,
is of a reasonable proportion compared to the whole amount of work. 
But with my markup changes, it's much different.  Even the first and
simplest of these changes (patch 207105), to go from the current state
to an actual submittable patch, will take like 2x the time it took to
get it to solve the user's probem.  For the bigger problems, like the
"markup needs to know what's before and what's ahead", or for the
integrated text/embedded-score flow, I don't know, could be up to 5x,
and now we are suddenly looking at problems of user value, and all the
repercussions.  So there is development happening which is important
to users (= enables a serious academic publication through a top-name
publisher), but those contributions can not be used better than just
being thrown away by the community.  I remember reading on the LKML,
kernel guys having somewhat similar problems with vendor patches and
integration with the vanilla tree.  I don't (yet) know how we should
deal with this, just thinking aloud while there is this discussion
about the same area of code...
 

> that is, any number of scheme arguments, then any number of single markup

 > > arguments, then any number of markup-list arguments, even though I don't
 > > know if having several markup list arguments is useful or not
(and if it's
 > > doable).

 



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


Re: news item for new G clef?

2010-04-23 Thread Boris Shingarov

I must have missed something -- I don't understand what you are
discussing.  Are you saying that when a contributor submits a patch,
the patchset should include an update to the CHANGES file?

On Sat, 24 Apr 2010 00:19:33  0100, Graham Percival  wrote:
On Sat, Apr 24, 2010 at 12:29:45AM  0200, Francisco Vila wrote:
 > > 0ce6fe9 introduced a new 1,5 degrees rotated G clef, does this deserve
 > > a news item? I think so.
 >
 > Entries in the Changes are completely up to individual
 > contributors.  As a general rule, I'd say that when in doubt, add
 > an entry.
 >
 > Cheers,
 > - Graham

 
 



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


Re: PATCH: Lyrics break estimation of vertical spacing

2010-04-21 Thread Boris Shingarov

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 Joe yesterday, and I also recall a bunch of
other fixes in this area in the last few months), but we are not only
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.

So much so that I am starting to think that sacrificing the benefit of
linebreaking/pagebreaking integration in the sake of always running
real (non-pure) height, would be the path to having a reasonable layout
for our book.  That is, calculate the line breaks disregarding page
breaking; calculate tallness of all lines; then run the page breaking
algorithm.
 
 
 
 
 
 



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


Re: PATCH: Lyrics break estimation of vertical spacing

2010-04-21 Thread Boris Shingarov



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 particular.
 



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


Re: Can not make install

2010-04-21 Thread Boris Shingarov

The problem is happening with 18.
I believe there is no issue with 17, because the last large bunch of my
work was based off a pull *after* 17, and it has been installing fine;
so the offending change has to be somewhere between 17 and 18; but I'll
go double-check 17.

On Wed, 21 Apr 2010 17:59:43 -0400, Boris Shingarov  wrote:
Must be something else.
 > I upgraded texinfo (and related packages) from 4.11.dfsg.1-4 (which it
 > is in lilybuntu) to 4.13a.dfsg.1-4ubuntu1, it diesn't make a difference.
 > Doing lilypond version dichotomy now.
 >
 > On Wed, 21 Apr 2010 14:00:29 -0700, Patrick McCarty  wrote:
 > On Wed, Apr 21, 2010 at 1:44 PM, Graham Percival
 >   >  wrote:
 >   > > On Wed, Apr 21, 2010 at 04:19:37PM -0400, Boris Shingarov wrote:
 >   > >> I wouldn't even care about this at all -- because I am not
experiencing
 >   > >> this problem on my development machine -- if not the outcry
of my users
 >   > >> who today can not use any of what I wrote in the past weeks.
 >   > >
 >   > > Well, we need somebody who sees those errors to do more
 >   > > investigation.  Does the source for 2.13.18 work?  If not, what
 >   > > about 2.13.17 ?  If not, what about 2.13.16 ?  etc.  If we know
 >   > > what range of commits we need to examine, we have a better chance
 >   > > at finding the problem.
 >   >
 >   > Graham,
 >   >
 >   > FWIW, I just did a clean build, testing `make install' and `make doc'
 >   > too, and I did not run into any build failures.
 >   >
 >   > I have texinfo 4.13a installed on my machine.
 >   >
 >   > Thanks,
 >   > Patrick
 >   >
 >   >
 >
 >
 >
 >
 > ___
 > lilypond-devel mailing list
 > lilypond-devel@gnu.org
 > http://lists.gnu.org/mailman/listinfo/lilypond-devel
 >
 >




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


Re: Can not make install

2010-04-21 Thread Boris Shingarov

Must be something else.
I upgraded texinfo (and related packages) from 4.11.dfsg.1-4 (which it
is in lilybuntu) to 4.13a.dfsg.1-4ubuntu1, it diesn't make a difference.
Doing lilypond version dichotomy now.

On Wed, 21 Apr 2010 14:00:29 -0700, Patrick McCarty  wrote:
On Wed, Apr 21, 2010 at 1:44 PM, Graham Percival
 >  wrote:
 > > On Wed, Apr 21, 2010 at 04:19:37PM -0400, Boris Shingarov wrote:
 > >> I wouldn't even care about this at all -- because I am not experiencing
 > >> this problem on my development machine -- if not the outcry of my users
 > >> who today can not use any of what I wrote in the past weeks.
 > >
 > > Well, we need somebody who sees those errors to do more
 > > investigation.  Does the source for 2.13.18 work?  If not, what
 > > about 2.13.17 ?  If not, what about 2.13.16 ?  etc.  If we know
 > > what range of commits we need to examine, we have a better chance
 > > at finding the problem.
 >
 > Graham,
 >
 > FWIW, I just did a clean build, testing `make install' and `make doc'
 > too, and I did not run into any build failures.
 >
 > I have texinfo 4.13a installed on my machine.
 >
 > Thanks,
 > Patrick
 >
 >




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


Re: Can not make install

2010-04-21 Thread Boris Shingarov

oh, also, "does it occur on make doc, or on make install" ?

 
Maybe that's just a missed dependency.  It occurs on "make install"
after a successful "make all".  The error message is this:
 
# make install
.. // bunch of successful stuff...
..
make[1]: Entering directory `/home/boris/lilypond/Documentation'
cp -p contributor.texi out/contributor.texi
export LILYPOND_DATADIR=
export
PYTHONPATH=/home/boris/lilypond/python/out:../python/auxiliar:/home/boris/lilypond/python/out:./python/auxiliar:
/usr/bin/python /home/boris/lilypond/stepmake/bin/install.py -c -d
/usr/local/share/info
install-info --remove --info-dir=/usr/local/share/info
./out/lilypond-usage.info ;  install-info --remove
--info-dir=/usr/local/share/info ./out/lilypond-changes.info ; 
install-info --remove --info-dir=/usr/local/share/info
./out/lilypond-contributor.info ;  install-info --remove
--info-dir=/usr/local/share/info ./out/lilypond-internals.info ; 
install-info --remove --info-dir=/usr/local/share/info
./out/lilypond-essay.info ;  install-info --remove
--info-dir=/usr/local/share/info ./out/lilypond-learning.info ; 
install-info --remove --info-dir=/usr/local/share/info
./out/lilypond-notation.info ;  install-info --remove
--info-dir=/usr/local/share/info ./out/music-glossary.info ; 
install-info --remove --info-dir=/usr/local/share/info
./out/lilypond-web.info ;  install-info --remove
--info-dir=/usr/local/share/info ./out/lilypond-extending.info ; true
install-info(./out/lilypond-usage.info): no entry for file `lilypond-usage'
install-info(./out/lilypond-changes.info): no entry for file
`lilypond-changes'
install-info(./out/lilypond-contributor.info): no entry for file
`lilypond-contributor'
install-info(./out/lilypond-internals.info): deleting entry `* LilyPond
Internals Reference: (lilypond-internals) ...'
install-info(./out/lilypond-essay.info): no entry for file `lilypond-essay'
install-info(./out/lilypond-learning.info): deleting entry `* LilyPond
Learning Manual: (lilypond-learning) ...'
install-info(./out/lilypond-notation.info): deleting entry `* LilyPond:
(lilypond-notation) ...'
install-info(./out/music-glossary.info): deleting entry `* Music
Glossary: (music-glossary) ...'
install-info(./out/lilypond-web.info): no entry for file `lilypond-web'
install-info(./out/lilypond-extending.info): no entry for file
`lilypond-extending'
install-info --info-dir=/usr/local/share/info ./out/lilypond-web.info

No `START-INFO-DIR-ENTRY' and no `This file documents'.
install-info(./out/lilypond-web.info): unable to determine description
for `dir' entry - giving up
make[1]: *** [local-install-info] Error 1
make[1]: Leaving directory `/home/boris/lilypond/Documentation'
make: *** [install] Error 2
#
 
Now, after that, invoking "make doc" results in building things I am
positive were not required for "install" before.
 

I'm not particularly concerned if "make install"
is broken with old libraries, since only package
managers need to run that.

 
My end users run that.  I don't want to get into that old thread about
"release early" and "cathedral" stuff; but for me, your argument in
that thread was convincing because I see Lilypond as in some sense
similar to Debian, where "stable" means dynosaur bones.  I fix bugs
that my users are saying get in the way of their production work, and
implement and contribute back features that they need to continue their
production work.  I could base this work off the stable 2.12, but are
you willing to look at patches against 2.12's page-breaking code, which
is completely replaced in 2.13?  Therefore, I obviously must do
development against the latest master.  But the direction this
development is driven by my users; in fact, my patches get tested in
the field on production manuscripts before they even get uploaded on
appspot.  If "make install" is broken for users, this whole model of
development breaks down.
 
I wouldn't even care about this at all -- because I am not experiencing
this problem on my development machine -- if not the outcry of my users
who today can not use any of what I wrote in the past weeks.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 



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


Re: Can not make install

2010-04-21 Thread Boris Shingarov

I think this should be marked as Critical, because it affects all
Lilybuntu installations, and Lilybuntu is a supported reference
platform for Lilypond.  If it were happening on some strange "Green
Elephant Linux" distro, I'd say it's small, but this is our own
reference platform that's broken.

On Wed, 21 Apr 2010 15:34:59  0100, Graham Percival  wrote:
On Wed, Apr 21, 2010 at 2:57 AM, Carl Sorensen  wrote:
 > > On 4/20/10 10:50 AM, "Graham Percival"  wrote:
 > >
 > >> On Tue, Apr 20, 2010 at 10:34:37AM  0200, Francisco Vila wrote:
 > >>> Hello. I guess this means I have to upgrade my compiler or something.
 > >>
 > >> If anything, it would be makeinfo, not your compiler.
 >
 > What happens if you use texinfo 4.13a?
 >
 > > After doing  make clean && make && make doc (and with the font stuff
 > > reverted) I get the following:
 > >
 > > /Users/Carl/lilypond/Documentation/out-www//rhythms.texi:1: Prev
reference
 > > to nonexistent node `Pitches' (perhaps incorrect sectioning?).
 >
 > Can't reproduce here -- either of the reports.  I built from scratch
 > (starting from a completely empty build directory).
 >
 > There's no string "nonexistent" in the entire build log.
 >
 > Cheers,
 > - Graham
 >
 >
 > ___
 > lilypond-devel mailing list
 > lilypond-devel@gnu.org
 > http://lists.gnu.org/mailman/listinfo/lilypond-devel
 >
 >




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


Re: Any way to use lilypond as a library? (embeded)

2010-04-07 Thread Boris Shingarov

Hi Alejandro,
 
For what you are doing, you probably want to use libmidi; lilypond is
more like if your program created a tune and needed to render the score
on paper or on the screen.  If your program is in C  , you can use
libmidi directly.  If it is in another language, there are many
wrappers around libmidi available.
 
On Wed, 7 Apr 2010 11:32:42   (UTC), Alejandro Piñeiro  wrote:
I would to ask if there are any way to use parts of lilypond as a library of a
 > different application (use lilypond embeded).
 >
 > Right now I'm using Ubuntu, and there are only available lilypond,
lilypond-data
 > or lilypond-doc packages. There isn't anything similar to lilypond-dev
 >
 > As far as I see lilypond only includes executables.
 >
 > Why I ask that?
 >
 > I'm creating a little application and I would like to create simple
midi files
 > on the fly, but I would like to avoid to enter in midi internals
(avoid to waste
 > my time reinventing the wheel). And lilypond file format is really
easy to use.
 >
 > So my idea is:
 >
 >  * My program creates a tune.
 >  * Create a string with the lilypond description.
 >  * Calls a function, and it creates a external midi file
 >  * My program uses the midi file.
 >
 > Of course, other alternative could be:
 >  * My program creates a tune
 >  * Creates a external lilypond file
 >  * Calls lilypond to parse this string->creates midi file
 >  * Uses the file
 >
 > But, I think that the second one is more slow.
 >
 > Thanks for your attention.
 >
 >
 >
 > ___
 > lilypond-devel mailing list
 > lilypond-devel@gnu.org
 > http://lists.gnu.org/mailman/listinfo/lilypond-devel
 >
 >




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


Re: Critical defects and collisions

2010-03-22 Thread Boris Shingarov

1027 Accepted Critical nobody Lyrics ignore minimum-Y-extent

 
This one, I have a suspicion that it may be related to the "Lyrics
break estimation of vertical spacing" bug I am working on.  If no one
else is looking at 1027, it *might* make sense to treat them together
while I am in that area of code.  But for either/both to happen, I'd
need a little help from Joe, to push me in the right direction re:
understanding the design of the axis group interface.



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


Re: Line breaking, simple-spacer, etc.

2010-02-09 Thread Boris Shingarov

Quoting Joe Neeman :


We create lots of extra grobs (eg. a BarNumber at every bar line) but
most of them are not drawn. See the break-visibility property in
item-interface. 


Thanks Joe, this explanation does help a lot. 
I hope I am not abusing your (and the list's) patience by asking 
another question:


In define-markup-commands.scm, there are references to things like 
wordwrap-internal-markup-list and make-wordwrap-internal-markup-list.  
For example, in the function define-builtin-markup-list-command, there 
is the application (make-wordwrap-internal-markup-list #t args). 
I can not find where these functions are defined.  Grepping the whole 
source tree only yields occurrences where they are applied.  I presume 
there must be some sort of dynamic building of the name and binding it 
to the the body (also there is the question then, how is the body 
constructed)?




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


Line breaking, simple-spacer, etc.

2010-02-04 Thread Boris Shingarov
I am experimenting with some modifications to the line breaking code, and I am 
stuck trying to understand how some of it works.  So far my understanding is 
that Simple_spacer operates on a vector of Grobs, and it is a well-known 
Constrained-QP problem (rods = constraints, springs = quadratic function to 
minimize).  What I don't understand is, if the spacer operates at the level of 
Grobs, which are built at an earlier stage in the pipeline, how are the changes 
necessitated by differences in line breaking, taken into account?  in other 
words, if I take the last measure of a line and place it on the next line, it 
is not just a matter of literally moving that graphic to where the start of the 
next line is, but I also need to draw a clef, key signature, and possibly other 
fundamental things -- but at that stage in the rendering pipeline, is it not 
too late??


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


Re: Avoid orphan/widow lines (issue190102)

2010-01-21 Thread Boris Shingarov

lgtm, modulo some more formatting nitpicking. If you fix the formatting
and mail me the patch, I'll push it. 


Here it is. 
--

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/constrained-breaking.cc
index 2fead24..31d2cf0 100644
--- a/lily/constrained-breaking.cc
+++ b/lily/constrained-breaking.cc
@@ -525,4 +525,8 @@ Line_details::Line_details (Prob *pb, Output_def *paper)
   title_ = to_boolean (pb->get_property ("is-title"));
   compressed_lines_count_ = 1;
   compressed_nontitle_lines_count_ = title_ ? 0 : 1;
+  SCM last_scm  = pb->get_property ("last-markup-line");
+  last_markup_line_  = to_boolean (last_scm);
+  SCM first_scm = pb->get_property ("first-markup-line");
+  first_markup_line_ = to_boolean (first_scm);
 }
diff --git a/lily/include/constrained-breaking.hh b/lily/include/constrained-breaking.hh
index bb8a1d0..f36ab74 100644
--- a/lily/include/constrained-breaking.hh
+++ b/lily/include/constrained-breaking.hh
@@ -52,6 +52,8 @@ struct Line_details {
  class. */
   int compressed_lines_count_;
   int compressed_nontitle_lines_count_;
+  bool last_markup_line_;
+  bool first_markup_line_;
 
   Line_details ()
   {
@@ -71,6 +73,8 @@ struct Line_details {
 title_ = false;
 compressed_lines_count_ = 1;
 compressed_nontitle_lines_count_ = 1;
+last_markup_line_ = false;
+first_markup_line_ = false;
   }
 
   Line_details (Prob *pb, Output_def *paper);
diff --git a/lily/include/page-breaking.hh b/lily/include/page-breaking.hh
index 2e5283d..d497d49 100644
--- a/lily/include/page-breaking.hh
+++ b/lily/include/page-breaking.hh
@@ -127,6 +127,7 @@ public:
   bool too_few_lines (int line_count) const;
   Real min_whitespace_at_top_of_page (Line_details const&) const;
   Real min_whitespace_at_bottom_of_page (Line_details const&) const;
+  int orphan_penalty () const;
 
 protected:
   Paper_book *book_;
@@ -179,6 +180,7 @@ private:
   int max_systems_per_page_;
   int min_systems_per_page_;
   vsize system_count_;
+  int orphan_penalty_;
 
   vector current_configurations_;
   vector current_chunks_;
diff --git a/lily/page-breaking.cc b/lily/page-breaking.cc
index e0a08c0..dc71659 100644
--- a/lily/page-breaking.cc
+++ b/lily/page-breaking.cc
@@ -174,6 +174,7 @@ Page_breaking::Page_breaking (Paper_book *pb, Break_predicate is_break)
   systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("systems-per-page"), 0));
   max_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("max-systems-per-page"), 0));
   min_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("min-systems-per-page"), 0));
+  orphan_penalty_ = robust_scm2int (pb->paper_->c_variable ("orphan-penalty"), 10);
 
   if (systems_per_page_ && (max_systems_per_page_ || min_systems_per_page_))
 {
@@ -1415,3 +1416,9 @@ Page_breaking::min_whitespace_at_bottom_of_page (Line_details const &line) const
   // FIXME: take into account the height of the footer
   return max (0.0, max (padding, min_distance + line.extent_[DOWN]));
 }
+
+int
+Page_breaking::orphan_penalty () const
+{
+  return orphan_penalty_;
+}
diff --git a/lily/page-spacing.cc b/lily/page-spacing.cc
index 8919257..8dbf183 100644
--- a/lily/page-spacing.cc
+++ b/lily/page-spacing.cc
@@ -245,6 +245,18 @@ Page_spacer::calc_subproblem (vsize page, vsize line)
 	penalty += lines_[page_start-1].page_penalty_
 	  + (page % 2 == 0) ? lines_[page_start-1].turn_penalty_ : 0;
 
+	  /* Deal with widow/orphan lines */
+	  /* Last line of paragraph is first line on the new page */
+	  if ((page_start > 0) &&
+	  (page_start < lines_.size ()) &&
+	  (lines_[page_start].last_markup_line_))
+		  penalty += breaker_->orphan_penalty ();
+	  /* First line of paragraph is last line on the previous page */
+	  if ((page_start > 0) &&
+	  (page_start < lines_.size ()) &&
+	  (lines_[page_start-1].first_markup_line_))
+		  penalty += breaker_->orphan_penalty ();
+
 	  demerits += penalty;
 	  if (demerits < cur.demerits_ || page_start == line)
 	{
diff --git a/lily/paper-book.cc b/lily/paper-book.cc
index 79896e6..f1ee2ec 100644
--- a/lily/paper-book.cc
+++ b/lily/paper-book.cc
@@ -516,15 +516,20 @@ Paper_book::get_system_specs ()
   paper_->self_scm (),
   page_properties,
   scm_car (s));
-	  for (SCM list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
+	  Prob *ps;
+	  SCM list;
+	  for (list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
 	{
 	  SCM t = scm_car (list);
 	  // TODO: init props
-	  Prob *ps = make_paper_system (SCM_EOL);
+	  ps = make_paper_system (SCM_EOL);
 	  ps->set_property ("page-break-permission",

Re: Enhancement: Page breaking to avoid widow lines

2010-01-21 Thread Boris Shingarov

Quoting Joe Neeman :


Again, I'd suggest uploading patches to codereview.appspot.com, which
provides nice formatting and makes it easy to have multiple reviewers. 


Ok, I've created Issue 190102 for this. 

One inconvenience that I see with the "upload.py" tool, is that I don't 
see a way to specify the exact target of the diff -- i.e. which files 
to run the diff against, or even make some tweaking to the diff 
contents before submitting them.  This is useful because the working 
copy usually contains other, temporary, changes, that I do not want to 
be submitted.  In this particular case, there is the workaround for the 
incorrect page height estimation, which got its way into the submitted 
patch because upload.py just grabbed all the changes. 


Use to_boolean


Done. 


put this on two lines


Done. 


false instead of 0


Done. 


(2) seems to be pretty important, no? If there is only one line then the
current code will avoid placing it first or last on any page. 


Implemented. 




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


Re: GUB buiding from a local source tree?

2010-01-20 Thread Boris Shingarov

Quoting Graham Percival :


I'm completely serious.  My GUB tree is *filled* with ugly hacks like
this.  It would be nice if they weren't needed, but it'll probably
take 20-50 more hours of work until this is the case. 


Oh, I completely understand this.  And this is the exact reason why I 
am asking questions, because when the code is this rough, there are 
things that are better to just ask, rather than to try to figure out 
"why" -- because we are not dealing with something finished but a 
thought-in-progress. 


If you're frustrated already, then I honestly think you
should give up now, because it will only get worse from now on


I completely realize what kind of complexity we are talking about.  And 
no, I am not at all frustrated.  Not from a technical viewpoint anyway. 
 But for me the whole thing about GUB is driven by the organizational 
side: as a developer, I am completely happy with the Linux development 
platform, and am much more interested in furthering Lilypond rather 
than trying to deploy it on a platform I don't even use.  But then 
there is the end-users who want to see it on Windows, but then again 
they want to see progress in Lilypond development, and the prospect of 
losing weeks to porting to Windows, makes them want to reconsider their 
platform preferences.  We'll see.  As I already said, at this point 
it's about organizational questions, not technical ones. 


Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/0419




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


Re: Enhancement: Page breaking to avoid widow lines

2010-01-20 Thread Boris Shingarov

Quoting Joe Neeman :


Again, I'd suggest uploading patches to codereview.appspot.com, which
provides nice formatting and makes it easy to have multiple reviewers. 


Are there lilypond patches discussed there already?  I looked around 
the list of repositories, but I can't find Lilypond.  Is there anything 
special that I missed?


Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/0419



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


Re: GUB buiding from a local source tree?

2010-01-14 Thread Boris Shingarov

Umm.  It would be *way*, ***way*** easier to download lilybuntu and do
a normal compile in there


Then I probably had misunderstood the purpose of Lilybuntu -- I thought 
this was for people who did not have a real linux setup for doing 
lilypond development -- like, having all the prerequisites in place 
etc.  For *development*, I am completely fine and happy.  It's that I 
am now happy with the development results and need to deploy, and the 
ultimate users do not use linux.  How does lilybuntu produce the win32 
binary anyway?  wouldn't it need to do the exact same crosscompile as 
what would happen in a physical ubuntu box?



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


Re: GUB buiding from a local source tree?

2010-01-14 Thread Boris Shingarov

By the way, do you have a good reason to build using GUB anyway?


Because I read on the maillist that it was not possible to do a native 
build of lilypond for win32. 




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


Re: GUB buiding from a local source tree?

2010-01-14 Thread Boris Shingarov

Quoting Graham Percival :


Didn't you read the part where I said you had to read the source, and
that there was probably something wrong in the above line?

Line 17 of lilypond.make is:
LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git

That's not hard to find, and I think it's pretty clear that this is
what I meant. 


That's the very first thing I found, but that's NOT what you were 
talking about in the first e-mail. 
It is LILYPOND_REPO, which is a separate variable. 
You see, I read both the head revision and 2.11.64-1, and they both 
contain LILYPOND_REPO_URL.  But 2.11.64-1 contains LILYPOND_REPO as 
well as LILYPOND_REPO_URL, and it is LILYPOND_REPO that got removed. 

Now, my real question is, does LILYPOND_REPO_URL help, i.e. did it 
absorb the functionality which used to be achieved via LILYPOND_REPO.  
My understanding is that LILYPOND_REPO_URL is passed as an argument to 
git, and then the easiest way is to create a local git server and 
commit the changes to it. 

But right now, we are not even there, as even simply building the 
current official head from the main lilypond repository, does not work. 
 It hangs when trying to download from the standard url:


$ make -f lilypond.make lilypond-installers


python bin/gub --platform=linux-64 
'git://git.sv.gnu.org/lilypond.git?branch=master' 
mingw::'git://git.sv.gnu.org/lilypond.git?branch=master'


calculating dependencies

cd: 1: can't cd to /home/boris/work/lilypond/gub/gub/downloads/lilypond/git

read_pipe failed: cd 
/home/boris/work/lilypond/gub/gub/downloads/lilypond/git && git show 
git.sv.gnu.org/lilypond.git/master:VERSION


cd: 1: can't cd to /home/boris/work/lilypond/gub/gub/downloads/lilypond/git

read_pipe failed: cd 
/home/boris/work/lilypond/gub/gub/downloads/lilypond/git && git show 
git.sv.gnu.org/lilypond.git/master:VERSION


cd: 1: can't cd to /home/boris/work/lilypond/gub/gub/downloads/lilypond/git

read_pipe failed: cd 
/home/boris/work/lilypond/gub/gub/downloads/lilypond/git && git show 
git.sv.gnu.org/lilypond.git/master:VERSION



^C


Tail of log/gub.log 

Running read_pipe

  ('cd /home/boris/work/lilypond/gub/gub/downloads/lilypond/git && 
git show git.sv.gnu.org/lilypond.git/master:VERSION',)


  {'ignore_errors': False, 'env': {'PATH': 
'/home/boris/work/lilypond/gub/gub/target/tools/root/usr/bin:/home/boris/work/lilypond/gub/gub/target/tools/root/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/cuda/bin:/usr/jdk1.6.0_10/bin:/usr/local/cuda/bin:/usr/jdk1.6.0_10/bin', 'LD_LIBRARY_PATH': 
'/home/boris/work/lilypond/gub/gub/target/tools/root/usr/lib'}}


invoking cd . && git clone --depth 10 --bare 
git://git.sv.gnu.org/lilypond.git 
/home/boris/work/lilypond/gub/gub/downloads/lilypond/git


 Tail of log/gub.log



Traceback (most recent call last):

  File "bin/gub", line 233, in exceptional_build

build (settings, options, files)

  File "bin/gub", line 199, in build

specs[name].download ()

  File "bin/../gub/build.py", line 242, in download

logging.default_logger.write_log (self.stage_message ('download'),

  File "bin/../gub/build.py", line 108, in stage_message

env=locals ())

  File "bin/../gub/context.py", line 179, in expand

d = self.get_substitution_dict (env)

  File "bin/../gub/target.py", line 182, in get_substitution_dict

d = build.AutoBuild.get_substitution_dict (self, dict).copy ()

  File "bin/../gub/build.py", line 232, in get_substitution_dict

d = context.RunnableContext.get_substitution_dict (self, dict).copy ()

  File "bin/../gub/context.py", line 146, in get_substitution_dict

self._substitution_dict = self.get_constant_substitution_dict ()

  File "bin/../gub/context.py", line 125, in get_constant_substitution_dict

val = method ()

  File "bin/../gub/build.py", line 260, in source_checksum

return self.source.checksum ()

  File "bin/../gub/repository.py", line 657, in checksum

self.download ()

  File "bin/../gub/repository.py", line 639, in download

self.git ('clone --depth 10 --bare %(source)s %(dir)s' % locals 
(), dir='.')


  File "bin/../gub/repository.py", line 605, in git

ignore_errors=ignore_errors, env=self.get_env ())

  File "bin/../gub/repository.py", line 213, in logged

return loggedos_func (self.logger, *args, **kwargs)

  File "bin/../gub/loggedos.py", line 80, in system

line = proc.stdout.readline ()

KeyboardInterrupt

make: *** [packages] Error 1






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


Re: GUB buiding from a local source tree?

2010-01-13 Thread Boris Shingarov

Oh, and make sure you're using the latest GUB; IIRC there are 2 or
3 different git repositories floating around.  You want the one at
github. 


git://github.com/janneke/gub.git -- this one, right?


I believe you'll want something like
make -f lilypond.make LILYPOND_REPO=/location/of/your/tree lilypond


Looks like LILYPOND_REPO was removed from recent revisions?  I can see 
it being in lilypond.make as of 2.11.64-1:

http://github.com/janneke/gub/blob/build/lilypond-gub/2.11.64-1/lilypond.make

but simple 'git clone git://github.com/janneke/gub.git' ends up with a 
revision not having it. 




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


GUB buiding from a local source tree?

2010-01-13 Thread Boris Shingarov

Hi,

How do I tell GUB to build Lilypond from a modified source tree which I 
have locally, instead of getting it from git?  In general, where is the 
best place to start reading more on GUB, the info on the GUB page is 
very sketchy, and GUB-related messages on lilypond-devel seem far apart 
and browsing the list archive for a while, did not get me very far. 
My immediate need is to test out my patches on the mingw platform. 



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


Re: Enhancement: Page breaking to avoid widow lines

2010-01-13 Thread Boris Shingarov
Here is the new code -- implementing all that's been discussed.  (Ok, 
not quite all -- the line length functionality is not implemented, but 
all the style remarks have been taken into account, the markup-list-id 
has been replaced with is-last-line, penalty made configurable, and 
also, (new, was not discussed yet), the opposite case of lonely first 
(as opposed to last) line is now properly handled. 


Quoting Joe Neeman :

On Wed, 2010-01-13 at 09:11 -0500, Boris Shingarov wrote:
> Joe,
>
> > Paper_book::get_system_specs then you wouldn't even need the
> > markup-list-id property: you could add an avoid-orphan property that
> > only gets set for the last line of a multi-line markup list if it is
> > short. That might also simplify Page_spacer::calc_subproblem. 
>

> This is the first idea that came to my mind when I started implementing
> this code. 
> I wanted to have a member called "is_last_line_" instead of

> "markup_list_id_", that way the nested ifs in calc_subproblem() become
> much more readable.  But I wasn't sure how to calculate that property
> inside the Line_details(...) constructor. 


Can't you do it in Paper_book::get_system_specs and store it in the Prob
(and then read it from the Prob in Line_details(Prob*))?

Joe





diff --git a/lily/constrained-breaking.cc b/lily/constrained-breaking.cc
index 2fead24..6497cd5 100644
--- a/lily/constrained-breaking.cc
+++ b/lily/constrained-breaking.cc
@@ -525,4 +525,8 @@ Line_details::Line_details (Prob *pb, Output_def *paper)
   title_ = to_boolean (pb->get_property ("is-title"));
   compressed_lines_count_ = 1;
   compressed_nontitle_lines_count_ = title_ ? 0 : 1;
+  SCM last_scm  = pb->get_property ("last-markup-line");
+  last_markup_line_  = SCM_BOOLP(last_scm)  ? scm_to_bool (last_scm)  : 0;
+  SCM first_scm = pb->get_property ("first-markup-line");
+  first_markup_line_ = SCM_BOOLP(first_scm) ? scm_to_bool (first_scm) : 0;
 }
diff --git a/lily/include/constrained-breaking.hh b/lily/include/constrained-breaking.hh
index bb8a1d0..b9590a9 100644
--- a/lily/include/constrained-breaking.hh
+++ b/lily/include/constrained-breaking.hh
@@ -52,6 +52,7 @@ struct Line_details {
  class. */
   int compressed_lines_count_;
   int compressed_nontitle_lines_count_;
+  bool last_markup_line_, first_markup_line_;
 
   Line_details ()
   {
@@ -71,6 +72,8 @@ struct Line_details {
 title_ = false;
 compressed_lines_count_ = 1;
 compressed_nontitle_lines_count_ = 1;
+last_markup_line_ = 0;
+first_markup_line_ = 0;
   }
 
   Line_details (Prob *pb, Output_def *paper);
diff --git a/lily/include/page-breaking.hh b/lily/include/page-breaking.hh
index 2e5283d..d497d49 100644
--- a/lily/include/page-breaking.hh
+++ b/lily/include/page-breaking.hh
@@ -127,6 +127,7 @@ public:
   bool too_few_lines (int line_count) const;
   Real min_whitespace_at_top_of_page (Line_details const&) const;
   Real min_whitespace_at_bottom_of_page (Line_details const&) const;
+  int orphan_penalty () const;
 
 protected:
   Paper_book *book_;
@@ -179,6 +180,7 @@ private:
   int max_systems_per_page_;
   int min_systems_per_page_;
   vsize system_count_;
+  int orphan_penalty_;
 
   vector current_configurations_;
   vector current_chunks_;
diff --git a/lily/page-breaking.cc b/lily/page-breaking.cc
index e0a08c0..dc71659 100644
--- a/lily/page-breaking.cc
+++ b/lily/page-breaking.cc
@@ -174,6 +174,7 @@ Page_breaking::Page_breaking (Paper_book *pb, Break_predicate is_break)
   systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("systems-per-page"), 0));
   max_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("max-systems-per-page"), 0));
   min_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("min-systems-per-page"), 0));
+  orphan_penalty_ = robust_scm2int (pb->paper_->c_variable ("orphan-penalty"), 10);
 
   if (systems_per_page_ && (max_systems_per_page_ || min_systems_per_page_))
 {
@@ -1415,3 +1416,9 @@ Page_breaking::min_whitespace_at_bottom_of_page (Line_details const &line) const
   // FIXME: take into account the height of the footer
   return max (0.0, max (padding, min_distance + line.extent_[DOWN]));
 }
+
+int
+Page_breaking::orphan_penalty () const
+{
+  return orphan_penalty_;
+}
diff --git a/lily/page-spacing.cc b/lily/page-spacing.cc
index 8919257..8dbf183 100644
--- a/lily/page-spacing.cc
+++ b/lily/page-spacing.cc
@@ -245,6 +245,18 @@ Page_spacer::calc_subproblem (vsize page, vsize line)
 	penalty += lines_[page_start-1].page_penalty_
 	  + (page % 2 == 0) ? lines_[page_start-1].turn_penalty_ : 0;
 
+	  /* Deal with widow/orphan lines */
+	  /* Last line of paragraph is first line on the new page */
+	  if ((page_start > 0) &&
+	  (page_start < lines_.s

Re: Enhancement: Page breaking to avoid widow lines

2010-01-13 Thread Boris Shingarov

Joe,


Paper_book::get_system_specs then you wouldn't even need the
markup-list-id property: you could add an avoid-orphan property that
only gets set for the last line of a multi-line markup list if it is
short. That might also simplify Page_spacer::calc_subproblem. 


This is the first idea that came to my mind when I started implementing 
this code. 
I wanted to have a member called "is_last_line_" instead of 
"markup_list_id_", that way the nested ifs in calc_subproblem() become 
much more readable.  But I wasn't sure how to calculate that property 
inside the Line_details(...) constructor. 




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