lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OT} Was "Re: Rounded beams"


From: David Kastrup
Subject: Re: [OT} Was "Re: Rounded beams"
Date: Fri, 18 Dec 2015 09:57:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

address@hidden writes:

> On Thu, 17 Dec 2015, Kieren MacMillan wrote:
>> I just read through the Essay in its entirety, and found nothing which
>> suggests to me that Lilypond ever sacrifices clarity or functionality
>> for "visual artistry”.
>
> That is not what I said.
>
> A focus on creating beautiful output does not imply "sacrificing" clarity
> or functionality.  On the contrary, it seems reasonable to guess that
> clarity and functionality are best served by beautiful output,

Only "beautiful" in the meaning of an absence of ugliness and
distractions.

I thought that the essay or other expositions feature a quote by either
de Saint-Exupéry or Mies van der Rohe (I forgot who) "Perfection is not
achieved when there is nothing more to add but when there is nothing
more to take away."  Interestingly, I don't find that quote in the
repository and consequently in either essay or web site.

It's basically the credo of typography, in some contrast to calligraphy.

> It seems strange that exactly straight beams in all cases without
> exception are good and necessary for LilyPond, if exact alignment of
> bar lines is bad and the avoidance of alignment is something to brag
> about.

One point of typography is to avoid distracting from the content by
creating distractions not inherent to the content.  In text typography,
an over-alignment of words is called "rivers" running through the page
and they are to be avoided.  The main problem with "avoidance of
alignment" in the form of exact notehead spacing is that it leads to
extremely irregular stem spacing.  One needs to balance several
conflicting visual goals here.

And so on.  There are precise reasons for the choices LilyPond makes: it
does not introduce randomness but rather heeds more variables than rigid
spacing would.

> And excluding the possibility of curved beams in all cases, even as a
> manual override for scores with special nonstandard needs, in the
> context of a tool that attempts to cover a wide range of other unusual
> notation cases, seems to be a sacrifice of "functionality" right
> there.  For what purpose is LilyPond making that sacrifice?

It's not a sacrifice but a choice.  Curved beams add no functionality
and require dealing with additional degrees of freedom in a manner that
cannot sensibly be automated.

> But don't claim that such a technical limitation is for our own good!

It is for the good of LilyPond doing its prescribed job well.  Even
given the existing set of graphical elements, LilyPond wants a lot of
improvement.  Creating an infinitely larger bag of things it is supposed
to deal with is not going to help.

> The statements that LilyPond doesn't do curved beams because users
> aren't smart enough to use such a feature wisely

Who is talking about users?  LilyPond is not smart enough to use such a
feature sensibly.  LilyPond is a tool for automated typesetting.  If you
want to have to control every single element, use InkScape.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]