[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: markup-command boxing the real printed ink?
From: |
Thomas Morley |
Subject: |
Re: markup-command boxing the real printed ink? |
Date: |
Tue, 20 Apr 2021 16:39:24 +0200 |
Am Di., 20. Apr. 2021 um 15:45 Uhr schrieb David Kastrup <dak@gnu.org>:
>
> Valentin Petzel <valentin@petzel.at> writes:
>
> > Hello Harm,
> >
> > This is probably quite hard to do. Basically the problem here is that
> > Lilypond does not in fact know the actual extent of the stencil. So to
> > get that you’d somehow need to draw the stencil. So eighter you’d need
> > to implement a custom drawing routine for "drawing" stencils within
> > Lilypond, or you could try to do a function that takes a stencil,
> > creates a new book containing that stencil, you’d then postprocess
> > that file with a script that determines the actual extent and writes
> > it into an auxiliary file, which is then included and gives the first
> > function a value for overriding the extent.
>
> You do realise that LilyPond processes outlines? It would seem that
> what Harm is asking for is recalculating markup bounding box dimensions
> from its outline. That would seem to require some C++ code I think, but
> not at the low level you suggest. More like adding something similar to
> "with-outline" support to lily/stencil-integral.cc and
> lily/stencil-interpret.cc .
>
> --
> David Kastrup
We have the markup-command \with-outline.
Alas, it looks not like what I would need and tbh, I've no clue how to
use it, no example there.
$ git grep "with-outline"
lily/stencil-integral.cc: else if (scm_is_eq (head, ly_symbol2scm
("with-outline")))
lily/stencil-interpret.cc: else if (scm_is_eq (head,
ly_symbol2scm ("with-outline")))
lily/stencil.cc: scm_list_3 (ly_symbol2scm
("with-outline"),
scm/define-markup-commands.scm:(define-markup-command (with-outline
layout props outline arg)
scm/define-stencil-commands.scm: with-outline
scm/stencil.scm: ((eq? head 'with-outline) (interpret (cadr expr)))
shows no doc/code-example as well.
Anyway:
I stumbled across the problem while looking at
https://lists.gnu.org/archive/html/lilypond-user/2021-03/msg00187.html
There's the complain note-by-number note working nicely with the Scorlatti-font.
For testing, I took the font from https://github.com/OpenLilyPondFonts.
Further investigation showed Scorlatti-note-heads exceed the bounding
box. With this in mind I asked here.
Meanwhile I noticed that this holds for use in notemode as well (the
up-Stem is always a little off).
Same for lilyjazz from there. gonville is fine. Didn't test the others
This leads to the conclusion that this scorlatti-font is unusable.
Not sure whether there are free variants of these font out there.
Thanks,
Harm
- markup-command boxing the real printed ink?, Thomas Morley, 2021/04/20
- Re: markup-command boxing the real printed ink?, Valentin Petzel, 2021/04/20
- Re: markup-command boxing the real printed ink?, David Kastrup, 2021/04/20
- Re: markup-command boxing the real printed ink?, Valentin Petzel, 2021/04/20
- Re: markup-command boxing the real printed ink?, Jean Abou Samra, 2021/04/20
- Re: markup-command boxing the real printed ink?, Valentin Petzel, 2021/04/20
- Re: markup-command boxing the real printed ink?, David Kastrup, 2021/04/20
- Re: markup-command boxing the real printed ink?, Valentin Petzel, 2021/04/21
- Re: markup-command boxing the real printed ink?, David Kastrup, 2021/04/21
- Re: markup-command boxing the real printed ink?, Valentin Petzel, 2021/04/21
- Re: markup-command boxing the real printed ink?, David Kastrup, 2021/04/21
- Re: markup-command boxing the real printed ink?, Valentin Petzel, 2021/04/21