Capitalized text
I am working on a grob for section labels. I want to recommend that the user encode the section name in title case (Coda), but I want LilyPond to render it in all caps (CODA) by default. Is there already a grob property to enable this transformation? I've hacked in a callback that calls string-upcase when my new grob is created, but this seems like a problem that ought to have a general solution. If this is not currently possible, would Text_interface::interpret_string() be the most appropriate place to implement it? Thanks, — Dan
Re: Is there any use for the 'char' stencil command?
Am Sonntag, dem 27.06.2021 um 20:11 +0200 schrieb Knut Petersen: > Hi everybody! > > We have a stencil command 'char'. Normally grep is a good friend, but > grepping for 'char' gives a looong list of possible matches even if you > add some restrictions ;-)) > > So I decided to try a brutal search method and changed the current > definition of 'char' to > > (define (char font i) (ly:error (_ "Unsupported stencil command > 'char'"))) > > in scm/output-ps.scm. But 'make doc' succeeded. So it's clear that we > do not use the 'char' stencil command during the generation of all our > docs. Otoh we certainly do not exercise every possible code path during > 'make doc'. > > Is the char stencil really an unused artifact that might be removed or > did I overlook something? I tried a bit of archeology and searching 'git log -p' for "char" (with quotation marks) leads to the following commits: https://gitlab.com/lilypond/lilypond/-/commit/c5d9ef8c7eaed663fabcd70742ba7a0e56cb337b https://gitlab.com/lilypond/lilypond/-/commit/e2c7a2ab964d7ab2b4d993634303327adf5e39f2 https://gitlab.com/lilypond/lilypond/-/commit/9505acaaf90190158f6b66b59da13db1454cddc4 So yes, probably unused. (FWIW, I didn't find any 'char in scm/) Jonas signature.asc Description: This is a digitally signed message part
Re: Is there any use for the 'char' stencil command?
On Sun, Jun 27, 2021 at 8:11 PM Knut Petersen wrote: > > Is the char stencil really an unused artifact that might be removed looks like it. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Is there any use for the 'char' stencil command?
Hi everybody! We have a stencil command 'char'. Normally grep is a good friend, but grepping for 'char' gives a looong list of possible matches even if you add some restrictions ;-)) So I decided to try a brutal search method and changed the current definition of 'char' to (define (char font i) (ly:error (_ "Unsupported stencil command 'char'"))) in scm/output-ps.scm. But 'make doc' succeeded. So it's clear that we do not use the 'char' stencil command during the generation of all our docs. Otoh we certainly do not exercise every possible code path during 'make doc'. Is the char stencil really an unused artifact that might be removed or did I overlook something? Knut
Re: Cairo
Hi Han-Wen,
I agree. Creating a new backend is actually fairly simple. Just copy
framework-ps.scm to framework-cairo.scm. That should be enough to get
you support for -dbackend=cairo. If you want, you can also copy
output-ps.scm, but that's not strictly necessary (anything that
populates the dispatch alist for the paper-outputter will work.)
I had a quick look at the C++ code. The global variables are a bit
concerning. As a start, you could put them into
class Cairo_context {
RefPtr cr;
...
}
this struct will then later be a natural candidate to create a smob
from. However, I wonder why you want to go through Scheme in the first
place, as the output mechanism (Cairo) lives in C++, while steering
the output goes through C++ as well (see paper-outputter.cc).
For the prototype, I think it would be better to insert the Cairo data
(Cairo::Context etc.) into Paper_outputter itself. Then, you can
intercept the Stencils directly in Paper_outputter::output_scheme.
Once that works, we can figure out something with inheritance to
factor out the cairo-specific code.
Hope this helps,
Of course your comments help, as do those of others here on the list that I
haven't (yet ) responded to.
I started with the Cairo project mainly because the license used by Ghostscript bothers me besides the repeatedly necessary adjustments to new Ghostscript versions. To integrate Ghostscript into Lilypond to the extent that it generates another intermediate format from the Postscript intermediate
format, from which the final format is then created, would make a license change for Lilypond necessary, which is neither generally desired nor feasible. An example of things we can't integrate into Lilypond as long as Ghostscript is necessarily involved is code that directly generates videos like
the one linked here.
The easiest step for me to start with Cairo was to go directly into ps/*,
scm/output-ps.scm and scm/framework-ps.scm and to program equivalents for the
postscript code normally generated there.I'll finish that without changing the
basic approach.
After that I'll look at how and where to integrate all this quite more
elegantly and efficiently into the existing code.
After that it's time for a merge request, so Werner will have to be patient for
a while ;-)
Thanks for the hint on paper-outputter.cc.
Knut
Re: Please review Pygments lexer and style
Benkő Pál writes: > Jean Abou Samra ezt írta (időpont: 2021. jún. > 24., Cs, 20:17): >> I'll style \longa in bold too. > > \longa is a duration, like 2 in c2; on the other hand 3 in \repeat > \unfold 3 or \time 3/4 is not a duration. now the 4 in \time 3/4 is > arguably a duration, but... No, it isn't. 3/4 is a fraction and passed as such into \time . A duration cannot be something like 5 while \time 3/5 is accepted by the parser (the time signature engraver will give you a warning because that's not really something LilyPond can make a lot of sense of). If you use 5 as a duration, it's the parser that already bombs out (though admittedly the lexer will treat it like 4, but then the lexer does not distinguish durations from integers in general). -- David Kastrup
Re: Please review Pygments lexer and style
Jean Abou Samra ezt írta (időpont: 2021. jún. 24., Cs, 20:17): > I'll style \longa in bold too. \longa is a duration, like 2 in c2; on the other hand 3 in \repeat \unfold 3 or \time 3/4 is not a duration. now the 4 in \time 3/4 is arguably a duration, but... p
Re: Obsolete labels
Am Samstag, dem 26.06.2021 um 15:09 +0200 schrieb Jonas Hahnfeld via Discussions on LilyPond development: > Hi all, > > while colorizing the labels (let me know what you think of the first > stage!), I noticed that there are some obsolete ones that should be > deleted: > > * Task: I *think* this comes from "Type: Task" on SourceForge and > never had issues. Slight correction: there was indeed one issue, but it was unlabeled some time ago: https://gitlab.com/lilypond/lilypond/-/issues/830 -> gone > * Cant_verify: As we don't do verification anymore, I don't think > there's much gain from labeling one open and two closed issues. Closed the one open issue as suggested by James 11 months ago. -> gone > * Frog: Does this still provide value? -> gone > Furthermore, the following labels have very few issues. I'd propose we > delete them because having less labels will make it easier to find the > right one: > > * Encoding: one closed issue about BOM signatures, fixed in 2.15.10 > * Dynamics: one open issue, title mentions dynamics > * Autochange: one open issue, "Enhancement: autochange improvements" > * Tablature: one open & one closed issue, titles mention tablatures -> all gone > Moreover, I find issues in Emmentaler, Font_handling and Glyph_handling > very confusing: While Emmentaler seems like a rather recent invention > of Werner and makes sense to me, Font_handling and Glyph_handling > overlap and I'd actually label some of the issues as Emmentaler- > related. I'd propose we merge these two labels, call it "Fonts", and > put into the description that everything related to Emmentaler should > go there. I did some archeology here, and back on SourceForge they were called "Font" and "Glyph" and both of them were used only for Emmentaler. The labels were renamed in November, probably while creating the new one for Emmentaler. That's exactly the reason why a bit more discussion cannot hurt here, to not end up in a situation with three overlapping labels. So the new situation is as follows: * Emmentaler: basically all issues that were labeled "Font" or "Glyph" on SourceForge, plus open ones that belong there * Font: support in LilyPond, including text fonts > Lastly, I don't like "-Wconversion" because it starts with a hyphen and > is very specific. Can we rename this to "Compiler warnings" or just re- > label the issues and MRs into Build and / or Maintainability? Renamed to "Compiler warning", re-assigned issues from "Warning", and added a bunch of labels for merge requests. > Once that's done, I'll try to distribute some category colors to the > remaining labels, right now I'm a bit overwhelmed. I put the same colors to: * Scripts: ABC2ly, MIDI2ly, MusicXML * "categories": Beaming, Build, Doc, Emmentaler, Font, Lyrics, MIDI, Partcombine, Regtest, SVG, Spacing, Syntax, Translation, Website I first though Ghostscript was another "category", but the four labeled issues seem more related to infrastructure; any objections to deleting it? "Other" now seems similarly misplaced, do we need it? > > Regards > Jonas signature.asc Description: This is a digitally signed message part
Re: Cairo
On Sat, Jun 26, 2021 at 10:52 PM Jonas Hahnfeld via Discussions on
LilyPond development wrote:
>
> Am Samstag, dem 26.06.2021 um 19:43 + schrieb Werner LEMBERG:
> > > No, it's definitely too soon for a merge request. A few
> > > stencils->cairo procedures need to be added, a bit of error
> > > handling
> > > (to prevent at least possible segfaults) is necessary, a bit of
> > > logical cleanup is desirable, etc.
> >
> > Well, you can start the commit message of the merge request with
> > 'WIP:'; this prevents execution of the CI stuff, AFAIK.
>
> No, it doesn't. There are ways to not run CI jobs for a particular
> commit, but I don't really see the point just for the sake of pushing
> the current demonstrator into a merge request.
>
> May I instead propose an incremental approach? Implementing a fully
> capable Cairo backend probably won't happen in a single MR, and making
> it the default will be even further down the road. I think for a first
> step the Cairo stuff needs to be optional and in a proper backend, not
> hacked into the current Postscript code. Then others can test, missing
> features can be added over time, and it's possible to evaluate further
> steps.
I agree. Creating a new backend is actually fairly simple. Just copy
framework-ps.scm to framework-cairo.scm. That should be enough to get
you support for -dbackend=cairo. If you want, you can also copy
output-ps.scm, but that's not strictly necessary (anything that
populates the dispatch alist for the paper-outputter will work.)
I had a quick look at the C++ code. The global variables are a bit
concerning. As a start, you could put them into
class Cairo_context {
RefPtr cr;
...
}
this struct will then later be a natural candidate to create a smob
from. However, I wonder why you want to go through Scheme in the first
place, as the output mechanism (Cairo) lives in C++, while steering
the output goes through C++ as well (see paper-outputter.cc).
For the prototype, I think it would be better to insert the Cairo data
(Cairo::Context etc.) into Paper_outputter itself. Then, you can
intercept the Stencils directly in Paper_outputter::output_scheme.
Once that works, we can figure out something with inheritance to
factor out the cairo-specific code.
Hope this helps,
Han-Wen
>
> Jonas
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
