Re: How to prevent ly:stencil-rotate to modify dimensions

[Torsten Hämmerle]

David Kastrup wrote
>> And, additionally, it is perfectly common for a (true) slanted/italic
>> character to protrude out of its box.
> 
> So?

Ahm, yes, of course. Otherwise, you'd never get a decent letter-spacing
without thousands of kerning exceptions. 

As a last attempt, this is an example of a real-life italic sort (in this
case a ligature) where you can clearly see the the groove protruding:
 
If you still don't believe me, I'll have to accept that.


In modern computer fonts, you still basically have the same system
(FontForge metrics of Century Schoolbook L Italic with kerning removed):

 

As LilyPond doesn't know slanted bounding boxes (just as in the olden days,
see above), slanted letters often have to protrude in order to get the
desired letter-spacing.




David Kastrup wrote
> It turns out that
> 
> \markup \box \with-dimensions-from \italic "This is a sample text" \null
> \markup \box \with-dimensions-from \italic \line { This is a sample text }
> \null
> \markup \box \with-dimensions-from \line \italic { This is a sample text }
> \null
> 
> has only the first box slightly larger: so in either of the two cases
> below, text spaces appears to be done by LilyPond based on the
> dimensions of the individual words (and disregarding the font in use)
> while the first line uses Pango(?) for rendering, producing a longer
> result.
> 
> Serious case of "huh" here.

Yup. But in the end, it's only a minimal deviation, and in typography and
music engraving there's the rule "If you don't see a difference, there is
none". :)
In hot metal or early photo typesetting times, a quad was divided in about
10 to 20 units (depending on the system), fine tuning was done by stuffing
sandwich paper in. So, all in all, we're well off, aren't we?.

That's close enough for jazz ;)

All the best
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[David Kastrup]

Torsten Hämmerle  writes:

> David Kastrup wrote
>> Torsten Hämmerle <
>
>> torsten.haemmerle@
>
>> > writes:
>> [...]
>>> Yes, I know, but this code was meant for text in the first place and it's
>>> quite common for slanted characters to stick out of their bounding boxes
>>> to
>>> the left to the right. Unfortunately, there are no slanted bounding boxes
>>> (the are always upright"
>>> But the main reason behind is that 
>>> \slanted "one two three" 
>>> should give the same result as 
>>> \slanted { "one" "two" "three" }
>> 
>> Uh, no?
>> 
>> \slanted "one two three"
>> 
>> should likely give the same result as
>> 
>> \slanted \line { "one" "two" "three" }
>> 
>> but
>> 
>> \slanted { "one" "two" "three" }
>> 
>> is exactly equivalent to
>> 
>> { \slanted "one" \slanted "two" \slanted "three" }
>> 
>> and is connected with unslanted spaces.
>
> Sorry for my misleading wording.
> When saying "should give the same result" what I really meant was "should
> produce the same visual result".
> If I had widened the resulting stencil in order to prevent "slanted" text
> stick out to the left and the right, this would have resulted in a wider
> spacing when applied to separate chunks.
>
> And, additionally, it is perfectly common for a (true) slanted/italic
> character to protrude out of its box.

So?


> David Kastrup wrote
>>> and when separately applying \slanted to "one", "two", and "three", a
>>> widened box would lead to a wider spacing.
>> 
>> This _is_ separately applying \slanted to "one", "two", and "three".
>
> Yes, it certainly is, that's why I mentioned it. But it should not lead to a
> wider spacing, exactly like 
> \italic "This is a sample text" or \italic \line { This is a sample text }
> and
> \italic { This is a sample text }
> will have visually identical spacing

It turns out that

\markup \box \with-dimensions-from \italic "This is a sample text" \null
\markup \box \with-dimensions-from \italic \line { This is a sample text } \null
\markup \box \with-dimensions-from \line \italic { This is a sample text } \null

has only the first box slightly larger: so in either of the two cases
below, text spaces appears to be done by LilyPond based on the
dimensions of the individual words (and disregarding the font in use)
while the first line uses Pango(?) for rendering, producing a longer
result.

Serious case of "huh" here.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[Torsten Hämmerle]

David Kastrup wrote
> Torsten Hämmerle <

> torsten.haemmerle@

> > writes:
> [...]
>> Yes, I know, but this code was meant for text in the first place and it's
>> quite common for slanted characters to stick out of their bounding boxes
>> to
>> the left to the right. Unfortunately, there are no slanted bounding boxes
>> (the are always upright"
>> But the main reason behind is that 
>> \slanted "one two three" 
>> should give the same result as 
>> \slanted { "one" "two" "three" }
> 
> Uh, no?
> 
> \slanted "one two three"
> 
> should likely give the same result as
> 
> \slanted \line { "one" "two" "three" }
> 
> but
> 
> \slanted { "one" "two" "three" }
> 
> is exactly equivalent to
> 
> { \slanted "one" \slanted "two" \slanted "three" }
> 
> and is connected with unslanted spaces.

Sorry for my misleading wording.
When saying "should give the same result" what I really meant was "should
produce the same visual result".
If I had widened the resulting stencil in order to prevent "slanted" text
stick out to the left and the right, this would have resulted in a wider
spacing when applied to separate chunks.

And, additionally, it is perfectly common for a (true) slanted/italic
character to protrude out of its box.



David Kastrup wrote
>> and when separately applying \slanted to "one", "two", and "three", a
>> widened box would lead to a wider spacing.
> 
> This _is_ separately applying \slanted to "one", "two", and "three".

Yes, it certainly is, that's why I mentioned it. But it should not lead to a
wider spacing, exactly like 
\italic "This is a sample text" or \italic \line { This is a sample text }
and
\italic { This is a sample text }
will have visually identical spacing

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[Andrew Bernard]

Hi Torsten,

Thanks for the confirmation. That obviously explains the observed behaviour
very simply.

Not intuitive to me. I would have thought the stencil was rotated in this
case about its axis of symmetry. But I guess lily[ond does not really know
the item, just a stencil, is a 'circle' with special geometrical
properties. But once one knows about this, it's all very clear. Indeed. as
I thought, lilypond has not the mathematical nicety of Postscript in this
particular area (indeed, why should it? It is my mistake to think that.).


Andrew



On 12 March 2018 at 02:43, Torsten Hämmerle 
wrote:

>
>
> The bounding box of a circle actually is a square.
> But, after rotation, the resulting markup/stencil will have a new bounding
> box (with vertical height and horizontal width) large enough to contain the
> original bounding box (all objects are considered as boxes, no matter what
> their actual shape may be).
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[David Kastrup]

Torsten Hämmerle  writes:

> Hi Harm,
>
> Thanks for the background information, that'd be a valuable improvement.
>
>
> Thomas Morley-2 wrote
>> Using your code with the following example:
>> 
>> \markup
>>   \override #'(box-padding . 0)
>>   \box
>>   \override #'(slant-angle . 40)
>>   \slanted
>>   \musicglyph #"clefs.G"
>> 
>> results in a not matching boundingbox as well.
>
> Yes, I know, but this code was meant for text in the first place and it's
> quite common for slanted characters to stick out of their bounding boxes to
> the left to the right. Unfortunately, there are no slanted bounding boxes
> (the are always upright"
> But the main reason behind is that 
> \slanted "one two three" 
> should give the same result as 
> \slanted { "one" "two" "three" }

Uh, no?

\slanted "one two three"

should likely give the same result as

\slanted \line { "one" "two" "three" }

but

\slanted { "one" "two" "three" }

is exactly equivalent to

{ \slanted "one" \slanted "two" \slanted "three" }

and is connected with unslanted spaces.

> and when separately applying \slanted to "one", "two", and "three", a
> widened box would lead to a wider spacing.

This _is_ separately applying \slanted to "one", "two", and "three".

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[Torsten Hämmerle]

Hi Harm,

Thanks for the background information, that'd be a valuable improvement.


Thomas Morley-2 wrote
> Using your code with the following example:
> 
> \markup
>   \override #'(box-padding . 0)
>   \box
>   \override #'(slant-angle . 40)
>   \slanted
>   \musicglyph #"clefs.G"
> 
> results in a not matching boundingbox as well.

Yes, I know, but this code was meant for text in the first place and it's
quite common for slanted characters to stick out of their bounding boxes to
the left to the right. Unfortunately, there are no slanted bounding boxes
(the are always upright"
But the main reason behind is that 
\slanted "one two three" 
should give the same result as 
\slanted { "one" "two" "three" }
and when separately applying \slanted to "one", "two", and "three", a
widened box would lead to a wider spacing.



Thomas Morley-2 wrote
> With '(slant-angle . 70) it produces an error:

Yes, this is due to a mathematical problem (slant-angle must be less than
45°).
I didn't catch the exception and a slant angle beyond 20° seems questionable
from a typographical point of view, anyway.
Moreover, typographically, these automated and artificial font manipulations
are getting worse as the effect increases.

Slant angles above 45°, can be achieved by an extended version that calls
the code twice for a smaller angle.
The trigonometric functions are used here the keep proportions right (same
width, same height after slanting) - in most other situations one may get
away without this kind of calculations. 

Probably it'd be a good idea to provide a handy new markup command that can
shear an arbitrary graphical object by any angle (approaching 90° will
result in an infinite width, though) that also adapts the bounding box...

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[Thomas Morley]

2018-03-11 15:27 GMT+01:00 Torsten Hämmerle :
> Hi Harm,
>
> David is right - it's the bounding box being rotated. As bounding boxes can
> only have heights and widths in vertical and horizontal direction (there
> isn't even such a thing as an italic slant in LilyPond), the resulting new
> bounding box's height and width increases.
>
> I usually solve this problem by calculating the desired X-extent and
> Y-extent and set the stencil dimensions.
> In scheme, I use (ly:stencil-outline stencil point-stencil) to rotate
> stencil using the dimensions of point-stencil so that the bounding box isn't
> distorted .
>
> *Example:* I've created a fake slanted markup command by combining rotate,
> scale, rotate back, scale (because there is no shearing) that keeps the
> original stencil extent.
> Without stencil extent manipulations (using point-stencil dimensions etc.)
> the resulting bounding box would be ridiculously high and totally unusable.
>
> %%%
>
> \version "2.19.81"
>
> #(define-markup-command
>   (slanted layout props arg)
>   (markup?)
>   #:category font
>   #:properties ((slant-angle 12))
>   "Fake a slanted font"
>   (let* ((alpha-rad (* 0.5 (acos (tan (* (/ PI -180) slant-angle)
>   (alpha-deg (* (/ 180 PI) alpha-rad))
>   (stencil (if (markup? arg) (interpret-markup layout props arg)
> empty-stencil))
>   )
> (ly:stencil-outline
>   (ly:stencil-scale
>(ly:stencil-rotate
> (ly:stencil-scale
>  (ly:stencil-rotate (ly:stencil-outline stencil point-stencil) 45 0
> 0)
>  1 (* (tan alpha-rad)))
> (* (- alpha-deg)) 0 0)
>(* (sqrt 2) (cos alpha-rad)) (/ 0.5 (sqrt 0.5) (sin alpha-rad)))
>  stencil)))
>
>
> \markup \override #'(box-padding . 0) \box \slanted "Poor man’s slanted
> Text"
>
> poor-mans-slanted.png
> 
>
> This is a simple case just keeping the original extents, but in the end, the
> desired new bounding box (i.e. stencil extent) has to be calculated
> explicitly depending on the desired output, I couldn't find an automatic
> solution either.
> Simple trigonometric functions are all you need - it could be worse... ;)
>
> All the best,
> Torsten

Hi Torsten,

yep, David's explanation sounds very reasonable.

To give a bit background:
Currently we have several line-styles to print solid, dashed, and
dotted lines, as well as zigzag-, trill- and squiggle-lines.
They are available via setting the style-property for grobs supporting
a line-style or via different markup-commands.
Additionally not long ago David Nalesnik wrote ly:line-interface.

Though, there are two disadvantages:
Some line-styles may visible end too short because there is no room to
add another item like a dot-, dash-, trillelement, without any
possibility to scale the line-elements accordingly. This holds
especially for the lines predefined in C++.
There is no other possibility for a user to create a new line-style
than doing it all from scratch.

So my thought was to write a scheme-line-interface with the
possibility to scale line-elements (if desired) and to provide a
simple method to create a new line-style.
This could be done by a user-provided init stencil (and probably
padding if wished) and let do the procedure all the rest.

Attached you'll find some exmple-images for a trill- and a clef-style-line.
With the clef-style-line the boundindbox-problem is very prominent.

Having a look at your code, I don't like all the trigonometrics. Guile
and LilyPond doesn't work nicely with them in special cases, so I
always try to avoid them in scheme. I was beaten by this before.
We nowadays have ly:angle, ly:directed and ly:length which serve me well.

Using your code with the following example:

\markup
  \override #'(box-padding . 0)
  \box
  \override #'(slant-angle . 40)
  \slanted
  \musicglyph #"clefs.G"

results in a not matching boundingbox as well.

With '(slant-angle . 70) it produces an error:

item-lines.ly:258:10: In procedure ly:stencil-scale in expression
(ly:stencil-scale (ly:stencil-rotate # 45 ...) 1 ...):
item-lines.ly:258:10: Wrong type (expecting real number):
7.00808368402012e-17-1.46441350735015i

Though, thanks a lot for your code!
It made me see that I need to find a method to reset the boundingboxes.

Something at the lines of
(ly:make-stencil
  whatever-stencil
  x-extent
  y-extent)

Where the challenge will be to get accurate values for x/y-extent,
ofcourse this was clear right from the start lol

Thanks,
  Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[Torsten Hämmerle]

Hi Andrew,

The bounding box of a circle actually is a square.
But, after rotation, the resulting markup/stencil will have a new bounding
box (with vertical height and horizontal width) large enough to contain the
original bounding box (all objects are considered as boxes, no matter what
their actual shape may be).

I've attached an image that demonstrates the growth of boxes: a circle with
square bounding box being rotated by 30 degrees and back, showing all the
bounding boxes involved (in colour).

Without outline/skyline analysis of the actual shape, LilyPond just sees
everything as boxes, exactly the way TeX does it and how it was done in hot
metal typesetting.

bb-rotation.png
  

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[Andrew Bernard]

Hi Torsten,

I think Harm and I would assume the bounding box for a circle is a square,
which is the root of the confusion. Why is it a rectangle for a circle?

Andrew
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[Torsten Hämmerle]

Hi Harm,

David is right - it's the bounding box being rotated. As bounding boxes can
only have heights and widths in vertical and horizontal direction (there
isn't even such a thing as an italic slant in LilyPond), the resulting new
bounding box's height and width increases.

I usually solve this problem by calculating the desired X-extent and
Y-extent and set the stencil dimensions.
In scheme, I use (ly:stencil-outline stencil point-stencil) to rotate
stencil using the dimensions of point-stencil so that the bounding box isn't
distorted .

*Example:* I've created a fake slanted markup command by combining rotate,
scale, rotate back, scale (because there is no shearing) that keeps the
original stencil extent. 
Without stencil extent manipulations (using point-stencil dimensions etc.)
the resulting bounding box would be ridiculously high and totally unusable.

%%%

\version "2.19.81"

#(define-markup-command
  (slanted layout props arg)
  (markup?)
  #:category font
  #:properties ((slant-angle 12))
  "Fake a slanted font"
  (let* ((alpha-rad (* 0.5 (acos (tan (* (/ PI -180) slant-angle)
  (alpha-deg (* (/ 180 PI) alpha-rad))
  (stencil (if (markup? arg) (interpret-markup layout props arg)
empty-stencil))
  )
(ly:stencil-outline
  (ly:stencil-scale
   (ly:stencil-rotate
(ly:stencil-scale
 (ly:stencil-rotate (ly:stencil-outline stencil point-stencil) 45 0
0)
 1 (* (tan alpha-rad)))
(* (- alpha-deg)) 0 0)
   (* (sqrt 2) (cos alpha-rad)) (/ 0.5 (sqrt 0.5) (sin alpha-rad)))
 stencil)))


\markup \override #'(box-padding . 0) \box \slanted "Poor man’s slanted
Text"

poor-mans-slanted.png
  

This is a simple case just keeping the original extents, but in the end, the
desired new bounding box (i.e. stencil extent) has to be calculated
explicitly depending on the desired output, I couldn't find an automatic
solution either.
Simple trigonometric functions are all you need - it could be worse... ;)

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[David Kastrup]

Thomas Morley  writes:

> Hi all,
>
> let's say I've a stencil, which I want to rotate around it's center.
> For the example below I choosed make-circle-stencil, because a circle
> center-rotated _should_ always look equal.
> Though, applying ly:stencil-rotate modifies the dimensions of said
> circle for degrees not equal to (* 90 n).
> (Made visible by boxing it)
>
> Why?

Because it is the rectangular bounding box that is getting rotated?  So
typically the covered area will increase unless you are rotating by
multiples of 90 degrees where the box covers the full bounding box after
rotation again.

> How to prevent?

No way that I know of.

> \markup
>   \override #'(box-padding . 0)
>   \box {
> \stencil
> #(make-circle-stencil 0.5 0.1 #f)
> \stencil
> #(ly:stencil-rotate (make-circle-stencil 0.5 0.1 #f) 10 0 0)
>   }

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to prevent ly:stencil-rotate to modify dimensions

[Andrew Bernard]

Hi Harm,

It's interesting to observe how the bounding box increases in size as you
increase the angle and then decreases again as you go to 90 degrees.

Clearly lilypond does not display the mathematical nicety of Postscript. As
to 'why?' - isn't this a bug or defect?

Andrew
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user