Re: GSoC project ideas
Am 23.01.2017 um 23:11 schrieb Simon Albrecht: > On 23.01.2017 22:47, Urs Liska wrote: >> So while it's perfectly possible to put OLL projects on the list and to >> apply for them (or others not listed there) in case of doubt projects >> working on LilyPond itself might be the preference of the developer >> community. > […] >> What I would see as a better project (and what I intend to suggest for >> the list) is developing a system of automated testing and documentation >> generation for openLilyLib, both the snippets repo and the other, >> "new-style", packages. This would actually bring openLilyLib a huge step >> forward to be usable on a broader base. > > I think having openlilylib in a state where it’s reliable, easy to use > and gets adopted more generally would be a huge step forward for all > of LilyPond. I’m thinking (as I’m certain you are, too) of something > comparable to the package system of the TeX universe, which offers a > great possibility to provide facilities for very different use cases > without blowing up the core program, while still having them readily > available, documented and comfortable to maintain. > So don’t be too uneasy about bringing openLilyLib up here, I think. > Thanks for that. I've uploaded a patch at https://codereview.appspot.com/311570043 Urs > Best, Simon > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for Tuesday January 24
Hello, Here is the current patch countdown list. The next countdown will be on January 27 A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: No patches to push at this time Countdown: 5037 web: GSoC page: Add SMuFL project - Urs Liska https://sourceforge.net/p/testlilyissues/issues/5037 http://codereview.appspot.com/318330043 5035 Remove midi.c - Graham Percival https://sourceforge.net/p/testlilyissues/issues/5035 http://codereview.appspot.com/7016046 5034 Fully document the short forms of the mode-changing commands - Trevor Daniels https://sourceforge.net/p/testlilyissues/issues/5034 http://codereview.appspot.com/313380043 185 RhythmicStaff squishing chords should produce single notes - Trevor Daniels https://sourceforge.net/p/testlilyissues/issues/185 http://codereview.appspot.com/6495107 Review: 5040 Let \alterBroken tweak ties again - David Nalesnik https://sourceforge.net/p/testlilyissues/issues/5040 http://codereview.appspot.com/319160043 5039 Replace \set Staff.instrumentName with \with form in doc examples - James Lowe https://sourceforge.net/p/testlilyissues/issues/5039 http://codereview.appspot.com/313400043 4509 Enhancement: automatically engrave lyric extenders - Alexander Kobel https://sourceforge.net/p/testlilyissues/issues/4509 http://codereview.appspot.com/313240043 New: 5042 Web: GSoC: Add openLilyLib project suggestion - Urs Liska https://sourceforge.net/p/testlilyissues/issues/5042 http://codereview.appspot.com/311570043 5041 Using eq? on numbers is undefined behavior - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5041 http://codereview.appspot.com/314300043 5038 Web: Review GSoC page introduction - Urs Liska https://sourceforge.net/p/testlilyissues/issues/5038 http://codereview.appspot.com/315410043 Waiting: 4600 Let notes/rests suppress multi-measure rest grobs - Dan Eble https://sourceforge.net/p/testlilyissues/issues/4600 http://codereview.appspot.com/265160043 Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3830: Document \offset command (issue 319150043 by david.nales...@gmail.com)
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2522
Documentation/notation/changing-defaults.itely:2522: [-]\offset
@var{property} @var{offsets} @var{item}
On 2017/01/23 23:52:54, thomasmorley651 wrote:
Would it be even more clear to have instead of @var{offsets} something
like
@var{offset-value} or @var{property-value}?
(Same below and in the docstring for the offset-command in
music-functions-init.ly)
Please keep in mind I'm not a native speaker, so I may be wrong here.
"offsets" works, but I could change this to "displacements" -- you know,
sort of like not using a word in its own definition. There would also
be no confusion between noun and verb senses, since "displacements" is
only a noun.
But maybe, since the docs are supposed to be clear to native and
non-native speakers, "offset-values" or "offset-amounts" would be best?
https://codereview.appspot.com/319150043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] no-outline-stencil backend property
Hi David!
What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. Probably by just containing _two_ stencils: one for typesetting, one for outlining. That would
make for a much more transparent manner of programming things like that.
There's no need for two stencils. I propose to include the attached code.
Knut
>From ae50c298fee5f57c1200bd82b8f20783e74b4cd9 Mon Sep 17 00:00:00 2001
From: Knut Petersen
Date: Tue, 24 Jan 2017 14:17:10 +0100
Subject: [PATCH] Implement no-outline-stencil backend command
Should be used instead of a transparent stencil / delayed
stencil evaluation construct where the delay is not needed.
Signed-off-by: Knut Petersen
---
lily/include/stencil.hh | 1 +
lily/stencil-integral.cc| 3 +++
lily/stencil-interpret.cc | 5 +
lily/stencil.cc | 6 ++
scm/define-stencil-commands.scm | 1 +
5 files changed, 16 insertions(+)
diff --git a/lily/include/stencil.hh b/lily/include/stencil.hh
index 8af67c0f76..546b5a3bff 100644
--- a/lily/include/stencil.hh
+++ b/lily/include/stencil.hh
@@ -84,6 +84,7 @@ public:
void align_to (Axis a, Real x);
void translate_axis (Real, Axis);
void scale (Real, Real);
+ void no_outline ();
Interval extent (Axis) const;
Box extent_box () const;
diff --git a/lily/stencil-integral.cc b/lily/stencil-integral.cc
index 1b9aa5181b..583a454750 100644
--- a/lily/stencil-integral.cc
+++ b/lily/stencil-integral.cc
@@ -55,6 +55,7 @@ when this transforms a point (x,y), the point is written as matrix:
#include "skyline.hh"
#include "skyline-pair.hh"
#include "spanner.hh"
+
using namespace std;
Real QUANTIZATION_UNIT = 0.2;
@@ -938,6 +939,8 @@ stencil_traverser (PangoMatrix trans, SCM expr)
else if (scm_is_eq (scm_car (expr), ly_symbol2scm ("delay-stencil-evaluation")))
// should not use the place-holder text, but no need for the warning below
return vector ();
+ else if (scm_is_eq (scm_car (expr), ly_symbol2scm ("no-outline-stencil")))
+return vector ();
else if (scm_is_eq (scm_car (expr), ly_symbol2scm ("grob-cause")))
return stencil_traverser (trans, scm_caddr (expr));
else if (scm_is_eq (scm_car (expr), ly_symbol2scm ("color")))
diff --git a/lily/stencil-interpret.cc b/lily/stencil-interpret.cc
index 25fad0d842..6bf0671284 100644
--- a/lily/stencil-interpret.cc
+++ b/lily/stencil-interpret.cc
@@ -39,6 +39,11 @@ interpret_stencil_expression (SCM expr,
}
if (scm_is_eq (head, ly_symbol2scm ("transparent-stencil")))
return;
+ if (scm_is_eq (head, ly_symbol2scm ("no-outline-stencil")))
+{
+ interpret_stencil_expression (scm_cadr (expr), func, func_arg, o);
+ return;
+}
if (scm_is_eq (head, ly_symbol2scm ("footnote")))
return;
if (scm_is_eq (head, ly_symbol2scm ("translate-stencil")))
diff --git a/lily/stencil.cc b/lily/stencil.cc
index 5e568c98db..afc348d95f 100644
--- a/lily/stencil.cc
+++ b/lily/stencil.cc
@@ -193,6 +193,12 @@ Stencil::scale (Real x, Real y)
}
void
+Stencil::no_outline ()
+{
+expr_ = scm_list_2 (ly_symbol2scm ("no-outline-stencil"), expr_);
+}
+
+void
Stencil::add_stencil (Stencil const &s)
{
SCM cs = ly_symbol2scm ("combine-stencil");
diff --git a/scm/define-stencil-commands.scm b/scm/define-stencil-commands.scm
index 23c17abb9b..ddce5bd631 100644
--- a/scm/define-stencil-commands.scm
+++ b/scm/define-stencil-commands.scm
@@ -63,6 +63,7 @@ are used internally in @file{lily/@/stencil-interpret.cc}."
combine-stencil
delay-stencil-evaluation
footnote
+no-outline-stencil
output-attributes
rotate-stencil
scale-stencil
--
2.11.0
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES - Countdown for Tuesday January 24
Hello David, On Tue, 24 Jan 2017 07:05:24 -0600 David Nalesnik wrote: > > > > Would you add > > 3830 Documentation for \offset is required > https://sourceforge.net/p/testlilyissues/issues/3830/ > https://codereview.appspot.com/319150043/ For anything to appear on my PATCH countdown (and test) 'radar' the Status field == 'Started' and Patch == 'New'. In this case Issue 3830 had a Status == 'Accepted'. I have changed this Status manually, although if you use git-cl this does (should do) this for you automatically, else you just need to change this 'Status' field to 'Started' manually if you are entering issues manually. Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES - Countdown for Tuesday January 24
James, On Tue, Jan 24, 2017 at 4:43 AM, James wrote: > Hello, > > Here is the current patch countdown list. The next countdown will be on > January 27 > > > A quick synopsis of all patches currently in the review process can be > found here: > > http://philholmes.net/lilypond/allura/ > > > > Push: No patches to push at this time > > > Countdown: > > 5037 web: GSoC page: Add SMuFL project - Urs Liska > https://sourceforge.net/p/testlilyissues/issues/5037 > http://codereview.appspot.com/318330043 > > > 5035 Remove midi.c - Graham Percival > https://sourceforge.net/p/testlilyissues/issues/5035 > http://codereview.appspot.com/7016046 > > > 5034 Fully document the short forms of the mode-changing commands - > Trevor Daniels https://sourceforge.net/p/testlilyissues/issues/5034 > http://codereview.appspot.com/313380043 > > > 185 RhythmicStaff squishing chords should produce single notes - Trevor > Daniels https://sourceforge.net/p/testlilyissues/issues/185 > http://codereview.appspot.com/6495107 > > > Review: > > > 5040 Let \alterBroken tweak ties again - David Nalesnik > https://sourceforge.net/p/testlilyissues/issues/5040 > http://codereview.appspot.com/319160043 > > > 5039 Replace \set Staff.instrumentName with \with form in doc examples > - James Lowe https://sourceforge.net/p/testlilyissues/issues/5039 > http://codereview.appspot.com/313400043 > > > 4509 Enhancement: automatically engrave lyric extenders - Alexander > Kobel https://sourceforge.net/p/testlilyissues/issues/4509 > http://codereview.appspot.com/313240043 > > > New: > > > 5042 Web: GSoC: Add openLilyLib project suggestion - Urs Liska > https://sourceforge.net/p/testlilyissues/issues/5042 > http://codereview.appspot.com/311570043 > > > 5041 Using eq? on numbers is undefined behavior - David Kastrup > https://sourceforge.net/p/testlilyissues/issues/5041 > http://codereview.appspot.com/314300043 > > > 5038 Web: Review GSoC page introduction - Urs Liska > https://sourceforge.net/p/testlilyissues/issues/5038 > http://codereview.appspot.com/315410043 > > > Waiting: > > > 4600 Let notes/rests suppress multi-measure rest grobs - Dan Eble > https://sourceforge.net/p/testlilyissues/issues/4600 > http://codereview.appspot.com/265160043 > Would you add 3830 Documentation for \offset is required https://sourceforge.net/p/testlilyissues/issues/3830/ https://codereview.appspot.com/319150043/ Thanks, David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES - Countdown for Tuesday January 24
On Tue, Jan 24, 2017 at 7:38 AM, James wrote: > Hello David, > > On Tue, 24 Jan 2017 07:05:24 -0600 > David Nalesnik wrote: > >> > >> >> Would you add >> >> 3830 Documentation for \offset is required >> https://sourceforge.net/p/testlilyissues/issues/3830/ >> https://codereview.appspot.com/319150043/ > > > > For anything to appear on my PATCH countdown (and test) 'radar' the > Status field == 'Started' and Patch == 'New'. > > In this case Issue 3830 had a Status == 'Accepted'. > > I have changed this Status manually, although if you use git-cl this > does (should do) this for you automatically, else you just need to > change this 'Status' field to 'Started' manually if you are entering > issues manually. > It wasn't done for me by git-cl, so I'll make a note to check in the future. Thanks! David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] no-outline-stencil backend property
Knut Petersen writes: > Hi David! > >> What a steaming heap of something. So your code would likely have >> worked in LilyPond 2.16. I think it would make sense to create a new >> type of stencil expression explicitly intended to bypass >> outlining. Probably by just containing _two_ stencils: one for >> typesetting, one for outlining. That would make for a much more >> transparent manner of programming things like that. > > There's no need for two stencils. That's what you claim. And then you use no-outline on your stencil, and use \with-dimension in order to stack this with another stencil that has just a box outline (one that survives into both dimensions as well as outline). I still count two. > I propose to include the attached code. Which completely _drops_ any outline. So if you want a different outline, you need to combine this with some stencil that has an outline but no ink. How do you remove the ink from arbitrary stencils? You can't. So you are tied down to use this trick in connection with stencils that insist on having an outline but no ink. Really, that makes little sense. If we are going to need two stencils anyway in order to make use of dropping an outline (and the positioning for stencils with _empty_ rather than point-stencil outline is _very_ weird), we might as well let our new stencil component take two stencils. One for the inking, one for the outline (and for the resulting dimension, I would guess). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3830: Document \offset command (issue 319150043 by david.nales...@gmail.com)
David,
Thanks for doing this - I know how hard it is to add a large entry in
the NR (and that is coming from a Native English speaker).
My comments below are, I hope, constructive.
Anything I can do to help you, let me know.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2514
Documentation/notation/changing-defaults.itely:2514: Properties can be
set to new values with the @code{\override},
Bearing in mind my not-very-deep understanding of LP, the preceding
paragraphs talk about both context and grob properties as being distinct
from one another and how 'grob properties' are just properties of a
context's own 'grob definition'. Then explains how 'grob definitions'
and 'context properties' are manipulated using different commands - i.e.
\override and \revert - where as 'context properties' are manipulated
with \set and \unset.
Which is the \offset for? One, the other, both?
This matters only because a user just looking up the \offset command
just get's the explanation that it is just 'Properties' and it is
ambiguous (at least to me). While we can show with examples, I think we
can improve this opening para.
I think, therefore it would be helpful to imply this in the opening para
(with words like 'Both Grob properties and context definitions can be
set to new ... etc.' or 'While it is possible to set [Grob
definitions|Context properties] with the @code{\overrride} ... etc.'
I'd be happy to make some grammatical suggestions but as I don't know
which of the three possible cases this command affects I am loathe to
waste everyone's time by guessing.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2522
Documentation/notation/changing-defaults.itely:2522: [-]\offset
@var{property} @var{offsets} @var{item}
'Displacements' is not the right word - you 'displace' one object/thing
by imposing on it (in it) another 'object/thing' - both things have to
exist at once for the displacement to happen, this is as distinct from
'replace'). We're not doing that here. We're simply moving the 'thing'
to another/different location from it's expected location.
I think 'offset-value' works, that implies a number or 'group' of
numbers (to us lesser mortals who don't know what alists and those
things with dots in between the two numbers and/or hash signs are called
:).
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2535
Documentation/notation/changing-defaults.itely:2535: The leading hyphen
may only be used with the @code{\tweak} form of the
'The leading ... ' or 'A leading ...' - again pardon my limited LP
knowledge if it is obvious.
However, I think this one sentence needs to be moved to an @knownissues
as this seems like some limitation that maybe able to be improved in the
future? Again, users look at @knownissues for these kinds of 'funnies'.
Also it would be useful to show an @example of the '\tweak' form, as -
unless I missed it - you don't show a '\tweak' example with '\offset' in
this edit at all.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2544
Documentation/notation/changing-defaults.itely:2544:
I am a bit worried that, thinking about users like me, that we're
starting to be a bit 'programmerish' in some of these following bullets.
I also think that, with a bit more insight for me, I may be able to help
you incorporate the bullets in the text with some examples.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2549
Documentation/notation/changing-defaults.itely:2549: each grob in
@rinternals{All layout objects}.
Does that mean that if these properties do not, that just mean that the
\offset command is redundant (i.e. a user should just use '\set' or
'\override'? Perhaps we could show an @example with two properties one
that has and one that doesn't have one to show that nothing changes? An
example of a property that doesn't have a default would help educate a
user when they look up the two layout objects in our examples for
themselves to see that one does and and one does not.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2555
Documentation/notation/changing-defaults.itely:2555:
Again I think this a bit 'talking through the code' (what's a callback?)
an @example showing something that doesn't have a numerical value and
that doesn't changing when using the \offset command would be
illustrative - assuming we're not going to thrown up errors during
lilypond-book compilation of the @example.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2558
Documentation/notation/changing-def
Re: Issue 3830: Document \offset command (issue 319150043 by david.nales...@gmail.com)
Thanks so such for the detailed review! Will post a patch update in the
near future.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2514
Documentation/notation/changing-defaults.itely:2514: Properties can be
set to new values with the @code{\override},
On 2017/01/24 14:36:08, pkx166h wrote:
Bearing in mind my not-very-deep understanding of LP, the preceding
paragraphs
talk about both context and grob properties as being distinct from one
another
and how 'grob properties' are just properties of a context's own 'grob
definition'. Then explains how 'grob definitions' and 'context
properties' are
manipulated using different commands - i.e. \override and \revert -
where as
'context properties' are manipulated with \set and \unset.
Which is the \offset for? One, the other, both?
This matters only because a user just looking up the \offset command
just get's
the explanation that it is just 'Properties' and it is ambiguous (at
least to
me). While we can show with examples, I think we can improve this
opening para.
I think, therefore it would be helpful to imply this in the opening
para (with
words like 'Both Grob properties and context definitions can be set to
new ...
etc.' or 'While it is possible to set [Grob definitions|Context
properties] with
the @code{\overrride} ... etc.'
Will clarify that it's _grob_ properties only. I like the "while..."
construction.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2522
Documentation/notation/changing-defaults.itely:2522: [-]\offset
@var{property} @var{offsets} @var{item}
On 2017/01/24 14:36:08, pkx166h wrote:
'Displacements' is not the right word - you 'displace' one
object/thing by
imposing on it (in it) another 'object/thing' - both things have to
exist at
once for the displacement to happen, this is as distinct from
'replace'). We're
not doing that here. We're simply moving the 'thing' to
another/different
location from it's expected location.
Though see here
(https://www.merriam-webster.com/dictionary/displacement):
"the difference between the initial position of something (as a body or
geometric figure) and any later position"
I think 'offset-value' works, that implies a number or 'group' of
numbers (to us
lesser mortals who don't know what alists and those things with dots
in between
the two numbers and/or hash signs are called :).
I'm happy to use "offset-value" though!
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2535
Documentation/notation/changing-defaults.itely:2535: The leading hyphen
may only be used with the @code{\tweak} form of the
On 2017/01/24 14:36:08, pkx166h wrote:
'The leading ... ' or 'A leading ...' - again pardon my limited LP
knowledge if
it is obvious.
However, I think this one sentence needs to be moved to an
@knownissues as this
seems like some limitation that maybe able to be improved in the
future? Again,
users look at @knownissues for these kinds of 'funnies'. Also it would
be useful
to show an @example of the '\tweak' form, as - unless I missed it -
you don't
show a '\tweak' example with '\offset' in this edit at all.
Yes, I give a number of examples with the "tweak" form. The "tweak"
form doesn't explicitly use "\tweak". As I explained above, the effect
of the \offset command is to create a tweak when the last argument is a
musical expression.
The presence/absence of the leading hyphen is exactly analogous to the
actual \tweak command. So I can't consider it a known limitation unless
it is a known limitation of \tweak.
I'll add a comment which stresses that the syntax of \offset in its
"tweak" form is modeled after \tweak itself.
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2539
Documentation/notation/changing-defaults.itely:2539: @code{\once} or
@code{\temporary} and reverted by using @code{\revert}
On 2017/01/23 23:52:54, thomasmorley651 wrote:
Does \undo work?
If so, please mention it as well.
Will check that out. Thanks!
https://codereview.appspot.com/319150043/diff/1/Documentation/notation/changing-defaults.itely#newcode2544
Documentation/notation/changing-defaults.itely:2544:
On 2017/01/24 14:36:09, pkx166h wrote:
I am a bit worried that, thinking about users like me, that we're
starting to be
a bit 'programmerish' in some of these following bullets.
Yeah, sorry. I'll try to clarify. But at the end of the day, this is
always going to be somewhat technical -- which is why it doesn't belong
in the LM :)
I also think that, with a bit more insight for me, I may be able to
help you
incorporate the bullets in the text with some examples.
https://codereview.appspot.co
Re: [PATCH] no-outline-stencil backend property
Am 24.01.2017 um 14:49 schrieb David Kastrup: What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. Probably by just containing _two_ stencils: one for typesetting, one for outlining. That would make for a much more transparent manner of programming things like that. There's no need for two stencils. That's what you claim. And then you use no-outline on your stencil, yes, here only expr_ is extended, it's still one stencil and use \with-dimension in order to stack this with another stencil that has just a box outline (one that survives into both dimensions as well as outline). I still count two. Why should I use with-dimension? The original stencil and its dimensions are unchanged and will be used in the stencil interpreter. no-outline() hides the dimensions from the code in stencil-integral.cc, but they are still present and the stencil interpreter uses them. I propose to include the attached code. Which completely _drops_ any outline. So if you want a different outline, you need to combine this with some stencil that has an outline but no ink. How do you remove the ink from arbitrary stencils? You can't. So you are tied down to use this trick in connection with stencils that insist on having an outline but no ink. David, this is NO-outline code. It' not a fake-some-arbitrary-outline-stencil. The code is useful for e.g. whiteout, watermarks etc. Define a stencil as usual, color it, scale it, whatever else. Just mark a stencil x with x.no_outline(); The result is: -> the outline is completely ignored in stencil_traverser(), so no collisions are detected. -> the stencil is drawn in interpret_stencil_expression() as it would be drawn without the no_outline layer. That's the intended use. It's probably much faster than the current solution with a transparent stencil, dimensions forced to zero and delayed evaluation. It is short, therefore easy to understand, and it is elegant. Really, that makes little sense. Think again. Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] no-outline-stencil backend property
Knut Petersen writes: > Am 24.01.2017 um 14:49 schrieb David Kastrup: >> What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. Probably by just containing _two_ stencils: one for typesetting, one for outlining. That would make for a much more transparent manner of programming things like that. >>> There's no need for two stencils. >> That's what you claim. And then you use no-outline on your stencil, > yes, here only expr_ is extended, it's still one stencil >> and >> use \with-dimension in order to stack this with another stencil that has >> just a box outline (one that survives into both dimensions as well as >> outline). I still count two. > Why should I use with-dimension? The original stencil and its dimensions > are unchanged and will be used in the stencil interpreter. no-outline() hides > the dimensions from the code in stencil-integral.cc, but they are still > present > and the stencil interpreter uses them. You wanted to use the equivalent of \with-dimensions #'(0 . 0) #'(0 . 0) and the C++ code for no-outline delivers the equivalent of \with-dimensions #'(+inf.0 . -inf.0) #'(+inf.0 . -inf.0) . So you cannot use it in the described manner without stacking an empty box on. Which is pretty much the only stencil without ink but with an outline. So this contortion works only for putting a rectangular outline onto the ink of some stencil, and even then, you need to juggle with several expressions. >>> I propose to include the attached code. >> Which completely _drops_ any outline. So if you want a different >> outline, you need to combine this with some stencil that has an outline >> but no ink. How do you remove the ink from arbitrary stencils? You >> can't. So you are tied down to use this trick in connection with >> stencils that insist on having an outline but no ink. > > David, this is NO-outline code. It' not a > fake-some-arbitrary-outline-stencil. Well, that is my complaint, isn't it? > Define a stencil as usual, color it, scale it, whatever else. Just > mark a stencil x with x.no_outline(); > > The result is: > -> the outline is completely ignored in stencil_traverser(), > so no collisions are detected. When skylines are involved. What dimensions are used when skylines are disabled? > -> the stencil is drawn in interpret_stencil_expression() as > it would be drawn without the no_outline layer. You'll find that the positioning of stencils with empty intervals as their dimensions can be somewhat quirky. > That's the intended use. It's probably much faster than the current > solution with a transparent > stencil, dimensions forced to zero and delayed evaluation. It is > short, therefore easy to understand, > and it is elegant. > >> Really, that makes little sense. > Think again. I did. I don't see why we need a specific expression for providing a null-stencil (rather than, say, a point-stencil) as the only permissable and hardwired traversal expression when we can just make the specification of the expression to be used for outlining explicit. And I don't see what would be so terrible if you had to do the equivalent of no-outline-markup = \markup \with-outline "" \etc (or the equivalent for a stencil) in order to get your \no-outline function. We have a function that makes some whiteout footprint by drawing a string repeatedly. What's wrong with being able to use that whiteout footprint for positioning while using the actual (non-whiteout) stencil for the actual placement? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] no-outline-stencil backend property
Knut Petersen writes: > Am 24.01.2017 um 14:49 schrieb David Kastrup: >> What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. Probably by just containing _two_ stencils: one for typesetting, one for outlining. That would make for a much more transparent manner of programming things like that. >>> There's no need for two stencils. >> That's what you claim. And then you use no-outline on your stencil, > yes, here only expr_ is extended, it's still one stencil >> and >> use \with-dimension in order to stack this with another stencil that has >> just a box outline (one that survives into both dimensions as well as >> outline). I still count two. > Why should I use with-dimension? The original stencil and its dimensions > are unchanged and will be used in the stencil interpreter. no-outline() hides > the dimensions from the code in stencil-integral.cc, but they are still > present > and the stencil interpreter uses them. > >>> I propose to include the attached code. >> Which completely _drops_ any outline. So if you want a different >> outline, you need to combine this with some stencil that has an outline >> but no ink. How do you remove the ink from arbitrary stencils? You >> can't. So you are tied down to use this trick in connection with >> stencils that insist on having an outline but no ink. > > David, this is NO-outline code. It' not a fake-some-arbitrary-outline-stencil. > > The code is useful for e.g. whiteout, watermarks etc. Define a stencil as > usual, > color it, scale it, whatever else. Just mark a stencil x with x.no_outline(); > > The result is: > -> the outline is completely ignored in stencil_traverser(), > so no collisions are detected. > -> the stencil is drawn in interpret_stencil_expression() as > it would be drawn without the no_outline layer. Sort of complementary to transparent-stencil (which is outline/dimension-only, no ink). I think I'd prefer to cast both in terms of the same primitive. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] no-outline-stencil backend property
Knut Petersen writes: > Am 24.01.2017 um 14:49 schrieb David Kastrup: >> What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. Probably by just containing _two_ stencils: one for typesetting, one for outlining. That would make for a much more transparent manner of programming things like that. >>> There's no need for two stencils. >> That's what you claim. And then you use no-outline on your stencil, > yes, here only expr_ is extended, it's still one stencil >> and >> use \with-dimension in order to stack this with another stencil that has >> just a box outline (one that survives into both dimensions as well as >> outline). I still count two. > Why should I use with-dimension? The original stencil and its dimensions > are unchanged and will be used in the stencil interpreter. no-outline() hides > the dimensions from the code in stencil-integral.cc, but they are still > present > and the stencil interpreter uses them. Take a look at the proposed Tracker issue: 5043 (https://sourceforge.net/p/testlilyissues/issues/5043/) Rietveld issue: 319170043 (https://codereview.appspot.com/319170043) Issue description: Define markup command \with-outline Also contains commits: Use ly :stencil-outline instead of transparent-stencil Implement ly :stencil-outline separating ink/metrics You'll find that your proposed no-outline can be done as (ly:stencil-outline stencil empty-stencil) Which probably is more prone to strange positioning (as it does not make any space at all and I am not sure that it will always properly translate to a reasonably correct position) than is (ly:stencil-outline stencil point-stencil) which will ask for padding. So you have the option to experiment, easily. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3830: Document \offset command (issue 319150043 by david.nales...@gmail.com)
I've posted an extensive rewrite which hopefully addresses all the concerns. I think the result is a lot more user-friendly. Note that I did not change the argument-name "offsets". My preference would be to use "displacements" here, because I think it is exactly expressive of its use. The documentation of \shape in the NR uses displacements. In second place would be "offsets." (Interestingly, the listing of "shape" in Available Music Functions uses "offsets," in contrast with the NR documentation. I suppose I'm responsible for the function docstring. IIRC, Trevor wrote the \shape documentation.) I've left it as-is for the moment, to invite other opinions. https://codereview.appspot.com/319150043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3830: Document \offset command (issue 319150043 by david.nales...@gmail.com)
Question:
How do I get a backslash in @subsubsubheading{} ?
The literal symbol doesn't show up, and @backslashchar{} displays
@backslashchar{}
https://codereview.appspot.com/319150043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3830: Document \offset command (issue 319150043 bydavid.nales...@gmail.com)
david.nales...@gmail.com wrote Tuesday, January 24, 2017 10:57 PM
> Question:
>
> How do I get a backslash in @subsubsubheading{} ?
>
> The literal symbol doesn't show up, and @backslashchar{} displays
> @backslashchar{}
>From memory it's @bs{}.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3830: Document \offset command (issue 319150043 by david.nales...@gmail.com)
On 2017/01/24 23:32:51, t.daniels_treda.co.uk wrote:
mailto:david.nales...@gmail.com wrote Tuesday, January 24, 2017 10:57
PM
> Question:
>
> How do I get a backslash in @subsubsubheading{} ?
>
> The literal symbol doesn't show up, and @backslashchar{} displays
> @backslashchar{}
From memory it's @bs{}.
Trevor
Thaat's it!
Thanks, Trevor.
David
https://codereview.appspot.com/319150043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
