Re: Doc: Add how to change the notation fonts (issue 330040043 by truer...@gmail.com)

[tisimst . lilypond]

LGTM


https://codereview.appspot.com/330040043/

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

Re: Doc: Add how to change the notation fonts (issue 330040043 by truer...@gmail.com)

[tisimst . lilypond]

I like the changes. Just a few more comments for clarification.


https://codereview.appspot.com/330040043/diff/20001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/330040043/diff/20001/Documentation/notation/input.itely#newcode2847
Documentation/notation/input.itely:2847: Note: @code{set-global-fonts}
can change not only the notation fonts
Maybe change the wording slightly:

"Note: Each call to @code{set-global-fonts} completely resets both the
main notation and text fonts. If any category is left unspecified, then
the default font will be used for that category.

Each call to @code{set-global-fonts} changes the fonts for each
@code{\book} that follows it, whether created explicitly or implicitly.
This means that each @code{\book} can have its own set of main fonts by
calling @code{set-global-fonts} before it."

https://codereview.appspot.com/330040043/diff/20001/Documentation/notation/input.itely#newcode2881
Documentation/notation/input.itely:2881: Note: The only allowed font
names must have the
I would reword this to be a bit more specific so there's no confusion
about what is/isn't expected:

"Note: At the moment, LilyPond expects the font file names to have the
following suffixes, all of which must be present in the above
installation folder(s) to work properly:"

The only caveat is that the user doesn't technically need to have BOTH
the music font set (with the -11, -13, -14, -16, -18, -20, -23, and -26
suffixes) AND a brace font (with the -brace suffix) for one or the other
to work, but the music font set must have a file for ALL of those
suffixes and the brace font must have its suffix.

The reason for this is that the internal functions are hard-wired to
require this, but can be modified quite easily to allow for more
flexibility in the number of music font files. They could also be
changed so the brace font no longer needs its -brace suffix, but maybe
it should be kept that way since there's only one brace font file. I
have configured the functions to allow this on my machine and haven't
seen any issues in functionality.

https://codereview.appspot.com/330040043/diff/20001/Documentation/notation/input.itely#newcode2884
Documentation/notation/input.itely:2884: That is,
@file{@var{fontname}-11.otf}, @file{@var{fontname}-20.svg},
I think it makes sense to be specific here, with something like "For
example, @file{emmentaler-11.otf}" instead of "That is,
@file{@var{fontname}-11.otf}".

https://codereview.appspot.com/330040043/diff/20001/Documentation/notation/text.itely
File Documentation/notation/text.itely (right):

https://codereview.appspot.com/330040043/diff/20001/Documentation/notation/text.itely#newcode1618
Documentation/notation/text.itely:1618: as the above
@code{make-pango-font-tree} example.
Since users are now using other music fonts, I think we better add a
note to make-pango-font-tree that says this resets the music font to
Emmentaler so that no one is surprised when this happens. Should
make-pango-font-tree be deprecated in favor of set-global-fonts?

https://codereview.appspot.com/330040043/diff/20001/Documentation/notation/text.itely#newcode1644
Documentation/notation/text.itely:1644: #:brace "emmentaler"
; default
It is important to note that the user does NOT specify the suffix of the
font (e.g, "emmentaler-18" and "emmentaler-brace"), only the root font
_file name_ "emmentaler" and NOT the internal font name "Emmentaler".
The suffixes are added internally when the font tree is being created
and looking up the font files. A simple note to say the suffixes are not
needed (indeed, will cause an error if given) would suffice, IMO. This
only applies to the #:music and #:brace strings. The text fonts expect
the internal font names.

https://codereview.appspot.com/330040043/diff/20001/Documentation/notation/text.itely#newcode1654
Documentation/notation/text.itely:1654: Each call of
@code{set-global-fonts} affects only the following book(s).
Maybe reword this paragraph a little:

"Each call of @code{set-global-fonts} affects each @code{\book} blocks
that follow it.

If there are multiple @code{\book} blocks and you want to use different
fonts for each, simply call @code{set-global-fonts} again, like this:"

https://codereview.appspot.com/330040043/

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

Re: Doc: Add how to change the notation fonts (issue 330040043 by truer...@gmail.com)

[tisimst . lilypond]

https://codereview.appspot.com/330040043/diff/1/Documentation/notation/text.itely
File Documentation/notation/text.itely (right):

https://codereview.appspot.com/330040043/diff/1/Documentation/notation/text.itely#newcode1627
Documentation/notation/text.itely:1627: #:factor (/ staff-height pt 20)
I'm not sure showing the use of #:factor is helpful here, unless we also
show WHY, which is, if set-global-staff-size is used to change the staff
size from the default of 20pt.

So, I'd either recommend removing this line or adding a staff size
change along with an explanation.

https://codereview.appspot.com/330040043/

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

Doc: Add how to change the notation fonts (issue 330040043 by truer...@gmail.com)

[tisimst . lilypond]

https://codereview.appspot.com/330040043/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/330040043/diff/1/Documentation/notation/input.itely#newcode2845
Documentation/notation/input.itely:2845: @end example
I think it would be prudent to show all the inputs in one place, at
least their defaults, so users know what acceptable. At the moment they
are:
- #:music
- #:brace
- #:roman
- #:sans
- #:typewriter

I know the text font keywords show up in text.itely, but I think they
should all show up together somewhere.

It is also important for users to understand that you can only apply
(set-global-fonts ... ) once per \book block since it resets the `fonts`
variable each time you call the function. The following does work,
though:

\paper {
  #(set-global-fonts ... )
}
\book { ... }

\paper {
  #(set-global-fonts ... )
}
\book { ... }

where each call to set-global-fonts only affects the book(s) following
it unless re-called as shown.

https://codereview.appspot.com/330040043/diff/1/Documentation/notation/input.itely#newcode2866
Documentation/notation/input.itely:2866: you can use them in the same
way as Gonville.
This is true, but at the moment, the only allowed font names must have
the following suffixes: -11, -13, -14, -16, -18, -20, -23, -26, -brace.
This is easily remedied by modifying the internal function, but for now
at the user level, this is a significant limitation because it assumes
that the music font has ALL the above optical sizes and/or brace font.
Not sure what information here is most appropriate, but I think we would
should at least raise this flag so users realize that you can't use just
any music font out there that might work with other apps (like Sibelius,
Finale, Dorico, etc.).

https://codereview.appspot.com/330040043/

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

Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)

[tisimst . lilypond]

On 2017/08/01 17:49:47, lemzwerg wrote:

> I looked into the latest Harfbuzz internals, and it looks like
> the list of supported OpenType features is manually maintained.



Nope.



> Not all the features listed on the Microsoft feature registry
> are supported, but many are.



HarfBuzz is agnostic to most features; if you select a feature, and

the feature

is available, and the other feature constraints are met, it simply

gets applied.


> This list [in HarfBuzz] covers pretty much all likely candidates
> a user is going to encounter or want to use in modern fonts, so it
> probably isn't worth listing each of the supported features.



You are mistaken.  What you are referring to is a special interface to

OSX's

`coretext' implementation of OpenType.


I very much appreciate your insight and correction. So, there's no
reason to provide or point to a separate list other than the Microsoft
registry?



https://codereview.appspot.com/328140043/

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

Re: OpenType info tools

[tisimst]

On Tue, Aug 1, 2017 at 6:10 AM, Werner LEMBERG [via Lilypond] <
ml+s1069038n204767...@n5.nabble.com> wrote:

>
> the following two tools should help any user identify scripts and
> features of OpenType fonts.
>
> `fontdrop' is a nice browser tool which analyzes a font on your
> harddisk without uploading it to a place in the internet.  It needs a
> recent browser that supports OpenType CSS features.
> [I haven't checked what license this stuff actually is.]
>
>   http://fontdrop.viktornuebel.com/
>
> `otfinfo' is a command line tool which is part of TeXLive and probably
> other TeX distributions also; it is also available from
>
>   https://www.lcdf.org/type/
>

Thanks for finding these!

FontDrop is really handy! I can see myself using it all the time. Although
it seems to support many of the most likely used features, it doesn't show
them all.

`otfinfo' seems to support more (all?), but does require the separate
TeXLive install.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/OpenType-info-tools-tp204767p204789.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)

[tisimst . lilypond]

On 2017/07/31 17:55:29, tisimst wrote:

On 2017/07/31 17:48:10, lemzwerg wrote:
> It's not Pango but HarfBuzz that processes (i.e., applies) the

OpenType

> features to a run of glyphs.



Ah, I see! Thanks for clarifying that. I didn't realize Harfbuzz was

part of the

picture. Guess I haven't looked deep enough into the code.


I looked into the latest Harfbuzz internals, and it looks like the list
of supported OpenType features is manually maintained. Not all the
features listed on the Microsoft feature registry are supported, but
many are. The full list can be found here:

https://github.com/behdad/harfbuzz/blob/9813be3d1212eef5a525d64978e0bb2032cd44d9/src/hb-coretext.cc#L439

This list covers pretty much all likely candidates a user is going to
encounter or want to use in modern fonts, so it probably isn't worth
listing each of the supported features.

https://codereview.appspot.com/328140043/

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

Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)

[tisimst . lilypond]

On 2017/08/01 15:08:11, trueroad wrote:

On 2017/08/01 15:05:46, trueroad wrote:
> Add notes and identification way



If I understand correctly, I've found a current limitation.
I could not find a way to specify OpenType font scripts and languages.



So I've added it to the document.
Also I've added feature identification way etc.


If I'm not mistaken, you don't need to specify the script/language.
That's part of the OpenType feature itself. In other words, if the
feature is requested for a glyph outside the scripts/languages that the
feature was specified for, the feature is not applied. Is that correct,
Werner?

Otherwise, LGTM.

https://codereview.appspot.com/328140043/

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

Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)

[tisimst . lilypond]

On 2017/07/31 17:48:10, lemzwerg wrote:

> If Pango really is agnostic of the features, that is really exciting

and a bit

> mysterious ;-).



Why?  It's not Pango but HarfBuzz that processes (i.e., applies) the

OpenType

features to a run of glyphs.


Ah, I see! Thanks for clarifying that. I didn't realize Harfbuzz was
part of the picture. Guess I haven't looked deep enough into the code.

https://codereview.appspot.com/328140043/

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

Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)

[tisimst . lilypond]

On 2017/07/31 16:58:40, lemzwerg wrote:

In general, Pango is agnostic of the features themselves, AFAIK.  It

simply

forwards the selected stuff to the font in question.


If Pango really is agnostic of the features, that is really exciting and
a bit mysterious ;-).


However, the user has first to look up what the font he or she wants

to use

actually supports, but this is not lilypond's job.


Oh, I get that. Perhaps a note should be added, though, to mention that
if the user requests a feature that doesn't exist in the chosen font,
then the feature is simply ignored.


What could be added, though, is a link to such a font inspection tool

that

reports the font's OpenType capabilities (i.e., supported scripts,

languages,

features).


Sounds good to me! Is there a web-based tool that can do this? That'd
eliminate the need to install another app just to inspect a font's
features. I use FontForge all the time, so I understand how to do it,
but a "normal" user probably won't have a font editor.



https://codereview.appspot.com/328140043/

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

Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)

[tisimst . lilypond]

On 2017/07/27 13:47:01, trueroad wrote:

Thank you for your reviewing.



https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely

File Documentation/changes.tely (right):



https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely#newcode1037

Documentation/changes.tely:1037:
On 2017/07/26 20:09:33, lemzwerg wrote:
> It would be nice to have an example of a feature that needs an index

(e.g.,

the
> `salt' or `swsh' features).



Done.



https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.itely

File Documentation/notation/text.itely (right):



https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.itely#newcode1464

Documentation/notation/text.itely:1464:
On 2017/07/26 15:38:12, pkx166h wrote:
> Would it be appropriate to add something after this @lilypond

example like:

>
> For the full OpenType font feature list please see:
>
> @uref{https://www.microsoft.com/typography/otspec/featurelist.htm}
>
> Otherwise LGTM



Done.


This is really great! Do you happen know what the current limitations
are? Or rather, having the full feature list is great, but if only a few
features are actually recognized by the underlying typography engine
(it's still Pango, right?), that would probably be a better list to
show, unless they're all recognized, of course.

https://codereview.appspot.com/328140043/

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

Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)

[tisimst . lilypond]

https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.itely
File Documentation/notation/text.itely (right):

https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.itely#newcode1464
Documentation/notation/text.itely:1464:
On 2017/07/26 15:38:12, pkx166h wrote:

Would it be appropriate to add something after this @lilypond example

like:


For the full OpenType font feature list please see:



@uref{https://www.microsoft.com/typography/otspec/featurelist.htm}



Otherwise LGTM


I like this idea. Most fonts that support at least one OpenType feature
will have it specifically mentioned in its specimen sheet. However,
since not all fonts have a specimen sheet, I think it's good to
reference the full list so the user knows what options are even
available.

https://codereview.appspot.com/328140043/

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

Re: True Hand-engraved Dashed Slurs

[tisimst]

On Wed, Jun 28, 2017 at 8:14 AM, Carl Sorensen-3 [via Lilypond] <
ml+s1069038n204180...@n5.nabble.com> wrote:

> On 6/27/17 9:00 PM, "lilypond-devel on behalf of Carl Sorensen"
>   on behalf of
> [hidden email] >
> wrote:
>
> >>
> >>Thoughts? You may be tempted to think that I'm being too nit-picky and
> >>maybe I am, but I think the PS dashed curve looks better due to its
> >>consistency. I've attached a PDF that shows all three kinds of dashed
> >>slurs, the current default, the better one using Slur Overrides, and the
> >>ideal one with PS code.
>
> I can see that the uniform dashing is better.  I am not in favor of moving
> to the PS code for LilyPond, however, because we have more backends than
> just PS (in particular, we have SVG).
>

Agreed. Hence, my bringing this up.

>
> >The slur made with your slur overrides is clearly defective. I'm not sure
> >why. I will investigate.
> >
> >If you go to high magnification you will see that some dash ends are
> >concave and some are convex.  That should never happen.
>
> I could not replicate the problem your pdf had with broken segments.  I
> don't know if it was just a case of my viewer, or not.
>
> But the issue of non-uniform t along the length of the bezier curve is a
> legitimate issue.  I am looking into it to see if there are any readily
> available solutions.
>

Well, t is numerically uniform. It's the transformation from t to x and y
coordinates that makes the segments non-uniform in length. It's not all
that complicated to estimate t-values that provide more equally sized
segments, it's just more calculations. The most basic algorithm is the
following:

1. Discretize the curve into N equal time segments (say 100).
2. Approximate the length of each real curve segment as if it were linear
from one time position to the next.
3. Now, given the desired segment dash length (which may be calculated
based on dash-fraction and dash-period), add up segments (or use linear
interpolation) until you've gone far enough along time and note the
t-values for that segment.
4. Repeat (or just continue from the last stopping point) for each segment
to get all the t-values that provide more-or-less geometrically equidistant
points along the curve.

There are numerous ways of optimizing this "walk" along the curve, but I
think you get the idea. The economics of this algorithm would need to be
vetted, but calculating the t-values for a single curve is quite fast.


> This is an example of something that one would hope to benefit from if
> LilyPond were to go to Cairo.
>

Like David, I'm not sure that using or not using Cairo is relevant for
general use (i.e., for both tapered and monolinear dashed curves).

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/True-Hand-engraved-Dashed-Slurs-tp204138p204185.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: True Hand-engraved Dashed Slurs

[tisimst]

On Tue, Jun 27, 2017 at 3:20 PM, Kieren MacMillan [via Lilypond] <
ml+s1069038n20417...@n5.nabble.com> wrote:

> Hi all,
>
> >> Take my vote for having it as the default.
> > Excellent! At least that makes two of us ;-) (and Kieren, I believe).
>
> Yes.
>

Cool!

One thing I just noticed, upon closer inspection of using plain old Slur
overrides is that the dashes near the tips of the slurs or shorter than
those near the middle. This occurs because the stencil pieces are
parameterized with the time variable "t" internally. In other words,
because most slurs are longer horizontally than they are tall, the
progression of the time variable moves more slowly near the tips, resulting
in shorter segments there and more quickly in the middle, resulting in
longer segments there. I completely understand why it is parameterized this
way, but I'm not sure I like the output so much. Even the current default
dashed slurs suffer from this.

I'm now wondering (since it looks a little odd to me to have visibly
shorter segments on the ends than in the middle), if there's an economical
way to create the stencil so each segment has a more consistent length? If
you compare the PS dashed curves and the dashed slurs with my latest
settings, you will see that the PS curve is much better at making the
segments more equal in length.

Thoughts? You may be tempted to think that I'm being too nit-picky and
maybe I am, but I think the PS dashed curve looks better due to its
consistency. I've attached a PDF that shows all three kinds of dashed
slurs, the current default, the better one using Slur Overrides, and the
ideal one with PS code.

- Abraham


old-style-dashed-slur.pdf (106K) 





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/True-Hand-engraved-Dashed-Slurs-tp204138p204177.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: True Hand-engraved Dashed Slurs

[tisimst]

On Tue, Jun 27, 2017 at 2:31 PM, Simon Albrecht-2 [via Lilypond] <
ml+s1069038n204170...@n5.nabble.com> wrote:

> On 27.06.2017 22:15, tisimst wrote:
> > How often are these split slurs used?
> > I personally have never had a reason to use them, but I guess they must
> be
> > used somewhere.
>
> They’re used in scientific editions e.g. if a slur is begun before the
> line break, but not continued after in the source.
>

Ah! I see now. Thanks!


> > Any reason this set of settings shouldn't be the default
> > for \slurDashed? Or maybe a new one with a old-style reference could be
> > added to property-init.ly? The Barenreiter dashed slurs are (almost)
> > perfectly matched with the following settings (for an ideal dash length
> of
> > 0.28 and gap of 0.2):
>
> Take my vote for having it as the default.
>

Excellent! At least that makes two of us ;-) (and Kieren, I believe).

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/True-Hand-engraved-Dashed-Slurs-tp204138p204171.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: True Hand-engraved Dashed Slurs

