Re: renaming "vertical spacing inside systems" props
> Renaming proposals, round 4: > > CURRENT NAME PROPOSED NAME > - > next-staff staff-staff > default-next-staff default-staff-staff > > inter-staffnonstaff-relatedstaff > inter-loose-line nonstaff-nonstaff > non-affinity nonstaff-unrelatedstaff > > between-staff withingroup-staff-staff > after-last-staff staffgroup-staff This is fine with me. > And lastly, I still think reference/opposite is better than > related/unrelated: > > nonstaff-referencestaff > nonstaff-oppositestaff Well, `related/unrelated' refers to the functionality, and `reference' too. However, `opposite' refers to a visual concept which IMHO doesn't harmonize well with the other terms. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
On 2010/11/04 08:31:30, marc wrote:
No, I don't think we should it do more complicated that necessary.
Perhaps the name 'tie-follow is misleading, but the engraver (before
you
left out the slur and glissando bits) did the right job - marking
exactly
the tab-note-heads that have to be treated specially.
If we mark *every* tied-to note, we have to mark *every* start of a
slur
and *every* start
of a glissando as well and check for the appearance of (and
('tie-follow
(or ( 'slur-start 'gliss-start,
which is overkill - just let the engraver take the decision, raise a
flag, and the callbacks do their job.
But right now, the callbacks are fighting over the notes -- and I don't
think that's right. In order to work correctly, we need to know the
order in which the callbacks are called.
I've got an algorithm that I think is clearer and simplifies the
callbacks, but I haven't been able to fully test it yet because I can't
get the C++ engraver to work right in terms of checking equality.
I'll post a patch for comments.
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Keith E OHara wrote: > I had imagined you would simultaneously change >staff-affinity (UP / DOWN / CENTER) > toreference-direction (UP / DOWN / CENTER) > so we can remember that this direction tells us which > staff is which between referencestaff and oppositestaff. I think staff-affinity is more informative than reference-direction. > The closest I could find to a flaw was that > nonstaff-unrelatedstaff-spacing also determines the space > between an UP nonstaff and a DOWN nonstaff (if there is no > CENTER nonstaff between them)... I *think* that's just a case of stretching to prevent collisions. Does the same happen when all the 'stretchability and 'padding keys are set to 0? If yes, please post a minimal example. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
On Sat, 06 Nov 2010 18:20:08 -0700, wrote: Renaming proposals, round 4: CURRENT NAME PROPOSED NAME - next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-relatedstaff inter-loose-line nonstaff-nonstaff non-affinity nonstaff-unrelatedstaff between-staff withingroup-staff-staff after-last-staff staffgroup-staff [...] And lastly, I still think reference/opposite is better than related/unrelated: nonstaff-referencestaff nonstaff-oppositestaff But I won't protest. Any last thoughts/votes, or should I go ahead with the proposals listed above Mark, I had imagined you would simultaneously change staff-affinity (UP / DOWN / CENTER) toreference-direction (UP / DOWN / CENTER) so we can remember that this direction tells us which staff is which between referencestaff and oppositestaff. We might convince Mr Daniels that this is good enough reason to support your (unabbreviated) preference, or he might come up with an even better suggestion for the variable that chooses which direction is the 'related' direction. Everything else looks consistent. The closest I could find to a flaw was that nonstaff-unrelatedstaff-spacing also determines the space between an UP nonstaff and a DOWN nonstaff (if there is no CENTER nonstaff between them) but I honestly prefer understandable names that describe 99% of the use cases, than theoretically perfect ones. -- Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
On 11/6/10 7:17 PM, "Mark Polesky" wrote:
> Okay, it looks like we're converging here...
>
> Renaming proposals, round 4:
>
> CURRENT NAME PROPOSED NAME
> -
> next-staff staff-staff
> default-next-staff default-staff-staff
>
> inter-staffnonstaff-relatedstaff
> inter-loose-line nonstaff-nonstaff
> non-affinity nonstaff-unrelatedstaff
>
> between-staff withingroup-staff-staff
> after-last-staff staffgroup-staff
>
>
> It seems that no one here is opposed to the odd-looking
> compound words ("withingroup", "relatedstaff" etc.), which
> surprises me a little. They remind me of the common
> mistake of reading "manslaughter" as "man's laughter"...
> Anyway, if nobody minds these, I guess I don't mind either.
I don't particularly like them, but I can't come up with a better
alternative, and they're much better than the previous, IMO.
>
> And lastly, I still think reference/opposite is better than
> related/unrelated:
>
> nonstaff-referencestaff
> nonstaff-oppositestaff
I'd be fine with either reference or related.
Whatever you want is fine with me.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: non-technical help for spacing issues
On Wed, 27 Oct 2010 00:24:33 -0700, Graham Percival wrote: >On Tue, 26 Oct 2010 00:47:01 -0700, Graham wrote: >This is directed at people saying "I can't do anything to help..." > I need a committing, not necessarily committed, partner to close this. I attach a patch corresponding to the style-sheets I just posted over on -user (http://lists.gnu.org/archive/html/lilypond-user/2010-11/msg00111.html) -- which are a lot simpler than they were two weeks ago. 1) The paper-defaults changes are for stretchability between systems, and at the bottom of a flush-bottom page. 1a) With this change, ragged-bottom=#f will leave a bit of stretch at the bottom to give reasonable results for scores, while it still pulls the last staff to the bottom of the page for single-staff parts. The 2.13 default spacing is shown as a small image at (http://lists.gnu.org/archive/html/lilypond-user/2010-10/msg00692.html) while the proposed spacing is at (http://k-ohara.oco.net/Lilypond/score.usedPatch.pdf). 1b) Putting relatively more vertical space between systems, or between staff-groups, is good for readability. I transferred the extra stiffening of the piano-staff, which Joe did a year ago, to everything spaced with StaffGrouper. 1c) GrandStaff does not currently get StaffGrouper spacing by default. The docs say that Piano Staff (which had and obviously wants StaffGrouper spacing) is just like GrandStaff, so I gave GrandStaff a topLevelAlignment of #f, the same as the other staff groups. 2a) Lyrics get less space in the new system, but all the choral-music folk seem to want is a but a touch more padding from Lyrics to any non-associated grobs on the next staff. 2b) The separation between Lyrics and its associated staff should be a 'rod' instead of a spring, or else the last line of Lyrics can get squished into its staff (image). Graham, your original wish did not get fulfilled. Tweaking parameters *could* reduced issue 1290 to the same severity as it had with version 2.12.3, but I could find no support for that step -- and do not recommend it myself. (Details are in the tracker the issue 1290 thread on -bug) Given that later discussion makes it seem like an enhancement request, and not a release-blocking issue, could the bug-meister please review 1290 ? -Keith engraver-init.ly.diff Description: Binary data paper-defaults-init.ly.diff Description: Binary data define-grobs.scm.diff Description: Binary data <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Okay, it looks like we're converging here...
Renaming proposals, round 4:
CURRENT NAME PROPOSED NAME
-
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-relatedstaff
inter-loose-line nonstaff-nonstaff
non-affinity nonstaff-unrelatedstaff
between-staff withingroup-staff-staff
after-last-staff staffgroup-staff
It seems that no one here is opposed to the odd-looking
compound words ("withingroup", "relatedstaff" etc.), which
surprises me a little. They remind me of the common
mistake of reading "manslaughter" as "man's laughter"...
Anyway, if nobody minds these, I guess I don't mind either.
And lastly, I still think reference/opposite is better than
related/unrelated:
nonstaff-referencestaff
nonstaff-oppositestaff
But I won't protest. Any last thoughts/votes, or should I
go ahead with the proposals listed above?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
On 11/6/10 6:46 PM, "Mark Polesky" wrote: > Carl Sorensen wrote: >>> 9) initial-separation >>> * longer but describes the meaning more accurately now >>> we have an item-item-spacing format >>> >>> I vote for 8 or 9. >> >> 9. > > Does this entail changing 'minimum-distance to > 'minimum-separation? I prefer both to use the same noun. Yes, I'm OK with minimum-separation, where separation is the separation between reference points. But I'm fine with 8 as well -- with all the work we've done on distance it may be better to just stay with distance. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
Carl Sorensen wrote: >> 9) initial-separation >> * longer but describes the meaning more accurately now >> we have an item-item-spacing format >> >> I vote for 8 or 9. > > 9. Does this entail changing 'minimum-distance to 'minimum-separation? I prefer both to use the same noun. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
On 2010-11-06 18:32, Mark Polesky wrote: 7 proposals for renaming the 'space alist-key have been discussed, but a decision has not yet been made. And I just added an 8th proposal (initial-distance). [...] 2) optimal-distance * sounds like the resulting trade-off between the desired distance and situational spacing constraints 3) desired-distance [...] 5) base-distance * sounds like the distance between "bases" [...] This might complicate it, but 2, 3 or 5, with decreasing preference. Sorry for not being active anymore in the recent discussions, by the way. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
On 11/6/10 5:38 PM, "Trevor Daniels" wrote: > Mark Polesky wrote Saturday, November 06, 2010 5:32 PM >> 7) basic-distance >> 8) initial-distance >> >> I vote for either 7 or 8. What about you? > > 9) initial-separation >* longer but describes the meaning more accurately > now we have an item-item-spacing format > > I vote for 8 or 9. 9. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
Mark Polesky wrote Saturday, November 06, 2010 5:32 PM 7 proposals for renaming the 'space alist-key have been discussed, but a decision has not yet been made. And I just added an 8th proposal (initial-distance). To recap, I think the arguments *for* each of these are mostly self-evident, so the list here only includes the arguments *against* those that have been opposed: 1) default-distance * sounds like the program's default, not the user's 2) optimal-distance * sounds like the resulting trade-off between the desired distance and situational spacing constraints 3) desired-distance 4) requested-distance 5) base-distance * sounds like the distance between "bases" 6) unstretched-distance * sounds like space can only stretch, not compress 7) basic-distance 8) initial-distance I vote for either 7 or 8. What about you? 9) initial-separation * longer but describes the meaning more accurately now we have an item-item-spacing format I vote for 8 or 9. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
On 11/6/10 11:32 AM, "Mark Polesky" wrote: > 7 proposals for renaming the 'space alist-key have been > discussed, but a decision has not yet been made. And I just > added an 8th proposal (initial-distance). > > > To recap, I think the arguments *for* each of these are > mostly self-evident, so the list here only includes the > arguments *against* those that have been opposed: > > 1) default-distance >* sounds like the program's default, not the user's > 2) optimal-distance >* sounds like the resulting trade-off between the > desired distance and situational spacing constraints > 3) desired-distance > 4) requested-distance > 5) base-distance >* sounds like the distance between "bases" > 6) unstretched-distance >* sounds like space can only stretch, not compress > 7) basic-distance > 8) initial-distance > > I vote for either 7 or 8. What about you? 3 or 7 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (font-related) \caps \fontCaps and \smallCaps
On Sat, Nov 6, 2010 at 6:49 PM, Werner LEMBERG wrote: > The whole issue is VERY problematic. Today, many fonts already > contain glyphs for small caps, however, lilypond isn't able to access > them! Reason is that lilypond currently misses an interface to > OpenType layout tables. Do we have a bug tracker item about it? If not, we certainly should add one. Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (font-related) \caps \fontCaps and \smallCaps
> The `normal' one is `smcp', BTW. If you activate it, small letters in > the input are converted to small caps letters. If I say `small letters' I mean `lowercase letters'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (font-related) \caps \fontCaps and \smallCaps
> Is it possible to check real small caps are available within the > font? The whole issue is VERY problematic. Today, many fonts already contain glyphs for small caps, however, lilypond isn't able to access them! Reason is that lilypond currently misses an interface to OpenType layout tables. There are five feature tags related to caps defined in the OpenType 1.6 specification: cpspCapital Spacing c2pcPetite Capitals From Capitals c2scSmall Capitals From Capitals pcapPetite Capitals smcpSmall Capitals The `normal' one is `smcp', BTW. If you activate it, small letters in the input are converted to small caps letters. Before having access to OpenType features, I consider any change in the font interface premature. Please read the documentation of the `fontspec' package (for both XeTeX and luatex), which provides a user-friendly LaTeX interface to OpenType fonts. The documentation also shows many OpenType features in action, including caps related ones. http://www.ctan.org/get/macros/xetex/latex/fontspec/fontspec.pdf I suggest that we develop (after release of 2.14) a not-yet-written API similar to the fontspec interface. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Renaming the 'space alist-key
7 proposals for renaming the 'space alist-key have been discussed, but a decision has not yet been made. And I just added an 8th proposal (initial-distance). The discussion began with the 7 posts starting here: http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00085.html ...and continued with the 3 posts starting here: http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00359.html To recap, I think the arguments *for* each of these are mostly self-evident, so the list here only includes the arguments *against* those that have been opposed: 1) default-distance * sounds like the program's default, not the user's 2) optimal-distance * sounds like the resulting trade-off between the desired distance and situational spacing constraints 3) desired-distance 4) requested-distance 5) base-distance * sounds like the distance between "bases" 6) unstretched-distance * sounds like space can only stretch, not compress 7) basic-distance 8) initial-distance I vote for either 7 or 8. What about you? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
(font-related) \caps \fontCaps and \smallCaps
Dear lilypond users, developers,
There is currently three different commands for small caps
(small capitals, to use inside a text markup) :
\caps , \fontCaps and \smallCaps .
If I understand correctly :
1. \smallCaps is a command to make "FAKE" small capitals (by
transforming lowercases to smaller-than-normal-fontsize uppercases).
It does not support accented characters.
2. \fontCaps is for "REAL" small capitals, provided by the font.
The font has to support the "caps" font-shape. I'm not an expert in
fonts but is there an "official" way to support this "caps" font-shape?
I have read that usually these "small caps" characters of the font are
usually "stored" in a special "font-related" group of characters in the
Unicode characters table.
But is it only "implicit, advised conventions" or is it "official"?
3. \caps is simply a copy of the \smallCaps command.
Could we simplify that and use only ONE SAME COMMAND for small caps?
For example change the \smallCaps command so that it behaves like:
IF ("real" caps are available with the selected font)
THEN use what we call currently \fontCaps
ELSE
use "fake" small caps (what we call currently \smallCaps )
Is it possible to check real small caps are available within the font?
What do you think about that?
Cheers,
Xavier
--
Xavier Scheuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: follow-up to report 22
On Sat, Nov 6, 2010 at 4:48 AM, Joe Neeman wrote: > If the archives were public, it might deter people from speaking frankly. I understand; however having public archives is also something important for the project's history. The best compromise I could come up with would be to make discussions public after a number of years. Again, this looks to me like a thing from the past: when considering a project in its infancy, or at least where people stay the same year after year, public archives are quite dispensable. Once you've reached a point where the development team is gradually renewed and few (if any) of the original developers are still around, this question has to be raised sooner or later. > Obviously, everyone knows by now that we've had a thread discussing David; > had there been public archives (or a plan to make them public in the > future), that conversation would have probably gone off-list. Which defeats > the purpose of having such a list in the first place. That's a interesting example. As far as I can see, David got listed as a LilyPond developer only in late June 2010 (and I'm guessing he didn't have git access much earlier in 2010). If, as has been stated, the only 4 emails on -hackers in 2010 were about "reviving -hackers", then it proves that any earlier discussion you guys might have had regarding David was actually not followed by any concrete action until much later. (Again, I can only guess.) Besides, while I certainly don't want to speak on his behalf, David doesn't strike me as the kind of person who can't take being directly criticized, even in a non-polite way. (I would probably, and do, react a lot more badly in such a situation.) > I doubt anyone objects to having a public list of the -hackers members. If > we do create such a list, it's probably more efficient just to get a list > from the list administrator rather than sleuthing around. Well, as it happens Xavier's original email about "secrete mailing lists" (his words, not mine) was also sent to the -hackers list administrator. However, I have yet to see any answers from him, privately or in this thread. (And, yes, Han-Wen really is a busy man and I can perfectly understand that these questions may seem trivial and uninteresting to him. However, when it comes to "reassurance", a few words go a long way.) > Do you really think that having a private mailing list damages the project? Potentially, yes (it does to me, I'm not sure about others). > That is, assuming that we are open about its existence/purpose/whatever? Then it would make quite a difference. This "openness", or rather the need for it, is precisely why we're having this conversation! Thanks for the thorough conversation. Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
