date:20120226

On Sat, Feb 25, 2012 at 6:27 PM, Phil Holmes  wrote:
> Midi2ly, as used in the make doc build system, puts 2 types of message on
> the terminal: "LY output to (filename)" and "Warning, more than 5 voices
> found.  Expect bad output".
>
> Seems to me we could:
>
> 1) Get rid of the first message completely by deleting the print line.

+1

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

Re: Cross-staff stem engraver (was: New frog in an empty pond?)

2012-02-26 Thread Joe Neeman

On Sat, Feb 25, 2012 at 9:14 PM, Pavel Roskin  wrote:
>
>
> Using an engraver to catch the stems sounds like a good approach.  I could
> even do some filtering in the engraver.  And it should be possible to
> replace stems with one rather than connect them together.  It would
> simplify SVG output, and I suspect the connect point could be seen in some
> renderings of the postscript output.
>
> Thank you for your help!  I'm getting really close!


Glad to hear it :)

In case it wasn't clear from what I said before, engravers in lilypond
don't do the actual layout. Instead, they build the grobs and set up the
connections between them. Most of the layout is done in callback functions.

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

Important: GSoC mentors

We have a nice Ideas List for Google Summer of Code. Now, each
project should have a mentor, who's job is to guide the student
working on the code and evaluate his/her work.

Mentors may or may not receive money, but they will surely win Eternal
Glory (and maybe a Graham's Kiss, who knows?). Please declare which
project(s) you are willing to mentor (remember that not all projects
will be launched):

1) Fixing problems with synchronization of grace notes, together with
all underlying architecture (issue 34). Grace notes are counfusing to
LilyPond's timing because they're like going back in time. This
causes weird effects, especially when one staff has a grace note and
the other don't.
Requirements: C++, MIDI; familiarity with LilyPond code and basic
music notation recommended.

2) Adding comprehensive MusicXML export and improving import, together
with tests checking how it works. Depending on time available,
implement some or all of the following:
-) Handle basic musical content export like the MIDI export (i.e.
using dedicated exporter classes, derived from the translator class)
-) Build the XML tree of the basic musical content, add a connection
from music event to XML tag
-) Let all LilyPond engravers do their job
-) add ability to link each output object (basically each stencil /
group of stencils) to the music cause (and thus to the XML tag in the
XML tree)
-) Add a XML output backend, which can then add the layout information
for each output object to the XML tags
The goal will be considered achieved when a (previously chosen) score
could be imported from MusicXML and exported back with no
unintentional loss of data.
Requirements: MusicXML, Python, basic LilyPond and music notation
knowledge; familiarity with other scorewriters would be a nice bonus
(for cross-testing).

3) Horizontal Spacing of Objects Attached to Notes: make spacing
depend on tightness of the music. The infrastructure should be
generic and extensible, so as to cover many types of grobs like
accidentals, dots, arpeggios etc.
Adding on-staff-line, between-staff-line, shorter and narrower
variants of some glyphs, for example accidentals, together with a
generic infrasctucture to support them. An example of notehead coming
in two variants is here
http://lilypond.googlecode.com/issues/attachment?aid=1839001&name=hole+sizes+and+stem+thicknesses.png&token=hQOK78AGtkqG3PmB5YSWI0g1I68%3A1329042576520&inline=1
. Requirements: MetaFont, C++, good eye for details; basic LilyPond
knowledge recommended.
I (Janek) am willing to take this.

6) Improve default slur and tie curves - ties on enharmonic notes are
not supported { cis'~ des' }, ties "broken" by clef or staff change
aren't supprted well. Quite often LilyPond produces bad-looking slurs
and ties. Fixing this will require sorting examples of bad output and
generically deciding on intended output. Requirements: C++,
experience with writing heuristics; basic Scheme, music notation and
LilyPond knowledge recommended.

7) Improve default beaming. Better support for cross-staff, broken
and kneed beams; beaming should depend on context and neighbor notes
(see http://icking-music-archive.org/lists/sottisier/sottieng.pdf
section 2.2). Improve positioning of regular beams, possibly reducing
computation time. Requirements: C++, experience with writing
heuristics; basic music notation knowledge recommended.

