> Hi all & Happy New Year, Hi and happy new year!
> I’m seeing that in version 2.24 the built-in \rounded-box always paints a
> white interior, which looks pretty rough on colored/ivory paper.
> I’d like to flip the default to transparent while keeping an optional fill.
>
> I am trying to build a development version of lilypond to test it.
>
> In the meantime, I created a test file to show the outcome of the current
> version and the outcome of my proposed change.
>
> Check the attached files and let me know if you'd like to keep the default
> behavior where the function rounded-box always produces a white background
> or is it ok to make it transparent by default?
This is something that bugged me for some time now. Essentially we have a
`ly:round-filled-box`, but no `ly:round-box`. Here we are kind of faking such
behaviour by printing a white box inside a box. And there are other places in
code where things like boxes are composed of line stencils, so there seems to
be a reasonable demand for a `ly:round-box` function.
Now, I guess the reason why we don’t have this is that the postscript
implementation abuses the blot diameter for the corner radius. So while it is
easy to adapt the implementation to not fill the rects corner radius and line
thickness would be linked.
So as it is there is no current postscript implementation for such a kind of
box, and creating one would require a lot of understanding how current
procedure works and making sure to match behaviour. Note that on the svg
backend `ly:round-box` will simply create a filled svg `rect` element. It
should thus be reasonably simple to adapt this to create a transparent box
with just a stroke. In fact the implementation (output-svg.scm:574) already
appears to contain commented code for that purpose.
Now, I guess once the postscript-backend is replaced by cairo-backend it
should thus be really straightforward to allow for unfilled boxes. Until then a
proper implementation would require some postscript code.
Now, what your code is doing is to recreate this stuff using paths, which is
possible, but should probably rather be part of the backend in future. After
all your code forces svg-backend to use a path even though it don’t need to.
@Werner: The issue you’ve seen is caused by a weird interpretation of the
corner-radius. As roundness is simply implemented using blob diameter the
rounded box stencil function does not take corner radius, but blot diameter.
`rounded-box` simply passes the `corner-radius` as blob diameter. But since
diameter = 2*radius this actually leads to half the corner radius given. E.g.
\markup\filled-box #'(0 . 1) #'(0 . 1) #0.5
will not create a circle, blob diameter needs to be 1:
\markup\filled-box #'(0 . 1) #'(0 . 1) #1
Of course this is very much a bug in the implementation of `rounded-box`, but
changing this is of course is going to cause issues in a lot of old code, so
it is probably better to live with the confusion (or rather: would it be
sensible to rename `corner-radius` to `corner-diameter` using convert-ly and
then having default `corner-radius` to `corner-diameter / 2` or something?).
So the immediate fix would be to include this wrong interpretation of corner-
radius in the non-filled code by changing line 82 from
(radius (min (+ ideal-blot half-line) ...)
to
(radius (min (+ (* ideal-blot 0.5) half-line) ...)
Also in the filled box code (which is copied from `rounded-box-stencil`)
contains a similar missconception: Here we have the bound
(ideal-blot (min blot (/ min-ext 2)))
which makes sense for the blot radius, but for the diameter it should be of
course
(ideal-blot (min blot min-ext))
This is the reason why `rounded-box` will at most produce a round corner over
a quarter of the possible space (and not half, which should be the true
limit):
% most that is possible
\markup\override #'(corner-radius . 10) \rounded-box "."
% should be possible
\markup \filled-box #'(-0.5 . 1.3) #'(0 . 1.4) #10
Cheers,
Tina
signature.asc
Description: This is a digitally signed message part.
