Re: Regular Polygons

2024-06-08 Thread Werner LEMBERG


> Thankfully, it should be trivial to make the changes.  The question
> now is what reference glyph is the best?

If you have an argument, the shape should enclose it symmetrically
(more or less) – it is up to you how sophisticated the algorithm is to
do that in the visually most pleasing way (i.e., how near the
polygon's shape comes to the argument's bounding box).  If there is an
empty argument I suggest that you select a size that fits well with
surrounding text, again to your liking.  As soon as you provide a
Merge Request (and I really hope that you submit one!) we will most
certainly tell you whether the size are OK :-)


Werner


Re: Regular Polygons

2024-06-08 Thread Shane Brandes
Typically fonts use x-height as a general design parameter. I don't know if
you find that helpful in this interesting project, but it is a point of
possible useage.

Regards,
Shane Brandes

On Sat, Jun 8, 2024, 5:47 AM Aaron Hill  wrote:

> Thank you both, Werner and Valentin, for taking the time to look at my
> submission.
>
> When I was playing around with drawing shapes, I was thinking paper
> scale not text scale.  This was inspired by Paolo's desire to draw
> arbitrary arrows and things.
>
> Because of that, I presumed the end user would desire absolute sizing.
> Of course, as I continued playing with the markup command, I realized it
> probably should work similar to the built-in \triangle command.
>
> I love the idea of tying things to font-size, so the shapes are
> automatically responsive to changes in the surrounding context.  That
> simplifies the usage of the command since you just need to specify point
> count.  This also makes it behave similar to the other built-in shape
> functions.
>
> Thankfully, it should be trivial to make the changes.  The question now
> is what reference glyph is the best?  "A" is notably a letter in most
> fonts that tries to make the apex more prominent.  As a result, it could
> make the polygons appear a little too big.  "O" has a similar issue.
> These glyphs are optically oversized, so they look good.  Perhaps "H"
> will work.  I think it usually has a consistently flat top and bottom
> without any optical adjustments.  Mind you, I could just be overthinking
> things.  Nothing would stop me from sampling all uppercase letters and
> averaging them.
>
> Regardless, you both have given me plenty to think about.
>
>
> -- Aaron Hill
>
>


Re: Regular Polygons

2024-06-08 Thread Aaron Hill
Thank you both, Werner and Valentin, for taking the time to look at my 
submission.


When I was playing around with drawing shapes, I was thinking paper 
scale not text scale.  This was inspired by Paolo's desire to draw 
arbitrary arrows and things.


Because of that, I presumed the end user would desire absolute sizing.  
Of course, as I continued playing with the markup command, I realized it 
probably should work similar to the built-in \triangle command.


I love the idea of tying things to font-size, so the shapes are 
automatically responsive to changes in the surrounding context.  That 
simplifies the usage of the command since you just need to specify point 
count.  This also makes it behave similar to the other built-in shape 
functions.


Thankfully, it should be trivial to make the changes.  The question now 
is what reference glyph is the best?  "A" is notably a letter in most 
fonts that tries to make the apex more prominent.  As a result, it could 
make the polygons appear a little too big.  "O" has a similar issue.  
These glyphs are optically oversized, so they look good.  Perhaps "H" 
will work.  I think it usually has a consistently flat top and bottom 
without any optical adjustments.  Mind you, I could just be overthinking 
things.  Nothing would stop me from sampling all uppercase letters and 
averaging them.


Regardless, you both have given me plenty to think about.


-- Aaron Hill



Re: Regular Polygons

2024-06-08 Thread Werner LEMBERG


> I was playing around with drawing regular polygons, which led to
> creating a new markup command with several configurable options.
> (Some of these options are inherited via the built-in \polygon
> command.)
> 
> There might be a few things to tighten up, but I believe it is in a
> pretty workable state.  I wish optional parameters existed for
> markup commands.  If they did, then a user could just specify the
> number of sides and omit the size.  The default size would be
> something that matches the font height, so the shape would naturally
> fit in with the surrounding text.

Very nice!  The MusicXML standard supports an `enclosure-shape` attribute:

  
https://www.w3.org/2021/06/musicxml40/musicxml-reference/data-types/enclosure-shape/

It would be very helpful to have a function that makes the polygon
enclose a text string, similar to the `\box` markup command.

And I agree with Valentin that you should completely drop the size
argument, relying on the available markup scaling commands instead.


Werner



Re: Regular Polygons

2024-06-08 Thread Valentin Petzel
Hello Aaron,

I would think there is little actual need to specify the size as parameter. 
After all, you have the font-size proportion, using which you can control size 
by \fontsize ...

You’d simply need to replace size by (magstep font-size). Alternatively if you 
want to match text you could interpret some markup like "A" and derive the 
height from it. This way you automatically have the font-size incorporated.

Cheers,
Valentin

Am Freitag, 7. Juni 2024, 00:09:36 MESZ schrieb Aaron Hill:
> I was playing around with drawing regular polygons, which led to
> creating a new markup command with several configurable options.  (Some
> of these options are inherited via the built-in \polygon command.)
> 
> There might be a few things to tighten up, but I believe it is in a
> pretty workable state.  I wish optional parameters existed for markup
> commands.  If they did, then a user could just specify the number of
> sides and omit the size.  The default size would be something that
> matches the font height, so the shape would naturally fit in with the
> surrounding text.
> 
> 
> -- Aaron Hill



signature.asc
Description: This is a digitally signed message part.