8) clean up compiler warnings, static code analysis, and valgrind
warnings. Automatic code analysis tools (warnings in g++ and clang)
and analysis tools like valgrind memory leak detection and callgrind
code profilers provide valuable information about possible flaws in
C++ code. Cleaning these warnings would allow us to automatically
reject any patch which introduced extra warnings.

9) Rewrite font building system. Create a robust, scalable and easily
maintainable system for creating Open Type Fonts from Metafont code
(merging and dividing fontsets, handling different design sizes) using
Fontforge's built-in Python scripting support. Requirements: Python,
basic font and Metafont skills.

cheers,
Janek

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

Re: Important: GSoC mentors

Janek,

These are all excellent.  I'll signal below those for which I could be of use.

On Feb 26, 2012, at 10:28 AM, Janek Warchoł wrote:

> 1) Fixing problems with synchronization of grace notes, together with
> all underlying architecture (issue 34).
> 

Can do.

> 2) Adding comprehensive MusicXML export and improving import, together
> with tests checking how it works.

Can do.

> 
> 3) Horizontal Spacing of Objects Attached to Notes: make spacing
> depend on tightness of the music.

I couldn't check the metafont, but I could help w/ the C++.

> 
> 6) Improve default slur and tie curves - ties on enharmonic notes are
> not supported { cis'~ des' }, ties "broken" by clef or staff change
> aren't supprted well.

I can mentor for this as well.  It is a minefield :)

> 
> 7) Improve default beaming.

Ditto for mentoring and ditto for minefield.

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

Re: Web&CG: remove "projects" from HelpUs (issue 5665047)


pushed as ee5f21d7ed3b985913194699aa1d412e4bced562

http://codereview.appspot.com/5665047/

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

Re: [frogs] Re: New frog in an empty pond?

2012-02-26 Thread Phil Holmes

- Original Message - 
From: "Colin Campbell" 

To: 
Sent: Saturday, February 25, 2012 11:37 PM
Subject: Re: [frogs] Re: New frog in an empty pond?

On 12-02-25 03:32 AM, Phil Holmes wrote:
- Original Message - From: "Janek Warchoł" 

Fortunately it's mostly me whom i'm doing this for :)
(is the above proper English, anyway?)

cheers,
Janek

"Fortunately, I'm mostly doing this for me."  would be fair idiomatic 
English.  Some people would say "myself" rather than "me".

--
Phil Holmes

"It is I for whom I do this" grumps a fusty old prescriptivist in the 
corner.

Colin

Colonial.

--
Phil Holmes

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

CG: a note about articulations on EventChord (issue 5696080)


Reviewers: ,

Message:
This is a bit vague and perhaps wordy, but i found it really helpful
when David was changing EventChord.
I'm not sure if this text reflects how things work now (wrt/ David's
changes) - hopefully someone knowledgeable will confirm.

Description:
CG: a note about articulations on EventChord

Explains a bit about iterators.

Please review this at http://codereview.appspot.com/5696080/

Affected files:
  M Documentation/contributor/programming-work.itexi


Index: Documentation/contributor/programming-work.itexi
diff --git a/Documentation/contributor/programming-work.itexi  
b/Documentation/contributor/programming-work.itexi
index  
1ff0247a731a2fd725ae08507a12fca73fa9a3cd..0897ca125211074cb7d986a1a457cc826520898f  
100644

--- a/Documentation/contributor/programming-work.itexi
+++ b/Documentation/contributor/programming-work.itexi
@@ -1567,6 +1567,9 @@ Iterators are routines written in C++ that process  
music expressions

 and sent the music events to the appropriate engravers and/or
 performers.

+See a short example discussing iterators and their duties in
+@ref{Articulations on EventChord}.
+

 @node Engraver tutorial
 @section Engraver tutorial
@@ -2248,6 +2251,7 @@ would become zero as items are moved to other homes.
 * Spacing algorithms::
 * Info from Han-Wen email::
 * Music functions and GUILE debugging::
+* Articulations on EventChord::
 @end menu

 @node Spacing algorithms
@@ -2653,3 +2657,30 @@ The breakpoint failing may have to do with the call  
sequence.  See
 @file{parser.yy}, run_music_function().  The function is called directly  
from

 C++, without going through the GUILE evaluator, so I think that is why
 there is no debugger trap.
+
+@node Articulations on EventChord
+@subsection Articulations on EventChord
+
+From David Kastrup's email
+@uref{http://lists.gnu.org/archive/html/lilypond-devel/2012-02/msg00189.html}:
+
+LilyPond's typesetting does not act on music expressions and music
+events.  It acts exclusively on stream events.  It is the act of
+iterators to convert a music expression into a sequence of stream events
+played in time order.
+
+The EventChord iterator is pretty simple: it just takes its "elements"
+field when its time comes up, turns every member into a StreamEvent and
+plays that through the typesetting process.  The parser currently
+appends all postevents belonging to a chord at the end of "elements",
+and thus they get played at the same point of time as the elements of
+the chord.  Due to this design, you can add per-chord articulations or
+postevents or even assemble chords with a common stem by using parallel
+music providing additional notes/events: the typesetter does not see a
+chord structure or postevents belonging to a chord, it just sees a
+number of events occuring at the same point of time in a Voice context.
+
+So all one needs to do is let the EventChord iterator play articulations
+after elements, and then adding to articulations in EventChord is
+equivalent to adding them to elements (except in cases where the order
+of events matters).



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

Re: GUB build problems

2012-02-26 Thread Graham Percival

On Sat, Feb 25, 2012 at 10:01:21PM +, Carl Sorensen wrote:
> Looking at the failed command, it appears to me that gcc_tooldir is wrong.
> 
> There is no directory /usr/powerpc-apple-darwin7

I just tried a build from scratch on ubuntu 11.10 64-bit, and I
have a possibly-related build failure:


building package: darwin-x86::cross/gcc
 *** Stage: download (cross/gcc, darwin-x86)
 *** Stage: untar (cross/gcc, darwin-x86)
 *** Stage: patch (cross/gcc, darwin-x86)
 *** Stage: autoupdate (cross/gcc, darwin-x86)
 *** Stage: configure (cross/gcc, darwin-x86)
 *** Stage: compile (cross/gcc, darwin-x86)
^[[ACommand barfed: cd
/main/src/gub/target/darwin-x86/build/cross/gcc-4.3.2 && make -j8
tooldir='/main/src/gub/target/darwin-x86/root/usr/cross/i686-apple-darwin8'
gcc_tooldir='/usr/i686-apple-darwin8'  

Tail of target/darwin-x86/log/cross/gcc.log 
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory
`/main/src/gub/target/darwin-x86/build/cross/gcc-4.3.2'
make: *** [all] Error 2
Command barfed: cd
/main/src/gub/target/darwin-x86/build/cross/gcc-4.3.2 && make -j8
tooldir='/main/src/gub/target/darwin-x86/root/usr/cross/i686-apple-darwin8'
gcc_tooldir='/usr/i686-apple-darwin8'
 Tail of target/darwin-x86/log/cross/gcc.log

*** Failed target: darwin-x86::cross/gcc
make: *** [cross-compilers] Error 1



The relevant config.log contains: 

configure:2588:
/main/src/gub/target/darwin-x86/build/cross/gcc-4.3.2/./gcc/xgcc
-B/main/src/gub/target/darwin-x86/build/cross/gcc-4.3.2/./gcc/
-B/main/src/gub/target/darwin-x86/root/usr/cross/i686-apple-darwin8/bin/
-B/main/src/gub/target/darwin-x86/root/usr/cross/i686-apple-darwin8/lib/
-isystem
/main/src/gub/target/darwin-x86/root/usr/cross/i686-apple-darwin8/include
-isystem
/main/src/gub/target/darwin-x86/root/usr/cross/i686-apple-darwin8/sys-include
-c -O2 -g -g -O2conftest.c >&5
/main/src/gub/target/darwin-x86/build/cross/gcc-4.3.2/./gcc/cc1:
error while loading shared libraries: libmpfr.so.1: cannot open
shared object file: No such file or directory
configure:2591: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }


I _do_ have libmpfr installed:

$ -l /usr/lib/libmpfr.*
-rw-r--r-- 1 root root 888130 2011-07-27 13:06 /usr/lib/libmpfr.a
lrwxrwxrwx 1 root root 16 2011-07-27 13:06 /usr/lib/libmpfr.so
-> libmpfr.so.4.0.1
lrwxrwxrwx 1 root root 16 2011-11-20 23:43
/usr/lib/libmpfr.so.4 -> libmpfr.so.4.0.1
-rw-r--r-- 1 root root 348472 2011-07-27 13:06
/usr/lib/libmpfr.so.4.0.1


$ ls -l /usr/include/mpf*
-rw-r--r-- 1 root root  6288 2011-07-27 13:04
/usr/include/mpf2mpfr.h
-rw-r--r-- 1 root root 47984 2011-07-27 13:04 /usr/include/mpfr.h


- Graham

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

On Fri, Feb 24, 2012 at 12:50 AM, m...@apollinemike.com
 wrote:
> On Feb 24, 2012, at 12:07 AM, Janek Warchoł wrote:
>> dynamic texts aren't skylined, their outlines are still rectangles.
>
> The issue is that dynamics are created via Pango and thus I can only use 
> rectangles
> for the time being.  A separate issue in the tracker can be opened for 
> redoing dynamics
> so that they used a series of named-glyph stencils.

Hmm.  But what about custom dynamics created using
make-dynamic-script?
(http://www.lilypond.org/doc/v2.15/Documentation/notation/expressive-marks-attached-to-notes#new-dynamic-marks)
I mean, isn't Pango necessary to create them?  If so, it seems to me
that what you suggest will result in having two types of dynamics:
simple stencil dynamics and advanced Pango dynamics.  This doesn't
sound good to me.
I think the question is: should we rather try to "break inside Pango"
to be able to create precise outlines for everything that is processed
by Pango?  The advantage of this approach would be that lyrics and
markups would be skylined even better.

cheers,
Janek

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

log files not deleted by doc-clean

2012-02-26 Thread Jean-Charles Malahieude


Hi !

Regarding issues 2302 and 2311, which by the way are very comfortable,
I just noticed that no log file is deleted when running either
"make doc-clean" or "make clean".

Cheers,
Jean-Charles


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

Re: log files not deleted by doc-clean

2012-02-26 Thread Phil Holmes

- Original Message - 
From: "Jean-Charles Malahieude" 

To: "Julien Rioux" ; 
Cc: "lilypond-devel" 
Sent: Sunday, February 26, 2012 1:06 PM
Subject: log files not deleted by doc-clean

Hi !

Regarding issues 2302 and 2311, which by the way are very comfortable,
I just noticed that no log file is deleted when running either
"make doc-clean" or "make clean".

Cheers,
Jean-Charles

Not sure if that's a good thing or not - it could be argued that you can go 
back and check them if they've not been deleted.

FWIW the CG says: "In some cases, it is possible to clean the compiled 
documentation with 'make doc-clean', but this method is not guaranteed to 
fix everything. Instead, we recommend that you delete your 'build/' 
directory, and begin compiling from scratch. " 
(http://lilypond.org/doc/v2.15/Documentation/contributor/generating-documentation#documentation-editor_0027s-edit_002fcompile-cycle)

--
Phil Holmes

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

Re: log files not deleted by doc-clean

2012-02-26 Thread Graham Percival

On Sun, Feb 26, 2012 at 01:30:53PM -, Phil Holmes wrote:
> Not sure if that's a good thing or not - it could be argued that you
> can go back and check them if they've not been deleted.

I don't think they should be deleted as part of doc-clean or
clean.  If somebody wants to add a log-clean, I'd have no
objection.

- Graham

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

Re: log files not deleted by doc-clean

2012-02-26 Thread Jean-Charles Malahieude


Le 26/02/2012 14:30, Phil Holmes disait :

- Original Message - From: "Jean-Charles Malahieude"


Regarding issues 2302 and 2311, which by the way are very comfortable,
I just noticed that no log file is deleted when running either
"make doc-clean" or "make clean".



Not sure if that's a good thing or not - it could be argued that you can
go back and check them if they've not been deleted.

Since they get overwritten on the next "make doc"... (unless they get a 
time stamp appended to the name)



FWIW the CG says: "In some cases, it is possible to clean the compiled
documentation with 'make doc-clean', but this method is not guaranteed
to fix everything. Instead, we recommend that you delete your 'build/'
directory, and begin compiling from scratch. "
(http://lilypond.org/doc/v2.15/Documentation/contributor/generating-documentation#documentation-editor_0027s-edit_002fcompile-cycle)



I've never used "build/" but a local clone.

I nevertheless think that "make clean" should delete those logs.

Cheers,
Jean-Charles

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

Re: log files not deleted by doc-clean

2012-02-26 Thread David Kastrup

Graham Percival  writes:

> On Sun, Feb 26, 2012 at 01:30:53PM -, Phil Holmes wrote:
>> Not sure if that's a good thing or not - it could be argued that you
>> can go back and check them if they've not been deleted.
>
> I don't think they should be deleted as part of doc-clean or
> clean.  If somebody wants to add a log-clean, I'd have no
> objection.

Whatever else, they should definitely be deleted as part of distclean.

-- 
David Kastrup


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

Fix for several musicxml2ly bugs. (issue 5697059)

2012-02-26 Thread ptrcklschmdt


Reviewers: ,

Description:
Fix for several musicxml2ly bugs.



musicxml2ly: title, chord symbol and midi bug

Titles and headers can now contain single words followed by a
 punctuation mark (.,!:).  See issue 1983.

Chord symbols are now placed above staffs instead of below.

musicxml2ly now includes an out-commented midi-block in every .ly-file.

Docs: Added command line options -m and --midi to Usage

Please review this at http://codereview.appspot.com/5697059/

Affected files:
  M Documentation/usage/external.itely
  M python/musicexp.py
  M python/musicxml.py
  M scripts/musicxml2ly.py



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

Re: Gets vertical skylines from grob stencils (issue 5626052)

On Feb 26, 2012, at 1:08 PM, Janek Warchoł wrote:

> On Fri, Feb 24, 2012 at 12:50 AM, m...@apollinemike.com
>  wrote:
>> On Feb 24, 2012, at 12:07 AM, Janek Warchoł wrote:
>>> dynamic texts aren't skylined, their outlines are still rectangles.
>> 
>> The issue is that dynamics are created via Pango and thus I can only use 
>> rectangles
>> for the time being.  A separate issue in the tracker can be opened for 
>> redoing dynamics
>> so that they used a series of named-glyph stencils.
> 
> should we rather try to "break inside Pango"
> to be able to create precise outlines for everything that is processed
> by Pango?  The advantage of this approach would be that lyrics and
> markups would be skylined even better.
> 

I'd like to do this...I'm just not sure if it's possible.  Joe (or someone who 
knows fonts) - is there a way to get font outlines of pango fonts?

Cheers,
MS


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

2012-02-26 Thread David Kastrup

"m...@apollinemike.com"  writes:

> On Feb 26, 2012, at 1:08 PM, Janek Warchoł wrote:
>
>> On Fri, Feb 24, 2012 at 12:50 AM, m...@apollinemike.com
>>  wrote:
>>> On Feb 24, 2012, at 12:07 AM, Janek Warchoł wrote:
 dynamic texts aren't skylined, their outlines are still rectangles.
>>> 
>>> The issue is that dynamics are created via Pango and thus I can
>>> only use rectangles
>>> for the time being.  A separate issue in the tracker can be opened
>>> for redoing dynamics
>>> so that they used a series of named-glyph stencils.
>> 
>> should we rather try to "break inside Pango"
>> to be able to create precise outlines for everything that is processed
>> by Pango?  The advantage of this approach would be that lyrics and
>> markups would be skylined even better.
>> 
>
> I'd like to do this...I'm just not sure if it's possible.  Joe (or
> someone who knows fonts) - is there a way to get font outlines of
> pango fonts?

The reason we are using Pango in the first place is because it is good
at composing Unicode (with kerning, ligatures, accents, writing
direction etc etc).  So we don't want the outlines of its fonts but
rather the outlines of the composed result.

Not that I would have a clue about the answer to either your question or
the changed question.

-- 
David Kastrup

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

Re: Issue 2100: Explanation of branches for CG (issue 5539062)


Carl, could you close this Rietveld issue?
Janek

http://codereview.appspot.com/5539062/

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

Re: CG: add information about Regtest Checking Project (issue 5669047)


Screw this; i tried using regular refs but they produced  hideous
effects in html. I'm going back to named references; they are not
perfect but acceptable i'd say.

http://codereview.appspot.com/5669047/

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

web: rephrase bugreports section (issue 5698070)


Reviewers: ,

Message:
Please review.

Description:
web: rephrase bugreports section

According to Graham's favorite rule ("perfection is attained
when there's nothing more to delete") i'm rephrasing bugreports
section hoping to make it even more brief and straightforward
for all users.

Please review this at http://codereview.appspot.com/5698070/

Affected files:
  M Documentation/web/community.itexi


Index: Documentation/web/community.itexi
diff --git a/Documentation/web/community.itexi  
b/Documentation/web/community.itexi
index  
a6af03f96cd7ac64de4cdbe6f4f711b575209de5..f3a15c60754df3ef372bfec86b8634d3002be488  
100644

--- a/Documentation/web/community.itexi
+++ b/Documentation/web/community.itexi
@@ -390,20 +390,23 @@ quite often 4 lines are enough to demonstrate the  
problem!

 @node Bug reports
 @unnumberedsec Bug reports

+
+@divClass{heading-center}
+If you have input that results in a crash or wrong output,
+then that is a bug.
+@divEnd
+
 @divClass{column-center-top}
 @subheading Step 1: Known bugs

-If you have input that results in a crash or an erroneous output,
-then that is a bug.  There is a list of current bugs on our google
-bug tracker,
+We may already know about this bug.  Check here:

 @example
 @uref{http://code.google.com/p/lilypond/issues/list}
 @end example

-@warning{Please @strong{DO NOT} add bug reports directly to the
-bug tracker.  Once an issue has been added to the tracker, feel
-free to add more information to that report.}
+@warning{Please @strong{DO NOT} add bug reports to the
+bug tracker yourself.}

 @divEnd

@@ -411,12 +414,12 @@ free to add more information to that report.}
 @divClass{column-left-bottom}
 @subheading Step 2: Creating a bug report

-If you have discovered a bug which is not listed, please help us
-by creating a bug report.
+If you have discovered a bug which is not listed,
+please help us by creating a bug report.

-@warning{We only accept bug reports in the form of
-@ref{Tiny examples}.  We have very limited resources to deal with
-bug reports, so any non-minimal example will be rejected.  Almost
+@warning{We only accept reports in the form of
+@ref{Tiny examples}.  We have very limited resources,
+so any non-minimal example will be rejected.  Almost
 every bug can be demonstrated in four notes or less!}

 Here is an example of a good bug report:
@@ -473,13 +476,14 @@ report.
 @divClass{column-center-bottom}
 @subheading Step 4: Wait for a response

-Once your bug has been sent to the list, our Bug Squad will
-examine the report.  Please allow up to 4 days, as we have a
-limited number of volunteers for this task.  They may ask you for
-more information, or may add the report to the tracker and let you
-know what the issue number is.
+Once your bug report has been sent to the list, our Bug Squad will
+examine it; they may ask you for more information.  You will be notified
+when the report will be added to the bug tracker. Please allow up to 4  
days,

+as we have a limited number of volunteers for this task.

-You may mark the bug so that you automatically receive emails when
+Once a bug has been added to the tracker, you can comment it to add
+more information about it.
+You may also mark the bug so that you automatically receive emails when
 any activity on the bug occurs.  This requires you have a google
 account.
 @divEnd



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

Re: Gets vertical skylines from grob stencils (issue 5626052)

2012-02-26 Thread Werner LEMBERG


>>> should we rather try to "break inside Pango" to be able to create
>>> precise outlines for everything that is processed by Pango?  The
>>> advantage of this approach would be that lyrics and markups would
>>> be skylined even better.
> 
> The reason we are using Pango in the first place is because it is
> good at composing Unicode (with kerning, ligatures, accents, writing
> direction etc etc).  So we don't want the outlines of its fonts but
> rather the outlines of the composed result.

AFAIK, Pango returns a list of glyph indices and coordinates to
position glyphs.  It's straightforward to feed those indices directly
into FreeType's `FT_Load_Glyph' function which is able to return an
`FT_Outline' structure holding the glyph's outline.


Werner

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

On Feb 26, 2012, at 7:37 PM, Werner LEMBERG wrote:
> 
> AFAIK, Pango returns a list of glyph indices and coordinates to
> position glyphs.  It's straightforward to feed those indices directly
> into FreeType's `FT_Load_Glyph' function which is able to return an
> `FT_Outline' structure holding the glyph's outline.
> 

This is great Werner - thank you!  I just checked out FT_Outline.  It's really 
straightforward, which is great.
Joe - this likely means that the build system work you were thinking about 
doing w/ glyph outlines is no longer necessary and that I can scrap all of the 
.scm stuff I wrote and replace it with calls to this.  I'll have time Wednesday 
morning to check this out.

Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Gets vertical skylines from grob stencils (issue 5626052)

2012-02-26 Thread Joe Neeman

On Sun, Feb 26, 2012 at 11:25 AM, m...@apollinemike.com <
m...@apollinemike.com> wrote:

> On Feb 26, 2012, at 7:37 PM, Werner LEMBERG wrote:
>
>
> AFAIK, Pango returns a list of glyph indices and coordinates to
> position glyphs.  It's straightforward to feed those indices directly
> into FreeType's `FT_Load_Glyph' function which is able to return an
> `FT_Outline' structure holding the glyph's outline.
>
>
> This is great Werner - thank you!  I just checked out FT_Outline.  It's
> really straightforward, which is great.
> Joe - this likely means that the build system work you were thinking about
> doing w/ glyph outlines is no longer necessary and that I can scrap all of
> the .scm stuff I wrote and replace it with calls to this.  I'll have time
> Wednesday morning to check this out.
>

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

On Sun, Feb 26, 2012 at 8:25 PM, m...@apollinemike.com
 wrote:
> On Feb 26, 2012, at 7:37 PM, Werner LEMBERG wrote:
>> AFAIK, Pango returns a list of glyph indices and coordinates to
>> position glyphs.  It's straightforward to feed those indices directly
>> into FreeType's `FT_Load_Glyph' function which is able to return an
>> `FT_Outline' structure holding the glyph's outline.
>
> This is great Werner - thank you!  I just checked out FT_Outline.  It's
> really straightforward, which is great.

Wonderful!

> Joe - this likely means that the build system work you were thinking about
> doing w/ glyph outlines is no longer necessary and that I can scrap all of
> the .scm stuff I wrote and replace it with calls to this.  I'll have time
> Wednesday morning to check this out.

I can't wait!  That's incredible!

cheers,
Janek

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

Re: Issue 2100: Explanation of branches for CG (issue 5539062)

2012-02-26 Thread Carl Sorensen

On 2/26/12 9:34 AM, "janek.lilyp...@gmail.com" 
wrote:

>Carl, could you close this Rietveld issue?
>Janek
>
>http://codereview.appspot.com/5539062/
>

Done, thanks.

Carl


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

Re: Handling of open strings in tablature (issue 5695058)

2012-02-26 Thread Carl . D . Sorensen


Looks like a good solution.

I think I would prefer the name excludeOpenStrings to ignoreOpenStrings.

I think "exclude" is a better word for what is happening than "ignore"

Thanks,

Carl


http://codereview.appspot.com/5695058/

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

PATCH: Countdown to 20120228

2012-02-26 Thread Colin Campbell


For 20:00 MST Tuesday February 28

Ugly:
Issue 2148 
: vertical 
skylines should use stencil integrals - R 5626052 



Documentation:
Issue 2346 
: Use 
convert-ly from latest development release for LSR updates - R 5696069 



Enhancement:
Issue 2347 
: Patch: 
Improving \harmonicBy... functions - R 5695059 

Issue 2348 
: Patch: 
Handling of open strings in tablature - R 5695058 



Patch:
Issue 2351 
: Patch: 
Removes mutopia-index.py processing - R 5696073 

Issue 2353 
: Patch: More 
reductions in make doc - R 5694079 


Cheers,

Colin

--
Criticism, like rain, should be gentle enough to nourish a man's growth 
without destroying his roots.

- Frank A. Clark, writer (1911- )
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCH: Countdown to 20120228