[tisimst]

On Tue, Jun 27, 2017 at 8:38 AM, Carl Sorensen-3 [via Lilypond] <
ml+s1069038n204157...@n5.nabble.com> wrote:

> On 6/26/17 4:53 PM, "lilypond-devel on behalf of Abraham Lee"
>   on behalf of
> [hidden email] >
> wrote:
>
> >Greetings, Devs!
> >
> >I have always wondered why dashed slurs look the way they do, especially
> >when compared to the Barenreiter snippets found in the essay. The current
> >dashes look better than they used to, but I still think they look a bit
> >odd
> >compared to the fairly uniform thickness of the hand-engraved Barenreiter
> >ones. Is there any historical reason they don't look that way? I'd be
> >curious to know if there is because I very much like the look of the
> >hand-engraved dashed slurs over the current LP dashed slurs.
>
> I think I'm to blame for the current slur dash code.  I think it is as it
> is because it makes half-dashed slurs look much better.
>

Ah, yes! That very much makes sense. How often are these split slurs used?
I personally have never had a reason to use them, but I guess they must be
used somewhere.


> >
> >In any case, I'm wondering what the right way to go about changing them
> to
> >look more like the Barenreiter ones is. I've cobbled together some PS
> code
> >that takes the Tie/Slur/PhrasingSlur control points and then generates a
> >separate stencil using those, but with a single dashed curve. This seems
> >to
> >work just fine, but I'm wondering if there's a better internal way of
> >getting the same dashed curve without resorting to pure PS code?
>
>
> It's very simple.  Just set the 'thickness property of the slur to 0; the
> 'thickness property of the slur defines the amount of expansion between
> the ends and middle of the slur.  The 'line-thickness property sets the
> thickness at the ends of the slur.
>
> \score{
>   {
> \slurDashPattern #0.7 #0.75
> c'4( e' g'2)
> \once \override Slur.thickness=0
> c'4( e' g'2)
>
> }}
>

Thanks for that! Oddly enough, David's comments also made me realize that
these settings were what I was after, particularly setting thickness=0. So,
thank you both! Any reason this set of settings shouldn't be the default
for \slurDashed? Or maybe a new one with a old-style reference could be
added to property-init.ly? The Barenreiter dashed slurs are (almost)
perfectly matched with the following settings (for an ideal dash length of
0.28 and gap of 0.2):

%%
% desired stencil (real dimensions):
%  - t, dash thickness = .16
%  - d, dash length = .28
%  - g, gap between dashes = .20
% therefore,
%  - line-thickness = t/(staff-line-thickness of 0.1) = 1.6
%  - dash-period = d+g = 0.48
%  - dash-fraction = (d-t)/(d+g) = (0.12)/(0.48) = 0.25

oldSlurDashed = {
  \override Slur.thickness = 0
  \override Slur.line-thickness = 1.6
  \override Slur.dash-definition = #((0 1 0.25 0.48))
}

%%

Thanks, again!
- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/True-Hand-engraved-Dashed-Slurs-tp204138p204167.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Micro release feature list

[tisimst]

On Mon, Jun 26, 2017 at 1:52 PM, Federico Bruni-2 [via Lilypond] <
ml+s1069038n204131...@n5.nabble.com> wrote:

> Il giorno lun 26 giu 2017 alle 21:46, kieren_macmillan kieren_macmillan
> <[hidden email] >
> ha scritto:
> > I look for "Fixed__2_19_x" in the issue tracker.
>
> Another way is entering the lilypond-git directory and then launch gitk
> (or similar GUI tools, like gitg), where you'll see the tags associated
> with releases. But in this "list" of commits you'll see also commits
> from translators (usually starting with doc-xx or web-xx).
>

Thank you both. I'll take a look at those suggestions and come back if I
have further questions.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Micro-release-feature-list-tp204126p204137.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: I'm to teach LilyPond officially again

[tisimst]

Hi, Francisco!

On Sun, Jun 18, 2017 at 10:05 AM, Francisco Vila [via Lilypond] <
ml+s1069038n20391...@n5.nabble.com> wrote:

> Hello all,
>
> Some time ago I was teaching LilyPond in a Conservatoire, then stopped
> doing so, now I'm doing it again! The course is October to June and it's
> optional and open to all four levels of High Music Education.
>
> I'm delighted because I was already missing giving lectures to groups. I
> plan to keep all as practice-oriented as possible with a minimum of
> theoretical issues beyond what's strictly necessary to understand some
> issues.
>
> I have plenty of teaching material, including my 30 weekly lessons plus
> lesson zero.
>
> "Lesson Zero" is {}{}~~~  in a Spanish keyboard, I think
> once achieved that, all else is easy :-)
>
> I'll use Frescobaldi, lilybin, OLy for OOo, and more. Students will also
> learn to enter LP music in wikipedia.
>
> Any suggestions are welcome.
>

Congrats! That's very exciting news. How well has this course been
received/attended? Do the students feel like they come out of it having
learned something useful?

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/I-m-to-teach-LilyPond-officially-again-tp203916p203924.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #1388 Support OpenType font features

[tisimst]

On Thu, May 18, 2017 at 2:34 PM, Xavier Scheuer [via Lilypond] <
ml+s1069038n203182...@n5.nabble.com> wrote:

> On 18 May 2017 at 07:35, Auto mailings of changes to Lily Issues <
> [hidden email] >
> wrote:
> >
> > Initial work to support opentype font features
> >
> > Following up on an old patch I send to the list. One comment was to use
> a
> list
> > for combining multiple font features. This is now implemented. A
> possible
> issue
> > is the pango API needed is somewhat newer. I'll investigate where I need
> to set
> > that in an update (pointers and hints welcome).
> >
> > http://codereview.appspot.com/323850043
>
> Wow!
>

Wow, indeed! This is great news!


> True small caps and old-style numbers coming into Lilypond, this is
> (again) one of my most-wanted features!
>
> How/where do we find the list of font-features? I guess these "terms"
> ("smcp", "onum") are related to Pango and/or OpenType. Or are these
> specific for each font?
>

They are general OpenType glyph categories (i.e., subtables), but the font
designers are the ones who determine whether a font has them or not. So,
trying to use the small-caps glyphs via "smcp" will only work if there are
real small-caps glyphs identified in that subtable. The same is true for
all other subtables.


> For example which term should we use respectively for tabular numbers,
> superior numbers, stylistic alternates, etc.?
>

Here's hoping! This would be brilliant!


> Thank you Jay, you are adding nice and useful features to lily!
>

I'll add my thanks to that. Looking forward to it, Jay!

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Re-Lilypond-auto-LilyIssues-auto-testlilyissues-issues-1388-Support-OpenType-font-features-tp203182p203185.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 3:34 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n200802...@n5.nabble.com> wrote:

> Of course it is good to have optical sizes - even if the vast majority
> of LilyPond users may not even be aware of it. And it's not depending on
> the number of different sizes in a score but already on a single staff
> size. If you want to engrave a pocket score requiring very small staves
> it's obviously better to have optical sizes that aren't simply scaled
> down.
> So we should definitely use the optical sizes equally when font handling
> is done by SMuFL, but (as you say) should be prepared that more or less
> any other font won't have it. (None of your fonts have it, Abraham,
> isn't it?).


At the moment, that's correct. I'm hoping to change this sometime this
year, though, time permitting. The root of this idea though is, how to
handle fonts that only have a single size and those that have multiple
sizes?




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200805.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 2:34 PM, Noeck [via Lilypond] <
ml-node+s1069038n200797...@n5.nabble.com> wrote:

> 1. Nathan was coding this, I just included this into oll and wrote the
> post.


Correct.


> 2. I guess it still works.
>

Yep. Mostly without problems, but it does have its limitations.


> 3. IIUC, this was just a set of overrides and callback functions picking
> up the correct symbols from a smufl font, doing the mapping by glyph
> name. So pretty much all you could do without touching lilypond directly.
> I guess for the GSoC the approach would be quite different and I hope
> Abraham can point into the right direction.
>

Personally, I think there's not much more that can be done with what is
already in OLL, but I don't think that's what we want done anyway. Full
SMuFL integration would be a more substantial improvement, IMHO.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200799.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 1:42 AM, ul [via Lilypond] <
ml-node+s1069038n200762...@n5.nabble.com> wrote:

>
>
> Am 06.03.2017 um 07:44 schrieb Werner LEMBERG:
> >>> Not yet :-)  I can only second what Urs said.
> >> I think we (i.e. Abraham and you) should give Matthew some more
> >> concrete pointers on where to start investigating.
> > Can you send him our e-mail conversation regarding this topic?
> > Currently, I'm abroad, not having time to do that by myself.
>
> I'll see what is there - probably it's at least partially in German.
>
> >
> >>> BTW, where are the current instructions to install a font compliant
> >>> to the SMuFL layout?
> >> What context are you talking about here?
> > This context:
> >
> >   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
> >
> > I don't know whether this is still up to date.
>
> Oh, me neither.
> Joram?
>

While I think this background info is helpful, I don't believe it's really
relevant beyond seeing which SMuFL glyphs are being substituted for the
LilyPond ones.

Here's what I see needing to happen to make SMuFL _really_ work with
LilyPond:

