[Guidolib-devel] Proposal for Locking down staff & system positions

[Henry F. <gui...@he...>]

I am exploring ways to lock down where staves are drawn on a “page” so that apps that use guido can know that the staff on an image is being drawn in the same place each time.

Following up on this, I’m thinking that we could add new parameters to lock down the x,y position of systems, so that they don’t shift with extended bounding boxes.

Here are some observations:

- You can lock down the distance between staves within a system by applying a dy to the upper staff of a pair of staves to be locked together.  A dy would need to be applied to each upper of a pair of staves to lock down all staves within a complete system.  (See staff2.gmn)

- Thus, it seems like the only thing we need to deal with is the position of each system.

- \systemFormat has a dx, but it only applies to the first system.

- it appears that each system is always at the left margin, except for when systemFormat has a dx set, which offsets JUST the first system.

- As an aside, in the code, “dy" on \newSystem is actually read, but it’s internally stored value (mSystemDistance) appears to be intentionally or unintentionally overwritten before it can be used.

What I propose:

TWO parameters:  One to lock the distance between successive systems, and one to lock the top left of the first system.

Some ideas:

#1)
\systemFormat<dy=3cm, lockfirst=yes> ← each successive system starts 3cm after the previous, and the first system is locked to the margin.

PROS: keeps system layout information in \systemFormat; CONS: \systemFormat’s “dy” applies to multiple systems, while its “dx” only applies to the first system; lockfirst is a new parameter.

#2)
\systemFormat<dy=1.1cm,dy=.5cm> …. \staff<4,dy=1.8cm> … ← the FIRST system is .5 cm down and 1.1 cm to the right from the top left margin, and the last staff of the system (labeled "4" in this case) says that the next staff (i.e., first staff of the next system) is 1.8cm down.

PROS: More consistent with existing use of “dy” and “dx” for both \systemFormat & \staff.  CONS: Moves some system layout info to the staff level.

Currently, my thinking is that option #2 would be less confusing to folks.

I would be willing to take a stab at implementing this.

Thoughts?

Cheers,
Henry



On Sep 6, 2014, at 8:31 PM, Henry Flurry <gui...@he...> wrote:

> I’m hoping to use GuidoLib for iOS apps.  Part of this depends upon the ability to create predictable images from GuidoLib.  So far, I’m generating text and interpreting it instead of making calls to the library for the elements.
> 
> Two issues have come up:
> 
> If in \staffFormat I set the staff size large, for instance if I’m trying to fill an image, the layout messes up.  Notes get crunched to the right side, etc.  I think I can get around this by using smaller “pages” and scaling it up, but I’ve not explored that yet.
> 
> Also, I would like to be able to place the staff at a known x,y, with a known width.  I have tried setting page margins to the page size in \pageFormat, high ledger lines will push the staff down.  Is it possible to get the staff at a known position and not have ledger lines adjust its vertical position?
> 
> Thanks!
> Henry Flurry
>