1. Full revamp of LilyPond's glyph naming scheme so it coincides with SMuFL
glyph names. The Metafont files would need to be adjusted for this.
2. Refactor LilyPond's glyph metadata subtables into the external SMuFL
font metadata file (thankfully there are many similarities here...)
3. Refactoring everywhere a glyph or the embedded metadata (LILY, LILC,
LILF subtables) is called (thankfully, they are all called by name and not
code point so they're easy to search for) to use the SMuFL glyph names.
4. Provide a mechanism to load a _single_ 3rd-party font file since I think
most SMuFL font designers will not take the effort to create optically
sized ones like Emmentaler. Now, SMuFL does include a dedicated set of
codepoints for the case where the user has a smaller staff next to the
normal sized one so the smaller staff's glyphs _are_ optically sized, but
no application that I know of (including Dorico) utilizes this at yet. It's
not a bad approach since an engraver isn't likely to have more than two
staff sizes in the same score, but I'm not sure it's the _right_ approach.
I like LilyPond's idea of this better.
5. (Optional) Create the "_Text.otf" version of the font files. They are
intended to make including music glyphs in text easier, but I don't see any
reason LilyPond would need to create these files.

>> For LilyPond there *are* of course no such instructions yet, and
> >> otherwise you can install them like regular fonts, it's then up to
> >> the notation application to properly use it.
> > Well, yes.  But music fonts are handled specially in lilypond...
>

They are, but SMuFL is similar enough that it should be a fairly
straightforward transition. I have to believe that Daniel Spreadbury
borrowed a lot of ideas from the LilyPond handles fonts. The nice thing
about SMuFL is that there are dedicated locations on all operating systems
(Mac, Win, Linux) where the files are expected to be located, as explained
in the SMuFL gitbook[1], so there should be no problem pointing to them.
SMuFL fonts are installed in the system font folder just like any normal
text font.

Those are just some thoughts to keep the conversation going.

Best,
Abraham

[1] https://w3c.github.io/smufl/gitbook/




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200794.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: A kick from history...

[tisimst]

On Mon, Feb 27, 2017 at 8:10 AM, David Kastrup [via Lilypond] <
ml-node+s1069038n20054...@n5.nabble.com> wrote:

>
> I suddenly remembered that I should have entered some Dowland previously
> and dug around on my disk, finding this:
>
>
> \title{I Saw My Lady Weep}
> \composer{John Dowland}
> \meter{C2}
> \duration{2}
> \key\D
> { 'fis1 'd1 b1 } { 'fis 'd1 b1 } 'g\stemup |
> { 'g4 'cis1 a1 } 'fis4\stemup 'fis\stemup { 'fis4 b1 g1 } [^ 'e8 'd8 ]
> 'e\stemup |
> { 'fis1 'cis1 b4.\headright\stemup fis1 } { b8\stemup } { ais4 } {
> b4\stemup } { 'fis1 'cis1 ais4\headright\stemup fis\stemdown } { b2\stemup
> } { fis2\stemdown } { ais4\stemup } |
> { 'fis 'd b1 fis1 B. } { 'fis\stemup 'd } { B4\stemdown } { 'fis2 'cis1
> Ais1 } { 'e\stemup } { 'd b fis\stemup B.\stemdown } { 'd\stemup b } {
> B4\stemdown } { 'cis b\stemup fis.\stemdown } { 'fis\stemup 'cis } {
> fis4\stemdown } { 'fis\stemup b.\stemdown g1\headleft } { 'e\stemup } {
> 'cis4 } |
> { 'a.\stemup 'd\stemdown\headleft fis1 } { 'cis(v } { 'a4\stemup } { 'g
> )'cis4\stemdown\headleft e\stemdown } { b4 } { 'fis\stemup b\stemdown(v d }
> |
> { 'e.\stemup )b4\headleft\stemdown cis1 } { b4 } { ais2\stemdown } {
> 'fis4\stemup } { 'g b1 B.\stemdown } { 'fis\stemup } { B4\stemdown } |
> { 'fis 'cis\stemup fis.\stemdown } { 'a(^ 'fis 'cis\stemup } {
> fis4\stemdown } { )'a b1 g1 } { 'g\stemup(^ } { )'g 'cis a1 } { 'fis\stemup
> 'd } { 'a. 'e.\stemup a\stemdown } { A\stemdown } { 'e4\stemup } { 'fis
> 'd\stemup a\stemdown d } { 'd4\stemup p } { 'e4\stemup } |
> { 'fis4 'd1 a1 d } { 'g4\stemup } { 'a4 d } { 'fis4\stemup } { 'g4 b. g.
> G4 } [^ { 'fis8 A4\stemdown } 'e8 ] { 'd4\stemup B4\stemdown } { 'e4\stemup
> cis4\stemdown } |
> { 'fis 'd a\stemup d.\stemdown } { 'fis\stemup 'd } { d4\stemdown } { 'e
> a\stemup cis\stemdown } { 'fis 'cis fis } |
> { 'fis b dis } { 'e b gis } { 'gis 'cis eis } { 'fis 'cis ais fis } { 'fis
> 'd b1 fis1 B. } { 'fis\stemup 'd } { B4\stemdown } { 'e\stemup g1
> e.\stemdown } { 'e\stemup b } { d4\stemdown } { p2\stemup c1 } { 'e\stemup(
> } [^ { )'e8 fis1 B. } 'e8 'dis8 'cis8 ] { 'dis\stemup } { B4\stemdown } |
> { 'e1 b1 e1 } p { 'eis\stemup gis\stemdown cis } { 'eis. gis1 cis1 } {
> 'e4\stemup } { 'd\stemup fis.\stemdown } { 'cis\stemup(^ } { e4\stemdown }
> |
> { )'cis4 d1 } { 'cis4\stemup } { b\stemup } { 'cis1\stemno
> fis\headright\stemup cis.\stemdown } { eis } { cis4\stemdown } |
> { 'cis1 ais1 fis1 } { 'fis 'cis fis } { 'dis b fis B } |
> { 'e1 gis2 e1\headright } { a2\stemdown( } { 'fis.\stemup
> )a4\headleft\stemdown dis\stemdown } { a4\stemdown } { gis\stemdown e } {
> 'e4\stemup } |
> { p4\stemup ais\stemdown fis1\headright } { 'd\stemup } { b\stemdown } {
> 'e4\stemup } { 'fis. 'cis1 b\headleft\stemdown fis1 } { ais\stemdown } {
> 'e4\stemup } |
> { 'g b1 B1 } { 'fis4\stemup } { 'b\stemup } { fis\stemdown } { 'a4\stemup
> } { 'e4\stemup cis4\stemdown } { 'fis4.\stemup 'd\stemdown a d\stemdown } {
> 'g8\stemup } { 'a4 'cis4\stemup A4\stemdown } [^ { 'g8 B(v } 'fis8 ] {
> 'd4\stemup } |
> { b )B4 } { B4\stemdown } { 'cis\stemup A\stemdown } { 'd4. b G1 } {
> 'd8\stemup } { 'e 'cis4 } { b4 } |
> { 'fis. 'cis1 ais1 fis1 cis1 Fis1 } { 'fis4\stemup } { 'fis1 'cis1 ais1
> fis1 cis1 Fis1 } |||
>

I like the clarity of LP's input syntax verbosity, but am I ever glad I'm
not forced to be _that_ verbose!

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/A-kick-from-history-tp200545p200546.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Arrow-glyphs in Feta (was: \arrow markup command)

[tisimst]

Hi, Simon!

On Tue, Dec 27, 2016 at 9:11 AM, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n198583...@n5.nabble.com> wrote:

> On 23.12.2016 22:34, Simon Albrecht wrote:
> > Why does the Feta font have one glyph for each of the 4 directions in
> > which an arrow head generated with \arrow-head can point? Why not
> > simply rotate one glyph in the first place? (I’m sure the Metafont
> > code does just that, though it would strike me more logical to do it
> > on a ‘higher’ level.)
>
> Can anyone comment on this Feta question?


Here's what I could tell from looking at the source code. The function
first creates one barb of the arrow, then mirrors it vertically to create
the full arrowhead. Without any other transformations, this creates the
right-pointing arrowhead. Each of the other glyphs follow the same steps to
this point, and then transforms the glyph, either by negative scaling or by
rotation, to get the others. This applies for both open and closed
arrowheads.

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/arrow-markup-command-tp198440p198587.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[tisimst]

On Wed, Dec 21, 2016 at 5:22 AM, Alexander Kobel-2 [via Lilypond] <
ml-node+s1069038n198284...@n5.nabble.com> wrote:

> On 2016-12-20 17:21, Abraham Lee wrote:
> > Yes, thanks for making this possible! It will be a great addition.
>
> Thanks Abraham.
>
> > One question I have about having the two properties is how will the two
> be
> > reconciled in actual use? In other words, if collapse-length is larger
> than
> > forced-length, will there still be the same amount of space between
> > syllables even without the extender (to the amount of forced-length)?
>
> One thing remains identical to the current situation: Extenders never
> ever influence horizontal spacing.
>
> > Maybe the question I really have is this: what does "given this length
> _if
> > possible_" mean and what governs this possibility? I can totally
> understand
> > how they work individually, I'm just trying to understand how I can use
> > them well together since it seems that forced-length contradicts
> > collapse-length.
>
> You won't really use them together; at least, not both will be effective
> at the same time:
> (1) If the natural length (essentially: the distance from the right end
> of the syllable to the right end of the last note in the corresponding
> melisma) is less than collapse-length, this extender will not be printed.
> (2) If you /force/ an extender, that is, you explicitly add one for a
> syllable that does not belong to a melisma, there is no "natural length"
> - simply because there is no "natural extender". The "faked" length of
> such an extender will be given by the minimum of forced-length and the
> available space to the next syllable. Again, this will not affect the
> space between the notes.
>
> Forced extenders should only be necessary under extraordinary
> circumstances, such as an extender reaching into a alternative ending of
> a repeat, re-extending after rests, or even more obscure design studies.
>

Ah! I understand now. Thank you for explaining that. So, it's "Force an
extender to appear if there is sufficient space (i.e., at least as much as
"collapse-length"), even in places they wouldn't normally be used." Is that
right? If so, then I think "forced-length" is not the right name for it.
Perhaps just "force" or "force-all"? Or is forced appearance not subject to
"collapse-length"?

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/music-function-to-be-included-somewhere-in-scm-tp197960p198288.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: home page: add examples/images, reduce news to headlines (issue 306350043 by paulwmor...@gmail.com)

[tisimst]

On Tue, Sep 6, 2016 at 9:52 AM, paulwmorris [via Lilypond] <
ml-node+s1069038n194266...@n5.nabble.com> wrote:

> Patch set 3 uploaded, with just one example image on the home page and a
> list of links to the other examples on the examples page.  I like how
> this gets an image of sheet music onto the home page and helps
> communicate the wide range of LilyPond's use cases.
>
> Screenshot:
> https://drive.google.com/open?id=0ByNTIEA63_a_ZzMtNTFiZHFqN2c
>
> The news links and examples links now link directly to their individual
> news item or example.  I realized that the anchor tags () already
> exist in the generated HTML for headings, so it's just a matter of using
> them.
>

+1*1000!! I already like it sooo much better. Thank you, Paul, for
working on this! Even without the slide-show, this is an excellent change.
Great work!

--
Abraham Lee




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Web-home-page-add-examples-images-reduce-news-to-headlines-issue-306350043-by-paulwmorris-gmail-com-tp194068p194267.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: About issue 4931 make \deadNote work with different fonts

[tisimst]

On Sunday, September 4, 2016, Federico Bruni-2 [via Lilypond] <
ml-node+s1069038n19420...@n5.nabble.com> wrote:

> Il giorno mar 26 lug 2016 alle 18:27, tisimst
> <[hidden email] <http:///user/SendEmail.jtp?type=node=194200=0>>
> ha scritto:
> > Just for the record (and maybe this is the wrong place to record it),
> > I
> > thought I'd clarify some confusion in the thread referred to in the
> > above
> > issue.
>
> >
> > 1. There is no "Feta" font. It's called "Emmentaler", but it consists
> > of
> > two sub-sets of glyphs: "Feta" (the classical notation glyphs) and
> > "Parmesan" (the ancient notation glyphs).
> >
> > 2. Since Emmentaler comes in 8 different optical sizes, the commands
> > to
> > load them only require the root name "emmentaler" to load them all.
> >
> > 3. The fonts are located, not in the system's font directory(s), but
> > in the
> > program's own font folder, typically
> > "[LilyPondDir]/usr/share/lilypond/current/fonts/".
> >
> > 4. To use Emmentaler (or whichever is the main font, if using an
> > alternative) for a grob that supports the font-interface, it can be
> > set via
> > the 'font-family property, but the value isn't 'emmentaler, it's 'feta
> > (sigh). It's a shorter name, which is nice, but it isn't _technically_
> > accurate.
> >
> > 5. In a \markup, the fonts can be accessed directly with the real font
> > name, like "emmentaler-23".
> >
> > 6. In the NR, section A.8 is entitled "The Feta font", but the
> > opening line
> > starts out with "The following symbols are available in the Emmentaler
> > font..."
> >
> > In other words, there's some inconsistency floating around.
>
> We discussed this almost an year ago :)
> http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00594.html
>
> Finally I'll take action and add an issue on the tracker:
> https://sourceforge.net/p/testlilyissues/issues/4966/
>

Thank you, Federico, for adding this!

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/About-issue-4931-make-deadNote-work-with-different-fonts-tp193110p194202.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: home page: add examples/images, reduce news to headlines (issue 306350043 by paulwmor...@gmail.com)

[tisimst]

On Wed, Aug 31, 2016 at 9:40 AM, Paul Morris [via Lilypond] <
ml-node+s1069038n194102...@n5.nabble.com> wrote:

> On 08/30/2016 06:05 PM, [hidden email]
>  wrote:
>
> > I'm not comfortable with the really long, scrolling, home page.
>
> Ok, given these concerns that Carl and David raised, let me think some
> more and see what I can come up with.
>
> Maybe just a single example, followed by a list of the other kinds of
> examples, to show the range of what LilyPond can do, with a link to the
> full example page.  (This is another place where @anchor would come in
> handy -- we could link the list items directly to the examples,
> "Tablature" to the tablature example etc.)
>
> Later, if we wanted, we could turn that single example into a CSS slider
> / slide show type thing where the user could click through some of the
> examples in-place on the home page, as Federico suggests.
>

I'll just toss this in (again) as a graphic mockup I think supports this
idea. See attached. Ideally, I would think it helpful to have a list of
genres near the top of the examples that, when clicked, would make just the
one image show up at a time without making the page refresh. It's just a
starting point for ideas.

Best,
Abraham


lilypond-website-mockup.png (391K) 





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Web-home-page-add-examples-images-reduce-news-to-headlines-issue-306350043-by-paulwmorris-gmail-com-tp194068p194104.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: repeating bar numbers and rehearsal marks in frenched score

[tisimst]

Mark, et al,

On Thu, Jul 28, 2016 at 1:36 PM, Mark Knoop-4 [via Lilypond] <
ml-node+s1069038n193214...@n5.nabble.com> wrote:

> At 21:03 on 28 Jul 2016, David Kastrup wrote:
>
> >Mark Knoop <[hidden email]
> > writes:
> >> I'm also unclear as to why you feel that this is unsuitable to be
> >> done by the Keep_alive_together_engraver without further nesting.
> >> After all, the documentation for this engraver states:
> >>
> >> These spanners are then tied together so that one will be removed
> >> only if all are removed.
> >
> >Your use case desired to have staves removed without consideration of
> >whether the mark line is removed, and have the mark line removed only
> >if all staves are removed.
>
> How is this so conceptually dissimilar to the divisi-staves situation
> which introduced the remove-layer property?
>
> Staves are already removeable without consideration of other contexts
> by setting remove-layer = ##f. The only change is that a specified
> context can be retained throughout the normal life of the group.
>
> I'm sorry, I am trying to progress this and respond to your
> suggestions, but it would be nice to receive some proper criticism of
> my (working) code which amounts to more than just "I don't like it".
>

Forgive me if this is the wrong place to ask this question, but can the new
code handle nested situations?

For example, let's say we have four horns. These may appear on their own
staff, they may appear on a combined staff (e.g., "Horns 1 & 2"), and they
may appear on a single staff together. The divisi-staves example works
wonderfully for a single parent-child situation, but using the
'keepAliveInterfaces as the trigger doesn't seem to allow you to have more
nested levels. Here's a complete compiling example. I tried to extend the
divisi-staves code to allow for this multi-level nesting, but all
permutations failed for me. Here's one example:

%

\version "2.19.13"

\header {
  texidoc = "The @code{VerticalAxisGroup.remove-layer}
property can be used for typesetting temporary divisi staves where
the switch to split staves is done only at line breaks such that all
complex passages are rendered in separate staves."
}

boring = \set Staff.keepAliveInterfaces = #'()
tricky = \unset Staff.keepAliveInterfaces

violI=\relative c'' {
  \boring \repeat unfold 50 c4
  \tricky 2
  \boring \repeat unfold 48 c4
  \tricky 2
  \boring \repeat unfold 98 c4
  \bar "|."
}

violII=\relative g' {
  \boring \repeat unfold 100 g4
  \tricky 2
  \boring \repeat unfold 98 g4
  \bar "|."
}

violIII=\relative e' {
  \boring \repeat unfold 100 e4
  \tricky 2
  \boring \repeat unfold 48 e4
  \tricky 2
  \boring \repeat unfold 48 e4
  \bar "|."
}

violIV=\relative c' {
  \boring \repeat unfold 100 c4
  \tricky 2
  \boring \repeat unfold 98 c4
  \bar "|."
}

\score {
  \new StaffGroup \with {
\consists "Keep_alive_together_engraver"
  } <<
\new StaffGroup \with {
  \consists "Keep_alive_together_engraver"
  \override VerticalAxisGroup.remove-layer = 1
  \remove System_start_delimiter_engraver
} <<
\new Staff \with {
  instrumentName = "Violin I"
  shortInstrumentName = "V I"
  \override VerticalAxisGroup.remove-empty = ##t
  \override VerticalAxisGroup.remove-first = ##t
  \override VerticalAxisGroup.remove-layer = 1
} \violI
\new Staff \with {
  instrumentName = "Violin II"
  shortInstrumentName = "V II"
  \override VerticalAxisGroup.remove-empty = ##t
  \override VerticalAxisGroup.remove-first = ##t
  \override VerticalAxisGroup.remove-layer = 1
} \violII
\new Staff \with {
  instrumentName = "Violins I"
  shortInstrumentName = "V I"
  \override VerticalAxisGroup.remove-layer = 2
} << \violI \\ \violII  >>
>>
\new StaffGroup \with {
  \consists "Keep_alive_together_engraver"
  \override VerticalAxisGroup.remove-layer = 1
  \remove System_start_delimiter_engraver
} <<
\new Staff \with {
  instrumentName = "Violin III"
  shortInstrumentName = "V III"
  \override VerticalAxisGroup.remove-empty = ##t
  \override VerticalAxisGroup.remove-first = ##t
  \override VerticalAxisGroup.remove-layer = 1
} \violIII
\new Staff \with {
  instrumentName = "Violin IV"
  shortInstrumentName = "V IV"
  \override VerticalAxisGroup.remove-empty = ##t
  \override VerticalAxisGroup.remove-first = ##t
  \override VerticalAxisGroup.remove-layer = 1
} \violIV
\new Staff \with {
  instrumentName = "Violins III"
  shortInstrumentName = "V III"
  \override VerticalAxisGroup.remove-layer = 2
} << \violIII \\ \violIV  >>
>>
\new Staff \with {
  instrumentName = "Violins"
  shortInstrumentName = "V I-IV"
  

Re: About issue 4931 make \deadNote work with different fonts

[tisimst]

On Tue, Jul 26, 2016 at 9:06 AM, Thomas Morley-2 [via Lilypond] <
ml-node+s1069038n193110...@n5.nabble.com> wrote:

> I had a look at
> https://sourceforge.net/p/testlilyissues/issues/4931/
> ...
>

Just for the record (and maybe this is the wrong place to record it), I
thought I'd clarify some confusion in the thread referred to in the above
issue.

1. There is no "Feta" font. It's called "Emmentaler", but it consists of
two sub-sets of glyphs: "Feta" (the classical notation glyphs) and
"Parmesan" (the ancient notation glyphs).

2. Since Emmentaler comes in 8 different optical sizes, the commands to
load them only require the root name "emmentaler" to load them all.

3. The fonts are located, not in the system's font directory(s), but in the
program's own font folder, typically
"[LilyPondDir]/usr/share/lilypond/current/fonts/".

4. To use Emmentaler (or whichever is the main font, if using an
alternative) for a grob that supports the font-interface, it can be set via
the 'font-family property, but the value isn't 'emmentaler, it's 'feta
(sigh). It's a shorter name, which is nice, but it isn't _technically_
accurate.

5. In a \markup, the fonts can be accessed directly with the real font
name, like "emmentaler-23".

6. In the NR, section A.8 is entitled "The Feta font", but the opening line
starts out with "The following symbols are available in the Emmentaler
font..."

In other words, there's some inconsistency floating around.

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/About-issue-4931-make-deadNote-work-with-different-fonts-tp193110p193116.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Leave of absence

[tisimst]

On Mon, Jul 11, 2016 at 2:05 AM, Thomas Morley-2 [via Lilypond] <
ml-node+s1069038n192541...@n5.nabble.com> wrote:

> Hi all,
>
> I'll be on vacations for the next two weeks, doing camping in Normandie.
> Thus completely without net-access.
>
> Cheers,
>   Harm
>

A well-deserved vacation. Enjoy living off the grid! Thanks for all you do,
Harm.

--
Abraham Lee




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Leave-of-absence-tp192541p192559.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: What to do with input/regression/page-spacing.ly

[tisimst]

On Thu, Jun 23, 2016 at 2:55 AM, Thomas Morley-2 [via Lilypond] <
ml-node+s1069038n19184...@n5.nabble.com> wrote:

> X-offset and Y-offset are working more like 'extra-offset.
>

They do, but extra-offset is based on the default X-offset and Y-offset
values. Setting Y-offset here is based on the page's zero-reference (the
bottom of the top allowable location). Likewise for X-offset (from the
left-side). So, why not make Y-offset behave like it does for every other
grob (i.e., it influences the vertical spacing of other staves/systems
around it) and add the extra-offset property such that it behaves like it
does for every other grob (i.e., it moves the staff/system, but doesn't
influence the spacing of any other staff/system)?

Another idea. What if, when calculating the vertical-skyline, setting the
Y-offset value could vertically offset the skyline up or down making the
system/staff seem bigger or smaller to the spacing algorithms than it
actually is? I guess that's more like changing Y-extent, but maybe there
could be a convenient way to do that? 'extra-Y-extent maybe? It could take
a pair where the car is the lower side and the cdr is the upper side? Just
some thoughts.

I think it's desireable to get (at least some of) the old
> possibilities working again, so that the interplay of manually
> tweaking the automatic behaviour works nicely.
> No idea how hard it would be to reimplement this, though.
>

+1!

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/What-to-do-with-input-regression-page-spacing-ly-tp191822p191860.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: fontforge-problem?

[tisimst]

Thomas,

On Tue, May 31, 2016 at 2:09 PM, Thomas Morley-2 [via Lilypond] <
ml-node+s1069038n191273...@n5.nabble.com> wrote:

> I usually don't pay much attention to the log of simple `make`, but
> after our present doc-problems I took a closer look and noticed two
> instances of `Internal Error` here one of it:
>
>
> Invoking "t1asm parmesan-noteheads20.pt1 parmesan-noteheads20.pfb"...
>
> Invoking "/usr/bin/fontforge -script parmesan-noteheads20.pe
> parmesan-noteheads20.pfb"...
> Copyright (c) 2000-2012 by George Williams.
>  Executable based on sources from 14:57 GMT 31-Jul-2012-ML.
>  Library based on sources from 14:57 GMT 31-Jul-2012.
> Internal Error (overlap) in noteheads.uM3neomensural: Mismatched
> intersection.
>  (669,462,430,017)->(650,002,178,75) ends at (-99,-99) while
> (650,002,178,75)->(617,499,179,724) starts at (650,002,178,75)
> Internal Error (overlap) in noteheads.uM3neomensural: monotonic is
> both needed and unneeded (630,541,427,486)->(650,821,448,141).
> x=650,001 (prev=624,031)
> Internal Error (overlap) in noteheads.uM3neomensural: Winding number
> did not return to 0 when x=650,001
> Internal Error (overlap) in noteheads.uM3neomensural: monotonic is
> both needed and unneeded (630,541,427,486)->(650,821,448,141).
> x=650,001 (prev=624,031)
> Internal Error (overlap) in noteheads.uM3neomensural: Winding number
> did not return to 0 when x=650,001
> Internal Error (overlap) in noteheads.uM3neomensural: monotonic is
> both needed and unneeded (630,541,427,486)->(650,821,448,141).
> x=650,001 (prev=624,031)
> Internal Error (overlap) in noteheads.uM3neomensural: Winding number
> did not return to 0 when x=650,001
> Internal Error (overlap) in noteheads.uM2neomensural: Mismatched
> intersection.
>  (519,46,430,017)->(500,178,75) ends at (-99,-99) while
> (500,178,75)->(467,497,179,724) starts at (500,178,75)
> Internal Error (overlap) in noteheads.uM2neomensural: monotonic is
> both needed and unneeded (480,539,427,486)->(500,819,448,141).
> x=499,999 (prev=474,029)
> Internal Error (overlap) in noteheads.uM2neomensural: Winding number
> did not return to 0 when x=499,999
> Internal Error (overlap) in noteheads.uM2neomensural: monotonic is
> both needed and unneeded (480,539,427,486)->(500,819,448,141).
> x=499,999 (prev=474,029)
> Internal Error (overlap) in noteheads.uM2neomensural: Winding number
> did not return to 0 when x=499,999
> Internal Error (overlap) in noteheads.uM2neomensural: monotonic is
> both needed and unneeded (480,539,427,486)->(500,819,448,141).
> x=499,999 (prev=474,029)
> Internal Error (overlap) in noteheads.uM2neomensural: Winding number
> did not return to 0 when x=499,999
> Internal Error (overlap) in noteheads.urM3neomensural: Mismatched
> intersection.
>  (669,462,430,016)->(650,002,178,75) ends at (-99,-99) while
> (650,002,178,75)->(617,499,179,724) starts at (650,002,178,75)
> Internal Error (overlap) in noteheads.urM3neomensural: monotonic is
> both needed and unneeded (630,541,427,486)->(650,821,448,14).
> x=650,001 (prev=624,031)
> Internal Error (overlap) in noteheads.urM3neomensural: Winding number
> did not return to 0 when x=650,001
> Internal Error (overlap) in noteheads.urM3neomensural: monotonic is
> both needed and unneeded (630,541,427,486)->(650,821,448,14).
> x=650,001 (prev=624,031)
> Internal Error (overlap) in noteheads.urM3neomensural: Winding number
> did not return to 0 when x=650,001
> Internal Error (overlap) in noteheads.urM3neomensural: monotonic is
> both needed and unneeded (630,541,427,486)->(650,821,448,14).
> x=650,001 (prev=624,031)
> Internal Error (overlap) in noteheads.urM3neomensural: Winding number
> did not return to 0 when x=650,001
> Internal Error (overlap) in noteheads.urM2neomensural: Mismatched
> intersection.
>  (519,46,430,016)->(500,178,75) ends at (-99,-99) while
> (500,178,75)->(467,497,179,724) starts at (500,178,75)
> Internal Error (overlap) in noteheads.urM2neomensural: monotonic is
> both needed and unneeded (480,539,427,486)->(500,819,448,14).
> x=499,999 (prev=474,029)
> Internal Error (overlap) in noteheads.urM2neomensural: Winding number
> did not return to 0 when x=499,999
> Internal Error (overlap) in noteheads.urM2neomensural: monotonic is
> both needed and unneeded (480,539,427,486)->(500,819,448,14).
> x=499,999 (prev=474,029)
> Internal Error (overlap) in noteheads.urM2neomensural: Winding number
> did not return to 0 when x=499,999
> Internal Error (overlap) in noteheads.urM2neomensural: monotonic is
> both needed and unneeded (480,539,427,486)->(500,819,448,14).
> x=499,999 (prev=474,029)
> Internal Error (overlap) in noteheads.urM2neomensural: Winding number
> did not return to 0 when x=499,999
>
> *** Successfully generated parmesan-noteheads20.pfb! ***
>
>
>
> No idea, if this is a real problem, just wanted to let you know.
>

My experience is that this occurs when there are more than two overlapping
shapes. It doesn't necessarily mean a problem with 

Re: Tie properties vs. slur properties.

[tisimst]

On Thu, May 26, 2016 at 12:50 AM, David Kastrup [via Lilypond] <
ml-node+s1069038n190980...@n5.nabble.com> wrote:

> tisimst <[hidden email]
> <http:///user/SendEmail.jtp?type=node=190980=0>> writes:
>
> > On Wed, May 25, 2016 at 12:19 AM, Werner LEMBERG [via Lilypond] <
> > [hidden email] <http:///user/SendEmail.jtp?type=node=190980=1>>
> wrote:
> >
> >>
> >> > The tie interface has height-limit and ratio as part of Tie.details.
> >> >
> >> > The slur interface has height-limit and ratio as part of Slur (not
> >> > embedded in Slur.details).
> >> >
> >> > Is there a reason for this difference, or is it just due to never
> >> > making the two be consistent?
> >>
> >> I believe it's the latter.
> >>
> >> > If there is no reason for the difference, I think the two should be
> >> > rationalized, probably by moving Slur.height-limit and Slur.ratio to
> >> > Slur.details.height-limit and Slur.details.ratio.
> >>
> >> This looks ok.
> >>
> >
> > What's the benefit of nesting properties like this?
>
> You don't need to list them individually in an interface.  You can
> override the whole set of details with one command without needing to
> specifically clear properties that are usually never set, but the user
> and/or some containing context may have set them to special values.
>
> If you need to access them as a set anyway, it's faster to get them once
> and go from there.
>
> There may be properties in some "details" that are named identically to
> properties in some other "details" or at top level.
>
> That's what I can currently think of.
>
> I'm not particularly enamored with the details either, but if you take a
> look at stuff like the harp diagram details, they are really a long long
> list.  Overriding all of them individually is effort.
>

Ah, yes. That makes sense. Thank you for making it possible to do both
Grob.details.property and Grob.details = #'((property . ...))

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Tie-properties-vs-slur-properties-tp190944p191003.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Tie properties vs. slur properties.

[tisimst]

On Wed, May 25, 2016 at 12:19 AM, Werner LEMBERG [via Lilypond] <
ml-node+s1069038n19094...@n5.nabble.com> wrote:

>
> > The tie interface has height-limit and ratio as part of Tie.details.
> >
> > The slur interface has height-limit and ratio as part of Slur (not
> > embedded in Slur.details).
> >
> > Is there a reason for this difference, or is it just due to never
> > making the two be consistent?
>
> I believe it's the latter.
>
> > If there is no reason for the difference, I think the two should be
> > rationalized, probably by moving Slur.height-limit and Slur.ratio to
> > Slur.details.height-limit and Slur.details.ratio.
>
> This looks ok.
>

What's the benefit of nesting properties like this? I'm open to hearing
arguments for it, but why not have them all accessible at top-level? Is it
programmatically beneficial to have some properties in the "details" alist?
I would argue that it would be more user-friendly if the user didn't need
to know when to do "Grob.property" vs "Grob.details.property" sometimes.
I'd vote for making all properties accessible like "Grob.property" if
that's possible.

Just my thoughts. Thanks to everyone who are making these properties easier
to access!

- Abraham

P.S. While we're talking properties, is there anyone who'd be willing to
make the trill spanner squiggle "~" externally \override-able independent
of the trill text "tr"?




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Tie-properties-vs-slur-properties-tp190944p190976.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Leave of absence / lookahead

[tisimst]

David,

On Mon, Apr 4, 2016 at 1:37 PM, David Kastrup [via Lilypond] <
ml-node+s1069038n189285...@n5.nabble.com> wrote:

> tisimst <[hidden email]
> <http:///user/SendEmail.jtp?type=node=189285=0>> writes:
>
> > Have a fantastic vacation (and take some awesome pictures to share with
> > us!),
>
> This one looks almost as tricky as getting rid of parser conflicts.
> It's at the Placca dell'Oasi, called Grigio Perla and turns out to be a
> rather skimpy 6a+.  Which does not sound all that impressive but is
> pretty close to my limit (if I remember correctly, I am traversing to
> slightly deeper dents in the rock on the right here).  There are still
> about 20m missing, but it gets somewhat easier later.  I think that the
> very top of the image shows the next bolt to clip (this is "free
> climbing" so you only use the rope and bolts for protection, not for
> progress).
>

I'm a total novice when it comes to rock-climbing, but that looks
impressive! Thanks for sharing!

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Leave-of-absence-lookahead-tp189057p189293.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Leave of absence / lookahead

[tisimst]

On Mon, Mar 28, 2016 at 2:04 AM, David Kastrup [via Lilypond] <
ml-node+s1069038n189057...@n5.nabble.com> wrote:

>
> Hi folks,
>
> I've been on my yearly vacation (climbing in Italy for 10 days) since
> last Thursday and so I've been a lot less responsive and particularly
> productive the last day.  While I do check the messages and try
> providing answers morning and evening, I don't actually have the focus
> and time to do significant productive work.
>
> Sorry for that.
>

What do you think you're doing?! Just kidding. On the contrary, I bet I'm
not the only one who might be even a little upset that you aren't
completely "vacating"! ;-) Take a break! Enjoy the mountains! Everything
and all of us will still be here when you return. You deserve a mental
break! Go have fun. We better not see you responding to any more emails
until after next Sunday, at least!

There are also decisions to tackle with regard to my future with
> LilyPond as leeching off fellow developers is becoming unsustainable.
> My previous largest sponsor has decided to call it quits on account of a
> drop in productivity with regard to commits to LilyPond and I can't
> blame him for that: the return in value I provided for his own
> contribution was certainly fluctuating more than his large investment
> warranted.
>
> On the other hand, I think I still provide enough money to warrant
> minimum levels of living, so I need to check out how to coordinate the
> possibility of lots of small payments.  I'll likely try to make use of
> FSF channels of funding which has the disadvantage that they take 10%
> flat for their own funding.  It will enable donation buttons, donation
> by credit card, tax deductible donations in the U.S.
>
> Of course, this will require agreement of other developers to actually
> go ahead with a scheme that will mostly benefit, given the current
> situation, a single person on behalf of the project.  We currently also
> see the need for funding with regard to fonts, and there are also
> infrastructure needs currently carried by project members which might
> warrant funding.  And having a system administrator for making our issue
> tracking free and maintaining it would also be nice.
>
> So even if it turns out that total funding or the wishes of other
> developers don't make it feasible to let me continue on the project, it
> does not seem like we'd soon get into the situation where there would be
> more funding available than we could sensibly make use of.  So I don't
> think we would need to backpedal with regard to donation buttons and
> other gushing sources of money in case I left.
>

David, you are extremely kind to mention my situation here. I'll be the
first to say it, though, that what you do is WAY more important than what I
am doing. If anything, we ought to set YOU up a Patreon/Gratipay/whatever
account that can be an on-going contribution. Seems like that would be
easier for lots of people, helping in a small way, can help you in a bigger
way.


> LilyPond would not be where it is without the bunch of dedicated workers
> continually answering questions, providing improvement, writing
> documentation, improving what is there, providing translations, managing
> issue reports and testing and so on and so on.  If this level of
> dedication and support would have been there from the start, maybe our
> core code base would be somewhat more transparent and documented and
> versatile: the continuing efforts (and failures) to make the best of the
> existing state provide a strong driving source for developers to make
> things easier to access and use, and to cater for more use cases and
> provide the tools for making this easier.
>
> Thanks to everyone
>

Thank YOU, David. You have made so many things easier. I know you aren't
the only one working on this great program, there are many people who
faithfully put in countless hours to improve it. Either way, I think I
speak for everyone by saying I am grateful for what you do. If you had not
been in the picture, I'm sure the program wouldn't be nearly as good as it
is today.

Have a fantastic vacation (and take some awesome pictures to share with
us!),
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Leave-of-absence-lookahead-tp189057p189063.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [Feature Request] Make LSR #888 the default for calculating X-offset of lyrics with punctuation

[tisimst]

Harm,

On Wed, Mar 23, 2016 at 1:51 PM, Thomas Morley-2 [via Lilypond] <
ml-node+s1069038n188879...@n5.nabble.com> wrote:

> 2016-03-23 19:56 GMT+01:00 Abraham Lee <[hidden email]
> >:
>
> > Dev Team,
> >
> > I really appreciate LSR #888: Center Lyric Syllables (ignoring
> > punctuation). Since most of what I engrave has lyrics, I can't think of
> any
> > reason why I wouldn't want this to be on all the time. Is it possible
> that
> > such a situation exists where I wouldn't want the punctuation to be
> > ignored? Perhaps, but I'd dare say they are much less likely.
> >
> > Not sure how much more work would be needed to incorporate it
> officially,
> > but I'm wondering if this can be considered for inclusion into the core
> > code.
> >
> > Thanks!
> >
> > - Abraham
>
>
>
> Hi Abraham,
>
> there are at least two recent threads where
> http://lsr.di.unimi.it/LSR/Item?id=888
> and problems with it are discussed:
>
> http://lilypond.1069038.n5.nabble.com/align-on-syllable-ly-and-2-19-36-td187874.html
>
> http://lilypond.1069038.n5.nabble.com/LyricText-center-on-word-breaks-lyricMelismaAlignment-td183456.html
>
> Apart from the problems which happen while aligning to Voice vs
> NullVoice this snippet creates a bunch of stencils, just to compare
> their extents and then throws them away.
> I don't think we want such code in the source.
> Otoh, it may be worth to think about a better approach for that feature...
>

Thanks for bringing me up to speed with the current state of its exclusion.
I will continue to use it on its own until something breaks ;-)

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Feature-Request-Make-LSR-888-the-default-for-calculating-X-offset-of-lyrics-with-punctuation-tp188877p10.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [Feature Request] Align lyrics to middle of font 'x-height' instead of baseline

[tisimst]

Simon,

On Wed, Mar 23, 2016 at 11:41 AM, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n188875...@n5.nabble.com> wrote:

> On 23.03.2016 18:14, Abraham Lee wrote:
> > Dev Team,
> >
> > I was wondering if you have any insight concerning the possibility
> > of/complications with changing the default Y-offset of LyricText to
> > be aligned on vertical center of the font's x-height. The Dynamics
> > characters do something similar already (roughly aligned on the vertical
> > center of Emmentaler's "m" glyph[1]), so why not lyrics? Seems like this
> > would bring a visual improvement over the current Y-offset of zero
> (i.e.,
> > the font's baseline).
> […]
> > I guess this might only be helpful when you want the lyrics to be
> > vertically centered between two staves (like in a hymnal)
>

Thanks for your comments.


> Why would anybody want that? The lyrics should be placed between the
> skylines of the neighbouring lines, and I don’t see the point of any
> exact v-centering.
>

I can count quite a few times where I have wanted this, not only with
hymnal-like music either. I can't imagine I'm the only one, but maybe I am.
This usually comes up when I want to center some lyrics between to
PianoStaff staves. The normal centering puts the baseline equidistant
between the staves, but there's an obviously larger amount of white-space
below the lyrics than above. I understand the need to for taking skylines
into account, but doesn't the Dynamics context do this, too?


> If anything, Y-offset would be relevant for alignment with other items
> on or next to the lyrics line. I don’t know how alignment with
> LyricHyphen and LyricExtender is currently handled, and how that would
> play with your suggestion; the only other item I can think of now is
> StanzaNumber – which should of course normally have the same baseline as
> the LyricText.
>

Agreed. Those would need to be considered, too.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Feature-Request-Align-lyrics-to-middle-of-font-x-height-instead-of-baseline-tp188874p188876.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to update an LSR snippet (Was: Use a straight tick (single straight quote) for a breath mark)

[tisimst]

On Monday, March 21, 2016, Thomas Morley-2 [via Lilypond] <
ml-node+s1069038n188782...@n5.nabble.com> wrote:

> 2016-03-21 23:10 GMT+01:00 tisimst <[hidden email]
> <http:///user/SendEmail.jtp?type=node=188782=0>>:
>
> >>> > On Mar 21, 2016, at 1:52 PM, Abraham Lee <[hidden email]
> >>> <http:///user/SendEmail.jtp?type=node=188772=0>> wrote:
> >>> >
> >>> > There's a lot about that snippet (LSR #195, and I imagine others)
> that
> >>> I
> >>> > think could really use an update/clean-up. I am wondering what the
> >>> "policy"
> >>> > is for updating existing snippets that I didn't create, if any? I've
> >>> got an
> >>> > LSR account already, so I'm happy to dive in and do it, but I can't
> >>> seem to
> >>> > change much as I'm not the original author).
> >>> >
> >>> > Thanks,
> >>> > Abraham
> >>>
> >>
> > Submitted for review: http://lsr.di.unimi.it/LSR/Item?id=1030
> >
> > Best,
> > Abraham
>
> Snippets exchanged, old one deleted.
>
> Thanks,
>   Harm
>

Thank _you_!
- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-update-an-LSR-snippet-Was-Use-a-straight-tick-single-straight-quote-for-a-breath-mark-tp188770p188783.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to update an LSR snippet (Was: Use a straight tick (single straight quote) for a breath mark)

[tisimst]

On Mon, Mar 21, 2016 at 3:13 PM, Abraham Lee 
wrote:

> Paul,
>
> On Mon, Mar 21, 2016 at 11:59 AM, Paul Morris [via Lilypond] <
> ml-node+s1069038n188772...@n5.nabble.com> wrote:
>
>> Hi Abraham,
>>
>> See: http://lsr.di.unimi.it/LSR/html/contributing.html
>>
>> Namely:
>>
>> Suggesting modifications or improvements to existing snippets
>>
>> You can only edit your own snippets. However, suggestions can be posted
>> as a whole new snippet: for example, if you want to correct some errors in
>> a snippet named “Adding simple notes”, just copy it and post a new snippet
>> with the title: “Adding simple notes [corrected]”. This way, the LSR editor
>> who will review your snippet will be able to replace the former one with
>> yours, and remove the text between brackets.
>>
>> -Paul
>>
>>
> Ah, yes. Thank you for re-pointing that out to me. I had read through the
> contributing page, but forgot that part. I'll proceed that way.
>
> Best,
> Abraham
>
>
>>
>> > On Mar 21, 2016, at 1:52 PM, Abraham Lee <[hidden email]
>> > wrote:
>> >
>> > There's a lot about that snippet (LSR #195, and I imagine others) that
>> I
>> > think could really use an update/clean-up. I am wondering what the
>> "policy"
>> > is for updating existing snippets that I didn't create, if any? I've
>> got an
>> > LSR account already, so I'm happy to dive in and do it, but I can't
>> seem to
>> > change much as I'm not the original author).
>> >
>> > Thanks,
>> > Abraham
>>
>
Submitted for review: http://lsr.di.unimi.it/LSR/Item?id=1030

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-update-an-LSR-snippet-Was-Use-a-straight-tick-single-straight-quote-for-a-breath-mark-tp188770p188781.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to update an LSR snippet (Was: Use a straight tick (single straight quote) for a breath mark)

[tisimst]

Paul,

On Mon, Mar 21, 2016 at 11:59 AM, Paul Morris [via Lilypond] <
ml-node+s1069038n188772...@n5.nabble.com> wrote:

> Hi Abraham,
>
> See: http://lsr.di.unimi.it/LSR/html/contributing.html
>
> Namely:
>
> Suggesting modifications or improvements to existing snippets
>
> You can only edit your own snippets. However, suggestions can be posted as
> a whole new snippet: for example, if you want to correct some errors in a
> snippet named “Adding simple notes”, just copy it and post a new snippet
> with the title: “Adding simple notes [corrected]”. This way, the LSR editor
> who will review your snippet will be able to replace the former one with
> yours, and remove the text between brackets.
>
> -Paul
>
>
Ah, yes. Thank you for re-pointing that out to me. I had read through the
contributing page, but forgot that part. I'll proceed that way.

Best,
Abraham


>
> > On Mar 21, 2016, at 1:52 PM, Abraham Lee <[hidden email]
> > wrote:
> >
> > There's a lot about that snippet (LSR #195, and I imagine others) that I
> > think could really use an update/clean-up. I am wondering what the
> "policy"
> > is for updating existing snippets that I didn't create, if any? I've got
> an
> > LSR account already, so I'm happy to dive in and do it, but I can't seem
> to
> > change much as I'm not the original author).
> >
> > Thanks,
> > Abraham
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-update-an-LSR-snippet-Was-Use-a-straight-tick-single-straight-quote-for-a-breath-mark-tp188770p188780.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lose the tagline (permanently)

[tisimst]

On Fri, Mar 4, 2016 at 3:07 PM, Noeck [via Lilypond] <
ml-node+s1069038n188094...@n5.nabble.com> wrote:

> >> I'm fine with making it classier rather than flashy.  But removing it
> is
> >> not doing us a favor.
> >>
> >
> > Even though I don't love having print by default, there are times when I
> do
> > leave it and having it classier is a wonderful idea.
>
> Classier sounds good. My proposal stands [1]:
> LilyPond 2.XY – lilypond.org
> Not because I insist on this version but to narrow the discussion a bit
> to actual proposals – "classier" is a quite wide range ;)
>

How about

Engraved with LilyPond X.Y---lilypond.org


I know it's not much shorter than

Music engraving by LilyPond X.Y---www.lilypond.org


but it is more concise and direct to the point of the default tagline is to
show _what_ did the engraving and not necessarily _who_.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Lose-the-tagline-permanently-tp187587p188095.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: OT: Using built-in ghostscript by itself

[tisimst]

Thank you, Sharon! That second link gave me enough clues to figure it out.

Best,
Abraham

On Thu, Mar 3, 2016 at 4:47 PM, Sharon Rosner [via Lilypond] <
ml-node+s1069038n188027...@n5.nabble.com> wrote:

> > I couldn't figure it out. When I call [LP_dir]/usr/bin/gs.exe I get the
> > error that it can't find gs_init.ps which is located in
> > [LP_dir]/usr/share/ghostscript/9.15/Resource/Init/. How do I tell gs.exe
> > where to find its files? Am I even using the right command?
>
> Possible answer here:
>
>   http://stackoverflow.com/a/12876349
>
> The GS man page:
>
>   http://linux.die.net/man/1/gs
>
> Sharon
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/OT-Using-built-in-ghostscript-by-itself-tp188026p188027.html
> To start a new topic under Dev, email
> ml-node+s1069038n88644...@n5.nabble.com
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/OT-Using-built-in-ghostscript-by-itself-tp188026p188079.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lose the tagline (permanently)

[tisimst]

On Tue, Feb 23, 2016 at 9:23 AM, Pierre-Luc Gauthier [via Lilypond] <
ml-node+s1069038n187606...@n5.nabble.com> wrote:

> Might I add,
>
> LilyPond is a rather exotic alternative compared to most other commercial
> project.
> The project as a whole needs visibility to gain recognition.
> Could this default tag be seen as a survival feature for the project?
>
> I am trying to show (or just explain) my LilyPond/Git/LaTeX workflow to my
> friends who are fully into music writing; they just don't see it worth the
> trouble.
> But when they see the quality of the result, they are thrown away. I
> explicitly want them to know that it was LilyPond made.
>
> As for LilyPond users that do not care, I strongly suggest that it be
> tagged as a LilyPond made score by default.
>
> Back when LilyPond was just an possible alternative in the back of my
> mind,
> while wandering through the web, I started paying attention at that tag at
> the bottom.
> The more I saw that tag, the more I realized that LilyPond could indeed
> used and therefore be usable by most anybody.
>
> My extremely non technology savvy mother knows about LibreOffice.
> Most of my professional music colleagues have never even heard of
> LilyPond.
> I think it is an issue.
>
> My default bottom tag I use is quite extensive but in the context in which
> I work demands an extremely clear version of a given arrangement as it
> changes for week to week.
>
> I happen to think that this default tag line in a bit too much though.
>
> ​I do think that just "LilyPond 2.19.36" with the link inside it is quite
> enough information to give to someone actually interested in how this
> music
> was written.
> ​
> At one extreme I think that cocky advertisement obviously does not have
> its
> place in a FOSS project, and on the other, I think that LilyPond needs the
> visibility.
> But then again, in all my project I \include "../myLilypondSlippers.ily"
> and I am good to go with a tag line I actually want to use.
>
> Thanks for the conversation.
>

Thanks for sharing, Pierre. That's a great insight.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Lose-the-tagline-permanently-tp187587p187607.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LilyPond as a service

[tisimst]

On Wed, Feb 17, 2016 at 2:51 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n187406...@n5.nabble.com> wrote:

> I'm sorry but I don't get this.
> Urs
>
>
> Am 17.02.2016 um 22:48 schrieb Abraham Lee:
>
> > This sounds a lot like lilybin.com 
>

You know what, I probably jumped the gun a little. lilybin.com does do LaaS
(LilyPond as a Service), but not quite in the way you were describing.
Sorry for the noise.




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LilyPond-as-a-service-tp187403p187407.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc section name change proposition

[tisimst]

On Wed, Feb 17, 2016 at 10:17 AM, Phil Holmes-2 [via Lilypond] <
ml-node+s1069038n18738...@n5.nabble.com> wrote:

> - Original Message -
> From: "Abraham Lee" <[hidden email]
> >
> To: "LilyPond Development Team" <[hidden email]
> >
> Sent: Wednesday, February 17, 2016 4:35 PM
> Subject: Doc section name change proposition
>
>
> > Docs Team,
> >
> > I noticed this a while back, but I thought I might as well bring it up.
> > Subsubsection 4.5.2  in NR is called "New spacing area", but the command
> > it
> > introduces is called "\newSpacingSection". In favor of not changing the
> > command name, can we rename the section to match the command? In other
> > words, I am wondering if anyone is against changing the section name to
> > "New spacing section"?
> >
> > On the other hand, is it conceivable that \newSpacingSection should be
> > renamed instead? I have no problem with that either.
> >
> > Thanks everyone!
> > - Abraham
>
>
> To me, calling the section of the documents "New spacing section" sounds
> better English.
>

Sounds just fine to me, too.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Doc-section-name-change-proposition-tp187377p187396.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: hyphen syntax

[tisimst]

On Wed, Feb 17, 2016 at 10:16 AM, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n187386...@n5.nabble.com> wrote:

> On 17.02.2016 18:02, tisimst wrote:
> > I've always wondered why the
> > LyricHyphen doesn't actually use the hyphen from the LyricText font
> rather
> > than a dashed line. I realize that doing that would reduce the
> > customizability of the dash (i.e., length, thickness, dash-period,
> etc.),
> > but it might it immediately look more homogeneous regardless of the font
> > used because they are designed to match each other. Not a big deal, just
> > curious.
>
> And I should like if there were an option to take these hyphens from a
> text font, since in some fonts/music engraving styles they are slanted
> or wavy (like ~) and it would be great to have a means of doing that.
>

That's exactly what I meant, if that wasn't clear.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/hyphen-syntax-tp187210p187389.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: hyphen syntax

[tisimst]

On Wed, Feb 17, 2016 at 9:54 AM, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n187380...@n5.nabble.com> wrote:

> On 17.02.2016 15:58, David Kastrup wrote:
>
> > Dan Eble<[hidden email]
> >  writes:
> >
> >>> >>On Feb 17, 2016, at 05:18 , Jean-Charles Malahieude<[hidden email]
> >  wrote:
> >>> >>
> >>> >>Le 14/02/2016 20:41, Dan Eble a écrit :
>  >>>Are there technical limitations that require typing a double
> hyphen
>  >>>to hyphenate lyrics?  Why not just one?
>  >>>
> >>> >>
> >>> >>Technically, I don't know. But, in terms of coherence, I would leave
> >>> >>it as it is:
> >>> >>
> >>> >>one hyphen is treated as one syllable, just like one underscore
> >>> >>"skips" one (group of) note
> >> >
> >> >But is it useful for a bare hyphen to be treated as a syllable?  I
> >> >don’t recall having seen any examples of that.
> > It is rather common for skipping syllables in multiple stanzas since an
> > isolated - is equivalent to " ".
>
> It’s an isolated _ (underscore) you mean. A dash is indeed treated as a
> syllable.
> I think _if_ we wanted to use - instead of --, we’d have to do the same
> kind of change for lyric extenders, else it would be inconsistent. And I
> think the double items suit the advanced functionality better (advanced
> in comparison to printing a hyphen character from a font).
>

Funny you should mention that because I've always wondered why the
LyricHyphen doesn't actually use the hyphen from the LyricText font rather
than a dashed line. I realize that doing that would reduce the
customizability of the dash (i.e., length, thickness, dash-period, etc.),
but it might it immediately look more homogeneous regardless of the font
used because they are designed to match each other. Not a big deal, just
curious.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/hyphen-syntax-tp187210p187381.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: doc: nice music examples removed?

[tisimst]

Bob,

Not sure why they've been removed, but it appears that there's a new page
that shows some new examples as well as some of those found in the site you
mentioned (source code not included):

http://lilypond.org/examples.html

HTH,
Abraham

On Tuesday, January 26, 2016, Bob Bib [via Lilypond] <
ml-node+s1069038n186510...@n5.nabble.com> wrote:

> Hi developers,
>
> in the past versions, some really nice pieces of music were included in
> the docs (e. g., J. S. Bach, E. Satie, F. Schubert):
> http://lilypond.org/doc/v2.12/examples
>
> In the current version (2.18), I can't find them.
> Have those music pieces been removed from the manuals (and why)?
>
> --
> Best wishes,
> Bob
>
> ___
> lilypond-devel mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/doc-nice-music-examples-removed-tp186510.html
> To start a new topic under Dev, email
> ml-node+s1069038n88644...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/doc-nice-music-examples-removed-tp186510p186520.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Typo about LilyDev image size

[tisimst]

On Sat, Nov 21, 2015 at 11:31 AM, pls [via Lilypond] <
ml-node+s1069038n183909...@n5.nabble.com> wrote:

> Abraham Lee <[hidden email]
> > writes:
>
> > Documentation Writers,
> >
> > I was just reading through the 2.19.31 contributors "Quick Start" guide
> > (Section 2.1) and it says this:
> >
> > *"The LilyDev disk image can also be written to a USB device or ‘burnt’
> to
> > a DVD – it is approximately 900 GB in size – and installed just like any
> > standard GNU/Linux distribution."*
> >
> > Now, I don't know about anyone else, but I don't think I've ever seen a
> > Linux distribution that required 900 GB ;-) I'm pretty sure it should
> say
> > "900 *M*B" instead.
>
> Yes, I already corrected this in a patch about to be uploaded for a
> review.
>
> Thanks,
> Patrick
>

Great! Thanks, Patrick!

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Typo-about-LilyDev-image-size-tp183907p183910.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Planning a MEI-to-LilyPond project

[tisimst]

Count me in as a developer if there's room. Work is slow for me at the
moment and I would enjoy working on the project.

Best,
Abraham

On Monday, October 19, 2015, Urs Liska [via Lilypond] <
ml-node+s1069038n182481...@n5.nabble.com> wrote:

> Dear developers,
>
> most of you will know or at least have noticed that I have thought about
> integrating LilyPond and the XML based MEI format. If not you might
> consider reading my current post on http://lilypondblog.org for an
> introduction. Today I would like to make kind of an announcement and
> call for discussion.
>
> Chances are pretty good that there will be a publicly funded development
> project with the goal of integrating LilyPond and MEI or - in a somewhat
> grander context - integrating professional music engraving in current
> digital music edition concepts. The project is intended to be hosted at
> the institute for music informatics at the music university in
> Karlsruhe/Germany and the ZenMEM (http://zenmen.de), a Digital
> Humanities institute founded for coordinating German research on digital
> music edition. The ZenMEM will also submit the application to the DFG
> (German Research Union). The actual scope and scale of the project
> application will have to be considered carefully but we start discussion
> with a three year project with two full positions. If we can make it
> plausible there might be the option to add some portions to commission
> individual development tasks externally.
> So while we still have to write an application and hope for its
> acceptance it is at least clear that the application *will* happen and
> there are reasons to consider it a promising application.
>
> I think this is a huge opportunity to bring LilyPond forward. First this
> will bring us a whole new range of users and use cases, maybe even to a
> point where a general audience will take notice of LilyPond on a
> different level. Second this potential new user base (the academic music
> edition community) can be expected to contribute back to LilyPond, in
> short and on the long run. And finally this project would mean
> significant amounts of money (= development capacity) thrown at us, and
> one can assume a significant share of that going into LilyPond
> development itself, and a significant share of *that* part benefitting
> LilyPond users in general, without considering the MEI/Digital Edition
> part.
>
> The task at hand is to produce the application which starts with
> outlining the development tasks, starting with ideas and wishes but
> pinning them down as concretely as possible. We intend to submit the
> application by the end of the year and have a meeting where people from
> the MEI and the LilyPond developer communities get together and outline
> possible tasks, with special consideration of the obstacles to overcome
> because of some conceptual incompatibilities.
>
> The actual discussion should take place on another, dedicated list, and
> I'll post to that about the outline as it currently stands. But I want
> to invite anyone from here to participate in that discussion as it's
> presumably an important and hopefully fruitful one for LilyPond. If
> you're interested in it please get in touch with me (if you aren't
> already).
>
> Best
> Urs
>
> ___
> lilypond-devel mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Planning-a-MEI-to-LilyPond-project-tp182481.html
> To start a new topic under Dev, email
> ml-node+s1069038n88644...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Planning-a-MEI-to-LilyPond-project-tp182481p182482.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: SVG output problems - TexGyre vs Century Schoolbook - not embedding fonts

[tisimst]

TeXGyreSchola, IIRC.

- Abraham

On Monday, September 14, 2015, pkx-2 [via Lilypond] <
ml-node+s1069038n181113...@n5.nabble.com> wrote:

> Hosada-san
>
> On 13/09/15 23:00, Masamichi HOSODA wrote:
>
> >>> In my experiment, by LilyPond 2.19.22 (before changing fonts to TeX
> Gyre),
> >>> SVG output is not embeded text fonts.
> >>> So I think that SVG backend does not embed any text fonts
> >>> independently of font changing to TeX Gyre.
> >>>
> >> Did you use the downloadable binary or from git directly?
> >>
> >> Also it does say in the instructions that the Century Schoolbook OTF
> >> files needed to be available (and suggests that a user puts them in
> >> ~/.fonts) did you do this?
> > I use cygwin64's packaged binary.
> > Century Schoolbook L OTFs exist in ~/.fonts.
> > So fc-list can find Century Schoolbook L OTFs.
> >
> >
>
> That is not standard I think.
>
> I have checked on my home and office systems (they are both using
> different distributions of Linux) and I don't have any Schoolbook OTF
> fonts seen by fc-list (or in my .fonts).
>
> I guess I will need to test this. Using an earlier build.
>
> Can you tell me which TexGyre 'font family' specifically replaced
> Century Schoolbook
>
> James
>
> ___
> lilypond-devel mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/SVG-output-problems-TexGyre-vs-Century-Schoolbook-not-embedding-fonts-tp181069p181113.html
> To start a new topic under Dev, email
> ml-node+s1069038n88644...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/SVG-output-problems-TexGyre-vs-Century-Schoolbook-not-embedding-fonts-tp181069p181115.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Authors - Updated authors.itexi (issue 258660043 by p...@gnu.org)

[tisimst]

Thanks, Trevor! I'm honored to be on that list. I think Kieren is on there
twice (not that he probably doesn't deserve it ;-)

- Abraham

On Saturday, September 5, 2015, tdanielsmusic [via Lilypond] <
ml-node+s1069038n180738...@n5.nabble.com> wrote:

>
>
> https://codereview.appspot.com/258660043/diff/1/Documentation/included/authors.itexi
> File Documentation/included/authors.itexi (left):
>
>
> https://codereview.appspot.com/258660043/diff/1/Documentation/included/authors.itexi#oldcode199
> Documentation/included/authors.itexi:199: Abraham Lee
> I think Abraham Lee has contributed to the current unstable release,
> hasn't he?
>
> https://codereview.appspot.com/258660043/
>
> ___
> lilypond-devel mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Authors-Updated-authors-itexi-issue-258660043-by-pkx-gnu-org-tp180738.html
> To start a new topic under Dev, email
> ml-node+s1069038n88644...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Authors-Updated-authors-itexi-issue-258660043-by-pkx-gnu-org-tp180738p180743.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: TextScript automatically italic in Dynamics context

[tisimst]

On 8/26/2015 2:50 PM, Wols Lists [via Lilypond] wrote:
 On 26/08/15 21:42, Abraham Lee wrote:
  Why is that? I see no reason that text in this context *must* be italic
  by default (and I know it can be changed back). Can someone help me
  understand the logic there?
 
 Because, in pretty much every score I know, dynamics text is always 
 italic?

While this is true (and I understand that historically it really was 
from an italic text font), nowadays we don't usually use characters from 
any text font for the most common dynamic text (mp, f, pp, sffz, etc.). 
They usually exist as dedicated glyphs that have no font-shape, italic 
or otherwise. They just are what they are. This \override forces any 
\markup text to automatically default to italic, which is okay, but 
doesn't seem that desirable IMO.

This isn't a huge deal. I was just curious. It looks like its been this 
way from the conception of the Dynamics context.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/TextScript-automatically-italic-in-Dynamics-context-tp180222p180224.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Music glyph design choices

[tisimst]

On 8/9/2015 10:38 PM, Werner LEMBERG [via Lilypond] wrote:
 The same as with the double-flat: we need evidence from real-world
 scores to decide this.

 Do you have time to check this?

A quick scan through IMSLP:

1. (Breikopf  Hartel, 1880) Chopin, Polonaise in B-flat minor: 
Identical flats
2. (Peters, 1895) Grieg, Piano Concerto in A-minor (for piano 4 hands): 
Identical flats
3. (Universal, 1920) Bartok, Studies for Piano, Op. 18: Identical flats

This is in way definitive, but seems like nice evidence for using 
identical flats. I'd be very interested in seeing a score where they 
were intentionally /not/ identical.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Music-glyph-design-choices-tp179329p179437.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Music glyph design choices

[tisimst]

On 8/10/2015 10:57 AM, Phil Holmes-2 [via Lilypond] wrote:
 - Original Message -
 From: tisimst [hidden email] 
 /user/SendEmail.jtp?type=nodenode=179439i=0
 To: [hidden email] /user/SendEmail.jtp?type=nodenode=179439i=1
 Sent: Monday, August 10, 2015 5:32 PM
 Subject: Re: Music glyph design choices

  This is in way definitive, but seems like nice evidence for using
  identical flats. I'd be very interested in seeing a score where they
  were intentionally /not/ identical.


 Looks like this should form an enhancement/bug request.  Do you have the
 skills to fix the font files?

Yes and no. I don't feel super comfortable putting together an official 
.PATCH, but I can definitely post my proposed changes or send updated 
files to anyone who has more experience getting these officially in the 
assembly line. FWIW I took the liberty to play around with the code that 
creates the double flat glyph and here's what I have that we can talk 
about if anyone cares to chime in.

First, the double flat. In the following image, you'll see three glyphs 
in the right. From the top, we see the current glyph, with the left 
flat's width = 0.7 and the right flat's width = 0.8. Next down shows 
what would happen if we averaged the widths of the two flats, which 
keeps the overall width of the glyph the same as the current one. The 
bottom glyph is composed of exact copies of the flat glyph with an 
appropriate overlap, to me at least, based on real scores I've seen. The 
only downside I can see is that it becomes a _little_ wider than the 
other two. Personally, I think this is going to have a minimal spacing 
effect on most scores since its usage isn't nearly as common as the flat is.



Thankfully it's just a matter of setting these variables in the glyph's 
MF code (except for width, which is calculated). The crook value is 
multiplied by staff_space. The flatflat.slash glyph should probably be 
changed to be the same.

BTW, if it isn't obvious from the picture, the overlap variable is how 
much the left flat's right-most bound overlaps the right flat's origin 
(the blue line), so even overlap=0 will have some real overlap because 
the flat glyph's left-most bound isn't at x=0.

Second, changing the prallup and pralldown glyphs according to my 
previous suggestions would also quite easy, if that were agreed upon. 
This is done by simply changing the order of the glyphs in 
feta-trills.mf to be

prallprall
prallmordent
upprall
upmordent
prallup*
downprall
downmordent
pralldown*
lineprall

(* i.e., just swap the prallup and pralldown places) and adding 
currentpicture := currentpicture yscaled -1; at the end of both 
prallup and pralldown definitions, the thick and thin parts of the 
zig-zags are then consistent across all of them. I don't have any 
historical proof to back my proposals for these two glyphs. It just 
seems right to make them consistent with the rest of them.

Those are my thoughts. Any 
thoughts/questions/concerns/rebuttals/snide-remarks?

- Abraham


jagbhabg.png (175K) 
http://lilypond.1069038.n5.nabble.com/attachment/179444/0/jagbhabg.png




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Music-glyph-design-choices-tp179329p179444.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Music glyph design choices

[tisimst]

On Fri, Aug 7, 2015 at 10:03 PM, Werner LEMBERG [via Lilypond] 
ml-node+s1069038n179333...@n5.nabble.com wrote:


  1. accidentals.flatflat: Why is the left flat more compressed than
  the right?  Perhaps if the left were expanded slightly and the right
  were compressed slightly, then the glyph width wouldn't have to
  change, but would look more consistent.

 Hmm.  I don't think this glyph looks inconsistent...


Here's what I meant. In the following image, we see two normal flats
superimposed (in green) on top of the doubleflat glyph (in black). The
stems are matched up to show what I'm referring to as being inconsistent:

[image: Inline image 1]

I hope this makes it more obvious what I'm seeing. The left flat is much
more compressed than the right one in the doubleflat. That's all I'm
saying. It would seem better to me to at least have the the left counter
look more like the right one. Like I said before, I'm not saying it is
inherently wrong (nor the green version right), but it seems like the two
sides to the glyph could look more similar. Maybe I'm the only one who
notices this.


  2. scripts.pralldown, scripts.prallup: The wiggle's thick/thin parts
  are opposite of the other similar glyphs, which seems odd to me.

 I guess all those glyph shapes are based on templates from Bärenreiter
 editions.  Han-Wen?


Well, whatever the reason, in fetatrills.mf, pralldown is the created by
scaling upprall by -X, which certainly does save a bunch of extra code, but
looks funny (and, again, inconsistent to the rest of the trill-like glyphs)
to me. Looks like its a similar story with prallup being a -X of downprall.
At least the code could be changed to be pralldown = rotate(downprall,
180deg) and prallup = rotate(upprall, 180deg). That would keep the
thick/thin lines pointing in the correct direction for each. What say ye?

[image: Inline image 2]

Best,
Abraham


image.png (63K) 
http://lilypond.1069038.n5.nabble.com/attachment/179400/0/image.png
image.png (66K) 
http://lilypond.1069038.n5.nabble.com/attachment/179400/1/image.png




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Music-glyph-design-choices-tp179329p179400.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Music glyph design choices

[tisimst]

On Sunday, August 9, 2015, Phil Holmes-2 [via Lilypond] 
ml-node+s1069038n179401...@n5.nabble.com wrote:

 - Original Message -
 From: tisimst [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=179401i=0
 To: [hidden email] http:///user/SendEmail.jtp?type=nodenode=179401i=1

 Sent: Sunday, August 09, 2015 5:08 PM
 Subject: Re: Music glyph design choices


  On Fri, Aug 7, 2015 at 10:03 PM, Werner LEMBERG [via Lilypond] 
  [hidden email] http:///user/SendEmail.jtp?type=nodenode=179401i=2
 wrote:
 
 
   1. accidentals.flatflat: Why is the left flat more compressed than
   the right?  Perhaps if the left were expanded slightly and the right
   were compressed slightly, then the glyph width wouldn't have to
   change, but would look more consistent.
 
  Hmm.  I don't think this glyph looks inconsistent...
 
 
  Here's what I meant. In the following image, we see two normal flats
  superimposed (in green) on top of the doubleflat glyph (in black). The
  stems are matched up to show what I'm referring to as being
 inconsistent:
 
  [image: Inline image 1]
 
  I hope this makes it more obvious what I'm seeing. The left flat is
 much
  more compressed than the right one in the doubleflat. That's all I'm
  saying. It would seem better to me to at least have the the left counter
  look more like the right one. Like I said before, I'm not saying it is
  inherently wrong (nor the green version right), but it seems like the
  two
  sides to the glyph could look more similar. Maybe I'm the only one who
  notices this.

 I don't have double flat examples from real music, but can show what
 Sibelius, Bravura, and Elaine Gould offer.  These are similar to your
 suggestion.  It would be interesting to try to find some real-world
 examples
 from published scores.

 Gould also says: double flat: two flat signs are placed together and
 (usually) touching.  This also implies they should be similar or the same.


I agree with Gould, but I would follow what she says more than what she
shows in the book since she uses Sibelius' default Opus font for all the
music instead of real engraving punches.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Music-glyph-design-choices-tp179329p179403.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Music glyph design choices

[tisimst]

Dev team, et al,

I have a question that I've been meaning to ask for some time, but just
haven't gotten around to doing. It's about certain glyphs in Emmentaler.
They are general questions about the design decision (which may or may not
lead to any changes). These questions don't necessarily mean I think they
are wrong, I'm just seeking understanding...

1. accidentals.flatflat: Why is the left flat more compressed than the
right? Perhaps if the left were expanded slightly and the right were
compressed slightly, then the glyph width wouldn't have to change, but would
look more consistent.

2. scripts.pralldown, scripts.prallup: The wiggle's thick/thin parts are
opposite of the other similar glyphs, which seems odd to me

I think that's all that appears to be inconsistent with the rest of the
font. Any thoughts are appreciated.

Regards,
Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Music-glyph-design-choices-tp179329.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: Remove old News entry from home page

[tisimst]

Paul, et al,

On Fri, Jul 10, 2015 at 12:49 PM, Paul Morris [via Lilypond] 
ml-node+s1069038n178576...@n5.nabble.com wrote:

  On Jul 9, 2015, at 5:39 AM, James [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=178576i=0 wrote:
 
  Perhaps we can tweak the 'website' slightly (i.e. make small changes to
  the TexInfo code) to perhaps do something like moving some/all of the
  text from here
 
  http://lilypond.org/introduction.html
 
  to the front page/news and jig the menu (?) links around to fit?

 My thinking is that it would be good to move some or all of the examples
 page[1] to the main column of the home page where the news is now.  That
 clearly shows what LilyPond can do, front and center.

 To me the full news listing seems less important to feature so prominently
 on the home page, so one idea would be for the news list to become a list
 of headlines in the home page side bar (possibly made wider) with each
 headline linking to that news entry on a separate news page.  That separate
 news page could just be a slightly revised version of the current old
 news page[2] (i.e. just call it “News”).

 -Paul

 [1] http://lilypond.org/examples.html
 [2] http://lilypond.org/old-news.html


I love this idea! What if, instead of moving all the contents from
.../introduction.html or .../examples.html to the front page, we just
brought over the secondary bar of links:

[image: Inline image 1]

That way visitors can quickly jump to Examples if they want, or
Reviews, or Features, etc.

On the other hand, if these could be set up in a tabbed format so that by
clicking on one its contents would immediately appear below these links
without the user leaving the homepage. I realize this isn't trivial, but it
would be so much more visitor-friendly. Here's an image mock-up of what I'm
thinking of (notice the News link at the top instead of Introduction):

[image: Inline image 3]

Just my 2 cents.

- Abraham


lilypond-website-mockup.png (391K) 
http://lilypond.1069038.n5.nabble.com/attachment/178578/0/lilypond-website-mockup.png
image.png (12K) 
http://lilypond.1069038.n5.nabble.com/attachment/178578/1/image.png




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Re-Remove-old-News-entry-from-home-page-tp178527p178578.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: freetype.cc: solve algebra puzzle for converting quadratics to cubics (issue 252810043 by d...@gnu.org)

[tisimst . lilypond]

The math checks out. LGTM2.

https://codereview.appspot.com/252810043/

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

Re: LilyPond Serif/Sans Serif/Monospace Text Fonts?

[tisimst]

Got it. That's the file data I saw that made me wonder. Makes perfect sense
now!

On Saturday, June 27, 2015, Masamichi Hosoda [via Lilypond] 
ml-node+s1069038n178256...@n5.nabble.com wrote:

  Greetings, Dev Team!
 
  I was just browsing through some of the latest code (in scm/font.scm)
 and I
  noticed that the default text font names are now LilyPond Serif,
 LilyPond
  Sans Serif, and LilyPond Monospace. Do such fonts actually exist or are
  these just place holders? It looks like the fontconfig allows for a
  fallback fonts anyway. It's not a big deal. I was just curious. Looks
 like
  Masamichi Hosoda made these changes.
 
 
 http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=28f58ecc2271956e9377dc61e5135ce3ade4abbd
 
  Thanks for everything you all do to make this program what it is today!
 
  - Abraham

 LilyPond Serif, LilyPond Sans Serif and Lilypond Monospace are aliases
 those are defined by fonts/lilypond-fonts.conf.
 fonts/lilpond-fonts.conf is LilyPond's own fontconfig configure file.
 For example, LilyPond Serif is defined by this file like following:

 ```
   alias binding=strong
 familyLilyPond Serif/family
 prefer
   familyCentury Schoolbook L/family
   familyDejaVu Serif/family
 /prefer
 default
   familyserif/family
 /default
   /alias
 ```

 The charactor that is contained in Century Schoolbook L:
 The glyph of Century Schoolbook is used.

 The charactor that is not contained in Century Schoolbook L,
 but is contained in DejaVu Serif:
 The glyph of DejaVu Serif is used.

 ___
 lilypond-devel mailing list
 [hidden email] http:///user/SendEmail.jtp?type=nodenode=178256i=0
 https://lists.gnu.org/mailman/listinfo/lilypond-devel


 --
  If you reply to this email, your message will be added to the discussion
 below:

 http://lilypond.1069038.n5.nabble.com/LilyPond-Serif-Sans-Serif-Monospace-Text-Fonts-tp178236p178256.html
  To start a new topic under Dev, email
 ml-node+s1069038n88644...@n5.nabble.com
 javascript:_e(%7B%7D,'cvml','ml-node%2bs1069038n88644...@n5.nabble.com');
 To unsubscribe from Lilypond, click here
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=2code=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=
 .
 NAML
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LilyPond-Serif-Sans-Serif-Monospace-Text-Fonts-tp178236p178290.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Compile LilyPond for NaCl

[tisimst]

Although I can't speak to the details of LilyPond's dependencies, it sure
seems possible based on the site's description. This would be really neat,
but you'd obviously need some good server-side support to make it smooth (I
think). This would be a great addition at making an embedded
editor/compiler in the docs so that people can try things out rather than
just read through the examples.

- Abraham

On Tue, May 12, 2015 at 4:50 PM, trevordixon [via Lilypond] 
ml-node+s1069038n176524...@n5.nabble.com wrote:

 Could any useful part of LilyPond be compiled for NaCl
 https://developer.chrome.com/native-client/overview#why-use-native-client?

 Is that at all within the realm of possibility?
 ___
 lilypond-devel mailing list
 [hidden email] http:///user/SendEmail.jtp?type=nodenode=176524i=0
 https://lists.gnu.org/mailman/listinfo/lilypond-devel


 --
  If you reply to this email, your message will be added to the discussion
 below:

 http://lilypond.1069038.n5.nabble.com/Compile-LilyPond-for-NaCl-tp176524.html
  To start a new topic under Dev, email
 ml-node+s1069038n88644...@n5.nabble.com
 To unsubscribe from Lilypond, click here
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=2code=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=
 .
 NAML
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Compile-LilyPond-for-NaCl-tp176524p176525.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [wish] Remove \skip duration in Lyrics

[tisimst]

Trevor,

Thanks for your reply.

On Mon, Apr 27, 2015 at 11:18 AM, Trevor Daniels [via Lilypond] 
ml-node+s1069038n175497...@n5.nabble.com wrote:


 Abraham Lee wrote Monday, April 27, 2015 5:39 PM

  I've seen lately a handful of users using (and suggesting to others) the
  single underscore _ syntax to skip syllables in lyrics instead of
 \skip
  X, which I think is a mistake when it's obvious they did not intend to
  make a melisma. It works, except the lyrics get left-aligned to the
 first
  note.

 Yes.  I've actually not seen many recently, and the manuals advise against
 it,
 for the reason you give.

  I am wondering if anyone has a better suggestion for a pure skipped
  syllable to replace \skip X since the duration X doesn't matter at
 all.
  It's easy enough to create a replacement macro like:

 I usually suggest using  , if just one or two syllables are involved.


This has the same problem with syllable horizontal alignment, I've
discovered, as the single underscore in both 2.18.2 and 2.19.18. Only the
empty string  gives the correct placement of the previous syllable.


  OR, it could use the number to say *how many syllables to skip* instead
 of
  a duration. I'm thinking about the instances where I've seen (and used)
  something like:
 
  skipFour = \repeat unfold 4 { \skip 4 }

 For longer durations I know of no alternative.  What you suggest seems
 sensible in a Lyrics context, but it would break backwards compatibility.
 And it has been suggested before:
 https://code.google.com/p/lilypond/issues/detail?id=1330

 Trevor


This is true, but aren't there lots of things that aren't backward
compatible? This isn't urgent, but it seems like it wouldn't be too hard to
implement either. I'm just not as versed in Scheme as I'd like to be (but
I'm working on that), and think the best solution might come from that
realm. I'm always happy to be proved wrong, though :-)

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/wish-Remove-skip-duration-in-Lyrics-tp175492p175501.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Some more possible tweaks to the appearance of the website

[tisimst]

+1 from me! I like the cleaned-up appearance a lot.

- Abraham

On Fri, Feb 20, 2015 at 11:00 AM, Paul Morris [via Lilypond] 
ml-node+s1069038n172119...@n5.nabble.com wrote:

 Hi Trevor,

 Thanks and good idea to wait for more feedback before moving forward.
 Different people can certainly have different preferences on these things.


 So I look forward to hearing from others on the list!

 -Paul


  On Feb 20, 2015, at 6:51 AM, Trevor Daniels [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=172119i=0 wrote:
 
  Hi Paul
 
  I'd be happy to go along with your index3C version, as linked below,
 but I'd like to see comments from others before the changes are adopted.
 These preferences can be very dependent on the individual's artistic sense.
 
  Trevor
 
  - Original Message -
  Paul Morris wrote Friday, February 20, 2015 7:07 AM
 
  I couldn't resist... I have another mock-up to share. Curious to hear
 what you and others think:
 
  http://clairnote.org /lilypond-web-demo3/index3B.html
 
  As you suggested this one has smaller text and the separate read more
 bit (as on the current site).  It also puts the news items into boxes that
 are like those used on the rest of the site, which I think works well for
 them.  This also frames the main focal area well and helps the page not
 look as stark and text-heavy.
 
  Here's another version where the only difference is that pondings and
 quick links are switched:
 
  http://clairnote.org /lilypond-web-demo3/index3C.html
 
  The advantage is that quick links always has a fixed height, while
 pondings does not.  So this has a more compact ragged-bottom sidebar
 (rather than ragged-middle).
 
  P.S. previous version is still here for comparison:
  http://clairnote.org /lilypond-web-demo3/


 ___
 lilypond-devel mailing list
 [hidden email] http:///user/SendEmail.jtp?type=nodenode=172119i=1
 https://lists.gnu.org/mailman/listinfo/lilypond-devel


 --
  If you reply to this email, your message will be added to the discussion
 below:

 http://lilypond.1069038.n5.nabble.com/Some-more-possible-tweaks-to-the-appearance-of-the-website-tp172020p172119.html
  To start a new topic under Dev, email
 ml-node+s1069038n88644...@n5.nabble.com
 To unsubscribe from Lilypond, click here
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=2code=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=
 .
 NAML
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Some-more-possible-tweaks-to-the-appearance-of-the-website-tp172020p172120.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \displayLilyMusic and default durations

[tisimst]

I completely agree. Better to be accurate than visually appealing in this 
regard. 

- Abraham

Sent from my iPhone

 On Feb 18, 2015, at 11:00 AM, David Kastrup [via Lilypond] 
 ml-node+s1069038n172042...@n5.nabble.com wrote:
 
 
 Hi, currently 
 \displayLilyMusic { c4 c c c } produces output { c4 c c c }.  I lean 
 towards letting it produce output { c4 c4 c4 c4 }.  Reason: that's 
 what's actually in the data structures of the music.  The machinery that 
 tries to decide when it can leave off the default duration is 
 potentially error-prone and carries state across the expression. 
 
 More seriously, currently \displayLilyMusic deals badly with 
 { c4 c4 8 8 4 } which gets rendered as { c4 c 8 8 4 } and does 
 consequently not recreate its input.  It would be rather tricky to fix 
 that since by the time the 8 is printed, c and the following space have 
 already been produced.  Instead of making things even more complex here, 
 I consider it saner to become less clever and just print what's in the 
 data, never mind whether it's possibly redundant. 
 
 Opinions? 
 
 -- 
 David Kastrup 
 
 ___ 
 lilypond-devel mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
 
 If you reply to this email, your message will be added to the discussion 
 below:
 http://lilypond.1069038.n5.nabble.com/displayLilyMusic-and-default-durations-tp172042.html
 To start a new topic under Dev, email ml-node+s1069038n88644...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/displayLilyMusic-and-default-durations-tp172042p172048.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ossias and key signatures

[tisimst]

I get the same thing in 2.18.2.

-Abraham 

Sent from my iPhone

 On Jan 18, 2015, at 4:48 AM, David Kastrup [via Lilypond] 
 ml-node+s1069038n170634...@n5.nabble.com wrote:
 
 Phil Holmes [hidden email] writes: 
 
  Image added. 
 
 Uh, looks like a bug.  Namely behavior I cannot imagine to be useful for 
 any purpose.  I seem to remember having fixed something in relation to 
 ossia staves recently, but it was probably unrelated? 
 
 What's the behavior for some earlier versions like 2.18?  The ossia fix 
 I remember doing was more recently than that. 
 
 -- 
 David Kastrup 
 
 ___ 
 lilypond-devel mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
 
 If you reply to this email, your message will be added to the discussion 
 below:
 http://lilypond.1069038.n5.nabble.com/Ossias-and-key-signatures-tp170630p170634.html
 To start a new topic under Dev, email ml-node+s1069038n88644...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Ossias-and-key-signatures-tp170630p170636.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ossias and key signatures

[tisimst]

Phil,

You probably tested this, but when I add \remove Key_engraver and 
\remove Clef_engraver to the ossia staves (as is done sometimes), the 
extra spacing goes away, but the flats are re-printed by the noteheads 
(which isn't too surprising, but also not so desirable). Also, you'll 
want to make sure that fontSize = -3 and not -2, otherwise the 
notation glyphs will be too big relative to the staff-height.

Sorry this doesn't solve the issue, but maybe it will help a little.

-Abraham

On Sun, Jan 18, 2015 at 4:20 AM, Phil Holmes-2 [via Lilypond] 
ml-node+s1069038n170630...@n5.nabble.com wrote:
  I'm not top posting. 
 
 Sending this via the Gmane interface, since my direct emails to the 
 mailing list never seem to get through. 
 
 I'm doing some music with a lot of Ossia staves as vocal cues, and 
 have 
 discovered 2 spacing issues that would appear to be caused by the 
 permanent staves reserving unnecessary space for the ossia's key sig. 
  The 
 code below gives the output which I will attach to a reply to this: 
 you 
 will see that the first line has an unnecessary extension at its end; 
 also 
 that the WMR in measure 20 is displaced to the right. 
 
 I'm assuming this is a bug: anyone know if it's easily fixable? 
 
 { 
   \new Staff = Tenors 

 \new Voice {  \time 3/4 \key ges \major \repeat unfold 24 ces''4 
  
   { 
R1*3*3/4 
   } 
   { 
   \new Staff \with { 
 \remove Time_signature_engraver 
 alignAboveContext = #Tenors 
 \override StaffSymbol #'staff-space = #(magstep -3) 
 fontSize = #-2 
   } 

 \new Voice { \key ges \major r2 aes'4 \repeat unfold 6 aes'4 
 } 

   } 
  
 \repeat unfold 24 ces''4 
 
  
   { 
R1*3*3/4 
   } 
   { 
   \new Staff \with { 
 \remove Time_signature_engraver 
 alignAboveContext = #Tenors 
 \override StaffSymbol #'staff-space = #(magstep -3) 
 fontSize = #-2 
   } 

 \new Voice { \key ges \major r2 aes'4 \repeat unfold 6 aes'4 
 } 

   } 
  
 \repeat unfold 15 ces''4 
 
 } 

 } 
 
 
 -- 
 Phil Holmes 
 
 
 
 ___ 
 lilypond-devel mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://lilypond.1069038.n5.nabble.com/Ossias-and-key-signatures-tp170630.html
 To start a new topic under Dev, email 
 ml-node+s1069038n88644...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Ossias-and-key-signatures-tp170630p170633.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Possible tweaks to the appearance of the website

[tisimst]

Paul Morris wrote
 I tried it lighter before but it blended in with the light green
 background in the top left corner too much.  In the latest version I have
 used a different color, and made the active items dark enough to make the
 distinction clear.

Ooooh... I like the more subtle gradient very much. The only thing I would
change is to make the Search box a little lighter to make it more
noticeable, but maybe it's just me. I don't think it needs to be white like
it is now.


Paul Morris wrote
 I like my latest version's combination of both icon and LilyPond for
 this.  I think using Home is not so common these days.  There's a well
 established expectation that the first link in the navigation, usually
 with the entity's logo or name, goes to the site's main/home page.  

+1! That also looks very nice IMHO.

-Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Possible-tweaks-to-the-appearance-of-the-website-tp170094p170145.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: Font switching docs - add a font to LilyPond?

[tisimst]

Urs,

I think that's a great idea!

Also, I was wondering if we could look into how to make Pango look in the 
system font folder if it can't find a music font and the LilyPond font folder. 
If we could do that then the fonts are version independent. What do you think 
of that? This could eventually lead to not requiring a separate font based on 
the font size if one is not available.

-Abraham

Sent from my iPhone

 On Dec 18, 2014, at 3:59 AM, Urs Liska [via Lilypond] 
 ml-node+s1069038n169508...@n5.nabble.com wrote:
 
 
 Am 18.12.2014 01:38, schrieb James Lowe: 
 
  Urs, 
  
  On 15/12/14 11:24, Urs Liska wrote: 
  Hi all, 
  
  
  Abraham has sent me documentation for his recent font switch improvement 
  to incorporate into LilyPond's manuals. 
  However, there is one issue I'd like to sort out before I start editing 
  the .itely files. 
  
  Of course the documentation gives an example of the use of the new font 
  selection function. But this will require the used font(s) to be 
  installed on the build system because otherwise the build will fail. 
  
  ... 
  
  https://code.google.com/p/lilypond/issues/detail?id=1494
  
  This is a 'patch abandoned'. Take a look here and see if this is 
  something you can work with.
 
 Well, not directly. It rather tells me that it *is* a non-trivial issue. 
 But I think that now that we have the infrastructure of switching fonts 
 built-in with LilyPond the situation has slightly changed. 
 
 So I officially propose to 
 
 - ship LilyJAZZ, LilyJAZZText and LilyJAZZChord with LilyPond 
as this is the most fundamental alternative (allowing for a 
 completely different type of scores 
while the other fonts are merely stylistic alternatives. 
I would do so even if we can only ship the resulting font files. 
It's somewhat less nice than having the MF sources like with 
 Emmentaler, but e.g. TeXLive would 
only say: Provide the sources if that's possible, otherwise use only 
 the font files. 
 - Host the binary font files in the lilypond-extra repository 
(I can prepare a pull request) 
 - Add something to the build process that copies those fonts to the 
 right location in LilyPond 
(I can look into that if someone points me in the right direction) 
 
 Urs 
 
  
  James 
  
 
 
 ___ 
 lilypond-devel mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
 
 If you reply to this email, your message will be added to the discussion 
 below:
 http://lilypond.1069038.n5.nabble.com/Font-switching-docs-add-a-font-to-LilyPond-tp169460p169508.html
 To start a new topic under Dev, email ml-node+s1069038n88644...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Font-switching-docs-add-a-font-to-LilyPond-tp169460p169523.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Another English notename issue

[tisimst]

+1

I have NEVER used the the long-hand names in English, so re-ordering to put cs 
before csharp, etc., IMO, is a wonderful idea!

-Abraham

Sent from my iPhone

 On Dec 1, 2014, at 4:55 AM, David Kastrup [via Lilypond] 
 ml-node+s1069038n169097...@n5.nabble.com wrote:
 
 
 Apart from the onraging discussion and/or non-discussion on bn for b 
 natural on issue 4076 
 URL:https://code.google.com/p/lilypond/issues/detail?id=4076, I found 
 another thing that I find dissatisfactory, namely the default _output_ 
 of music expressions.  We have for 
 
 \language english 
 
 \displayLilyMusic \transpose c cs { c d e f g a b } 
 
 the output 
 
 lilypond /tmp/ugh.ly 
 GNU LilyPond 2.19.16 
 Processing `/tmp/ugh.ly' 
 Parsing... 
 { 
   csharp dsharp esharp fsharp gsharp asharp bsharp 
 } 
 
 I am not convinced that the verbose english style is desirable here, in 
 particular since we have for 
 
 \language english 
 
 \displayLilyMusic \transpose c cqs { c d e f g a b } 
 
 the output 
 
 GNU LilyPond 2.19.16 
 Processing `/tmp/ugh.ly' 
 Parsing... 
 { 
   cqs dqs eqs fqs gqs aqs bqs 
 } 
 
 Now one could state that this should be cured by giving verbose names to 
 quarter accidentals as well, but I think that this will lead to music 
 that more often than not reads other than one would type it. 
 
 So I think we should likely reorder the English notename language such 
 that the default output is the abbreviated form.  Thoughts? 
 
 -- 
 David Kastrup 
 
 ___ 
 lilypond-devel mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
 
 If you reply to this email, your message will be added to the discussion 
 below:
 http://lilypond.1069038.n5.nabble.com/Another-English-notename-issue-tp169097.html
 To start a new topic under Dev, email ml-node+s1069038n88644...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Another-English-notename-issue-tp169097p169098.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Alternative Quarter Rest

[tisimst]

Dan,

IMHO, I think that looks just fine. Everyone's preference may be 
different, but what you have done gets the point across. I think having 
a little space above and below the rest is nice. If you look at the 
eighth rest, it is also left-aligned with the noteheads, so that isn't 
a problem. Optically, it might look nicer to have them 
center-aligned, but I think it's fine left-aligned.

My two cents,
Abraham

On Sat, Nov 29, 2014 at 7:25 PM, Dan Eble [via Lilypond] 
ml-node+s1069038n169055...@n5.nabble.com wrote:
 On Nov 28, 2014, at 08:51 , Dan Eble [hidden email] wrote:
 
  On Nov 28, 2014, at 03:49 , Werner LEMBERG [hidden email] wrote: 
  
  I think that the symbol itself could be improved.  Somehow the 
 slant 
  of the diagonal line looks to steep, so I think its shape should 
  probably checked with original scores (e.g. old Italian and French 
  vocal scores like Ricordi's old edition of `L'esirir d'amore'). 
  
Werner 
  
  Thanks.  I don’t know if this is exactly what you meant, but in 
 this low-resolution scan, 
  
   
 http://www.dlib.indiana.edu/variations/scores/caw8891/large/index.html
  
  the rests are probably taller than the samples I’ve been working 
 from.
 The second draft is attached.  I found no other examples online 
 (maybe I’m lazy) so I interpreted a little.  The scan made it look 
 like the rests were touching the staff lines, but I didn’t like 
 that, so I left a little room. 
 
 Should the rests and note heads be aligned at the left edge, as they 
 appear to be? 
 
 ___ 
 lilypond-devel mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
  z-rest-test.pdf (30K) Download Attachment
 
 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://lilypond.1069038.n5.nabble.com/Alternative-Quarter-Rest-tp168892p169055.html
 To start a new topic under Dev, email 
 ml-node+s1069038n88644...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Alternative-Quarter-Rest-tp168892p169056.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Alternative Quarter Rest

[tisimst]

That's a nice idea, but frequent use of the quarter rest will make this quite 
tedious. This style of quarter rest is typical of that time period of music 
typesetting. I could make a font to do this for a small bounty if enough people 
were interested... My Gutenberg1939 font is another moveable type variant of 
the time, but the quarter rest looks like what we're used to.

Any takers on the bounty? Just curious... If you are interested, send me a 
personal email. 

Regards,
Abraham

Sent from my iPhone

 On Nov 23, 2014, at 7:48 AM, TaoCG [via Lilypond] 
 ml-node+s1069038n168898...@n5.nabble.com wrote:
 
 It looks like two eighth rests combined to me. 
 Something like this, just flipped... 
 
 { 
 r8 
 \tweak rotation #'(180 0 0.1) 
 \tweak extra-offset #'(-1.8 . 0) 
 r8 
 } 
 
 If you reply to this email, your message will be added to the discussion 
 below:
 http://lilypond.1069038.n5.nabble.com/Alternative-Quarter-Rest-tp168892p168898.html
 To start a new topic under Dev, email ml-node+s1069038n88644...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Alternative-Quarter-Rest-tp168892p168901.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Alternative Quarter Rest

[tisimst]

Dan,

I'm not sure if the style was given a name other than it is a moveable type 
design. I am certainly not an expert on the matter, but I know it's not 
distinctly American. I have seen the same or similar typesetting style in at 
least one German-published music text and I think I've also seen it in an 
Italian one, too.

-Abraham

Sent from my iPhone

 On Nov 23, 2014, at 5:47 PM, Dan Eble [via Lilypond] 
 ml-node+s1069038n168908...@n5.nabble.com wrote:
 
 On Nov 23, 2014, at 15:07 , tisimst [hidden email] wrote: 
  
  This style of quarter rest is typical of that time period of music 
  typesetting. 
 
 Is your knowledge of the subject deep enough to propose a name for the style? 
  (Is it distinctly American, maybe?) 
 
 Thanks, 
 — 
 Dan 
 
 
 ___ 
 lilypond-devel mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
 
 If you reply to this email, your message will be added to the discussion 
 below:
 http://lilypond.1069038.n5.nabble.com/Alternative-Quarter-Rest-tp168892p168908.html
 To start a new topic under Dev, email ml-node+s1069038n88644...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Alternative-Quarter-Rest-tp168892p168915.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Next step for easier custom music font switching

[tisimst]

David Kastrup wrote
 Possibly using named arguments, so
 
 (make-pango-font-tree FreeSerif FreeSans Inconsolata
#:music lilyjazz #:brace gonville)
 
 Though I am not overly happy with what would be the required and what
 would be the optional font arguments.
 
 Maybe recycling the same function name is not really worth the trouble.
 A backward compatible interface seems to create more trouble than it
 solves.
 
 -- 
 David Kastrup

Could we make them all optional? They all have defaults, after all. There
have been plenty of times where I haven't cared what the sans-serif and
monospace fonts were because all I wanted to change was the serif font.

As for the function name recycling, do you think it would then be more
useful to create a new function instead? I'm cool with that. I just wanted
to make sure everyone else thought this was a good idea. Like I said before,
I hardly changed the original functions. 99+% of the code is the same.
Putting the music/brace font arguments at the end also sound fine to me if
that works for everyone else.

Regards,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Next-step-for-easier-custom-music-font-switching-tp164649p164720.html
Sent from the Dev mailing list archive at Nabble.com.

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

Next step for easier custom music font switching

[tisimst]

So, Urs and I have been discussing how we might proceed to make alternate
music fonts more publicly available and I thought I'd bring the discussion
here since there are some decisions to be made regarding how users would
experience the change.

- Question 1: *Should the new syntax be something like this?* (where the
music and piano-brace fonts are put at the first)

\paper {
  #(define fonts
(make-pango-font-tree
*lilyjazz*  ; music font
*gonville*  ; piano brace font
FreeSerif
FreeSans
Inconsolata
(/ staff-height pt 20)))
}

- Question 2: *Should we require the new fonts to be in the same folder as
Emmentaler?* Most users won't know where this is and would more likely want
to just install the fonts in the usual system fonts folder with all the
other text fonts. Pango seems to know where this folder is, so it wouldn't
need to be hard-coded like it currently is in lily/font-config.cc.

- Question 3: *Should we require a font file for each of the optical sizes
even though Emmentaler is the ONLY font, currently, that supports this? Or
can we make it possible to have a single music/brace font file?* As it
stands, with the new music fonts I've made, I create a separate file for
each of the optical sizes, even though they are all actually identical. I
guess all I'm saying is that we can keep this requirement, but it seems like
it would be nice to allow for a single font when there's only one size
available. It would make things a little simpler for the user when they are
installing things.

Urs has kindly volunteered to host the fonts on www.openlilylib.org, so that
will be taken care of.

What think ye?

Regards,
Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Next-step-for-easier-custom-music-font-switching-tp164649.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: Crash

[tisimst]

Phil,

The issue comes from using R instead of r when inputting rests. The R
syntax for rests is used to indicate that an entire measure is rested, which
centers a whole rest across the measure, regardless of actual duration. It
also assumes that /there are measures/ to break up the time. The r syntax
for rests doesn't care where it is, only that it takes up some amount of
time. Thus, since Mensural notation doesn't use measures, changing R\breve
to r\breve should fix the problem for you (it worked for me).

-Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Crash-tp163090p163112.html
Sent from the Dev mailing list archive at Nabble.com.

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

Slashed notehead collision

[tisimst]

I just noticed a peculiar collision that I couldn't make go away between the
noteheads.s0slash glyph and a tie. Here's a minimal snippet:

\new Staff {
  \new Voice \with {
\consists Pitch_squash_engraver
  }
  \relative c' {
\improvisationOn
f1 ~
f2
  }
}

http://lilypond.1069038.n5.nabble.com/file/n162855/slashednoteheadcollision.png
 

A slur works doesn't clash, but a tie does. Seems like a bug that needs some
serious squashin' though I'm not sure where to attack this one :) Just
thought I'd bring it up.

-Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Slashed-notehead-collision-tp162855.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: Question about customizing emmentaler font

[tisimst]

Urs Liska wrote
 I tried this:
 - replacing font.scm
 - downloading Gonville and
extracting the files beside the emmentaler files
 - running the example (with gonville twice, as I
don't have Cadence yet)
 
 On my machine it gives the attached result, and the text of the tagline 
 is tiny too. This is on a patched 2.18 as well as on a patched 2.19.4.
 
 Any idea what this means?

:(

Off the top of my head, no (sigh). But I do have a few questions...

1. What OS are you using?
2. Did you use the font.scm file I posted, or did you tweak it yourself?
3. Will you provide a .ly file that I can try that's not working for you?
4. Were there any warnings/errors/unusual log information printed during
compile?

I'm sorry to hear it didn't work for you as easily as I'd hoped. I confess
that I am thoroughly enjoying being able to create stylesheets and use other
fonts at-will. I've made  Parnassus http://www.resonata.be/archives/117  
LilyPond-compatible and I'm almost done with Bravura-0.9. I'm finding that I
mostly only need to do some basic glyph repositioning, but nothing
complicated or time consuming. 

I've tried this on Linux and Windows and they give the same results for me.
Can't say I know what will happen on a Mac since I'm not sure how it deals
with fonts (and I don't have access to a Mac, for that matter...). There
certainly may be limitations here that I just won't know about yet until
more people try it and give me feedback. So, thanks for the feedback! It can
seem like I live in this little world of paradise, ignorantly thinking that
it will work smoothly for others, too.

One thing I've learned (though I doubt it's the culprit to your issue) is
that if I want to engrave at a reduced the staff-size, I need to set that
/before/ setting the document fonts, like the following, or it won't resize
correctly:

#(set-global-staff-size 15)

\paper {
  #(define fonts
  ... )
}

Let me know what you find out.

-Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Question-about-customizing-emmentaler-font-tp161702p162102.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: Question about customizing emmentaler font

[tisimst]

Urs,

That's exactly what I'm saying. If someone could figure out how to create a
function to only change those two fonts, I agree, that would be great! It
certainly adds to the complexity of make-pango-font-tree. I just couldn't
figure it out in the short time I've worked on it :), so I simply resorted
to modifying the current one.

I can't see why you couldn't make a script in order to make a SMuFL font
work with LilyPond. Now, it's not quite as convenient as \smuflOn and
\smuflOff, but I'd think people wouldn't mix notation fonts for different
passages in the same document (maybe I'm wrong). This might also make it
easier to make LilyJAZZ more compatible, though I haven't tried it.

At your request, I've attached a PDF showing cadence notation and gonville
braces.

mixing-notation-and-brace-fonts-example2.pdf
http://lilypond.1069038.n5.nabble.com/file/n162037/mixing-notation-and-brace-fonts-example2.pdf
  



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Question-about-customizing-emmentaler-font-tp161702p162037.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: Question about customizing emmentaler font

[tisimst]

Werner LEMBERG wrote
 we would need to set up another font instance for posters and the
 like, without any edge smoothing...  I still think that a
 postprocessor is the way to go.

Don't get me wrong, the global post-processing would be very cool if
someone's willing to figure out how to do it, but it just seems like a more
difficult challenge than just updating the glyphs.

If we really wanted to use the fonts for a large poster print, why not just
make another version without the rounds called emmentaler-poster or
emmentaler-72? In reality, the rounds would simply be REALLY TINY, virtually
unnoticeable, which practically could just be omitted at these very large
sizes. I would think that the /most common/ usage of these fonts is NOT for
posters, though.

-Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Question-about-customizing-emmentaler-font-tp161702p161799.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: Question about customizing emmentaler font

[tisimst]

Jan,

Your skepticism is not uncommon. See the collages I've attached that 
exemplify what I'm talking about. Some are from Barenreiter (even from 
the LilyPond essay), some from Breitkopf, some from Edition Peters. 
Sorry they all aren't the same resolution, but that's what I had to 
work with. They all show this artifact of rounded interior corners. I 
promise I'm not just making this up. They come from the punch 
manufacturing process AND the engraving process AND printing process. I 
think it would be quite nice to incorporate these somehow, but maybe 
that's just me, in which case I would do it for myself.

What I love about them is the eye doesn't really notice them when they 
are there, but I would argue that the eye DEFINITELY notices when they 
are NOT there, like with any of the major notation fonts today. If you 
need more examples, I'd be happy to supply them. Cheers!

-Abraham

On Tue, Apr 22, 2014 at 4:23 AM, Jan Nieuwenhuizen [via Lilypond] 
ml-node+s1069038n161734...@n5.nabble.com wrote:
 tisimst writes: 
 
  Here's a couple of screenshots of what I mean by the internal 
 corners 
  needing to be rounded. Thanks for your help! If you can help me 
 know 
  how to add these rounds programmatically with metafont, I'll be a 
 VERY 
  happy camper :) 
 
 I'm not sure why, I'd be quite, quite surpised if you could produce 
 high-resolution scans that show these corners rounded. 
 
 Although I appreciate your looking into this, I think this is a 
 mistake 
 to round these... 
 
 Greetings, Jan 
 
 -- 
 Jan Nieuwenhuizen [hidden email] | GNU LilyPond http://lilypond.org
 Freelance IT http://JoyofSource.com | Avatar®  
 http://AvatarAcademy.nl  
 
 ___ 
 lilypond-devel mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://lilypond.1069038.n5.nabble.com/Question-about-customizing-emmentaler-font-tp161702p161734.html
 To unsubscribe from Question about customizing emmentaler font, click 
 here.
 NAML


breitkopf-essay-examples.png (79K) 
http://lilypond.1069038.n5.nabble.com/attachment/161770/0/breitkopf-essay-examples.png
edition-peters-examples.png (342K) 
http://lilypond.1069038.n5.nabble.com/attachment/161770/1/edition-peters-examples.png
barenreiter-examples.png (603K) 
http://lilypond.1069038.n5.nabble.com/attachment/161770/2/barenreiter-examples.png
barenreiter-essay-improvement-examples.png (127K) 
http://lilypond.1069038.n5.nabble.com/attachment/161770/3/barenreiter-essay-improvement-examples.png
barenreiter-essay-examples.png (122K) 
http://lilypond.1069038.n5.nabble.com/attachment/161770/4/barenreiter-essay-examples.png




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Question-about-customizing-emmentaler-font-tp161702p161770.html
Sent from the Dev mailing list archive at Nabble.com.___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel