ABC scores - last line scaled larger

[gwyndaf]

Behaviour is reminiscent of an earlier issue.

Wichita_Lineman.cho.txt,
processed with -X --define pdf.kbdiagrams.show=right --config keyboard gives me
Wichita_Lineman_kbdiag_right.pdf

It's clear that the second line is scaled larger than the first. The split=0 workaround, used previously, also works here.

The issue also goes away if I have diagrams at the bottom (default): Wichita_Lineman_kbdiag_default.pdf

So, I wonder if the width of the diagrams column on the right is somehow affecting scaling calculations?

Behaviour observed with both release version 6.060 and dev _003.

[sciurius]

Can you try _026?

[gwyndaf]

Have you pushed it to github? Latest seems to be _025.

[sciurius]

It's _027 now.

[gwyndaf]

_027 seems to fix last line scaling, but with changed behaviour overall.

It looks like the first line/s are now scaled up to be the same size as the last line: Wichita_Lineman_027.pdf

Previously, I think the last line was scaled down to match the preceding lines.

Testing this against a few other songs confirms that scores now occupy more space than previously. For example:

Release 6.060:

Dev _027:

from:

{start_of_abc-keyboard: Verses + bridge melody}
scale=0.97
split=0
%%pagescale 0.9
%%maxshrink 0.85
X:1
M:4/4
K:C
L:1/8
|: "C"z e2 d cG F2 |"C" E"Cmaj7" [CE]3"Dm7" [DF]2"D#dim7" [_E_G][=E=G] | "C"z e2 d cG F2 | "C"E "C7"[EG]3 "B7"[_E_G]2 "Bb7"[DF]"A7"[^C=E] | 
"A7"z G2 F EDCc- |"Dm7" c3 A- A4 |"G7" z EF^F GC^DE |"C" C"C7" [CEG]3"Cdim7" [C_E_G]2"Dm7" [DF]"C"[C=E] :|
"F6" d4 c2 Ac- |"D#dim7" c4 z2 cd- |"Em7" d4 c2 GE- |"C7" E4 z2 c2 |
"F6" d4 c A2 c- |"D#dim7" c4 z4 |"Em7" z BBB B A2 G | "Dm7"z4 "G7"z4 !D.C.! ||

{end_of_abc}

[sciurius]

This is getting tough...

Image assets like ABC are processed into PDF objects at the beginning of the PDF output phase of the song. Some image assets (like ABC) are processed to a specific page width. On A4 paper with 40pt margins the page width is 515pt. If you place the diagrams to the right, the effective page width gets smaller, 449pt for a single column of keyboard diagrams. Smaller output with ABC generally means you get more staves with less measures.

But imagine the same asset to be used on the first 439pt page and on another 515pt page...

In dev_027 I changed to using the smaller width for processing the assets. I think a better approach is to use the normal page width and apply an additional scale (in this case 449/515 = 87%) to assets on the first page.

[gwyndaf]

Ah, that makes sense. I can see how ABC processing of a narrower page width (with _027) would force the score on to more lines.

Personally, I'm usually squeezing a short riff or motif score into a small space on a single-page sheet so, the more compact, the better (within reason) for my usage.

I'd certainly welcome what you suggest (ABC layout for wider page, then scale down), which I guess was the previous approach. That would save me some time-consuming re-tweaking of ABC layout parameters and scale values!

[sciurius]

Can you try dev_029? I hope I didn't break other images (fingers crossed...).

[gwyndaf]

Great. _029 behaving almost as previously/expected.

One observation: there's more space between staves than previously, although I can restore previous behaviour by including split=0:
Wichita_Lineman_split=1.pdf
Wichita_Lineman_split=0.pdf

However, it does mean that multi-page score are now spaced (vertically) more loosely than previously:
Don_t_Get_Around_Much_Anymore_6.060.pdf
Don_t_Get_Around_Much_Anymore git _029.pdf

I can see in the second (_029) that p2 stave height is a little greater than p1, because images are scaled up to full page width.

However, it looks like the stave-to-stave spacing is the same on both p1 and p2, which means p1 stave spacing is greater than previously, and disproportionately large. As it runs over two pages, the split=0 workaround won't work here.

I'm guessing it's maybe a need to reflect the scaling factor in vertical positioning/spacing measurements when the score is scaled down to fit alongside diagrams?

[sciurius]

True. I'll take a look.

You are aware that if you have a song with one staff on the first page and the other staff on the next page, the staffs will have different sizes? Do we want that?

[gwyndaf]

I noticed that larger p2 scaling with the Don't Get Around Much (_029) example, but it's just a test sample. Nearly all my scores are short motifs that fit within one page, so I don't have a strong view, but maybe err toward consistent scaling, even if narrower. There may be other users who use longer scores and have views on this.

Two possible arguments for continuation pages having the same scaling as the first page (I think that's current 6.060 behaviour):

1. Less cognitive friction. I think the difference in scaling might be enough to create a mental 'bump in the road' for the reader, who'll have to adjust to it as well as picking up after a (possible) page turn.
2. Layout efficiency. Potentially, continuation pages scaled at ~87% might allow for an additional stave on each page, reducing pages and page turns.

On the other hand, maybe there are established standards for readable score sizes? Although that's already compromised if p1 is scaled smaller.

I doubt it's worth the effort of achieving both consistent scaling and full-width continuation pages, when it's limited to the diagrams.show=right case. Possibly it would need two ABC passes, to create two sets of images, from which each line would have to be picked, positioned and scaled according to the effective width of the page it's being placed on. That doesn't sound like a nice job, so maybe best avoided!

[gwyndaf]

I'm not sure if this is related, but I noticed with dev_029 that a Lilypond score now seems to have more space beneath it.

Running the song source with default configs and pdf.diagrams.show=right suggests it's related to diagrams being on the right (the extra space doesn't occur with default diagram position):
Canon_in_D_diagrams-default.pdf
Canon_in_D_diagrams-right.pdf

Comparing the two side-by-side, I notice that the comment below the score has the same vertical positioning in each case. That maybe suggests that the scaled-down score (diagrams right) is still being allocated the same amount of vertical space as the unscaled one (diagrams bottom), rather than also scaling down the vertical size of the score area.

Having figured that out, it does now seem quite similar behaviour to the extra spacing between split ABC staves on pages with diagrams right.

[sciurius]

One of the recent changes (I suspect the "Centered chord" commit) introduced an error in the vertical spacing. I'll look into it.

[gwyndaf]

Another, possibly related behaviour change is alignment of the 'horizontal rule' in these examples:
My_Girl_release_6.060.pdf
My_Girl (Guitar) git_029.pdf

It's created using code adapted from your '1-pixel image':

{image: width=100% height=0.001% border=0.25 src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="}

With release version, it's been 100% of available width (excluding diagrams on right) and so it's irrelevant whether it's aligned left or centre (because it's 100% width).

With dev_029 we seem to have the odd situation that it scales correctly to 100% of available width (i.e. excluding diagrams), but then seems to be centred within page body width (margin to margin).

For my own practical purposes, I can easily fix this by adding align=left. But, is current (_029) behaviour confusing, if the page width used for scaling is different from the page width used for alignment?

[sciurius]

Maybe related: ChordPro has spread images, images that go on top of the page (page, not paper) possibly spanning columns.
ChordPro can also put the chord diagrams on top of the page.

What if both? What do you prefer? Left is 6.06, right is 6.05.

[gwyndaf]

OK, so assuming these are two different ways of interpreting pdf.diagrams.show=top, I think I'd generally favour the right (6.05).

Personally, it's not a case that's arisen for me, and I'd be inclined to put chords at the bottom of the page, but guess that's simply the bottom option.

Rationale
I'm always mindful of the readers' playing ability and purpose of a sheet or songbook. For a 'tutorial' approach, I assume the reader knows neither the song nor the guitar chords, so would put chord diagrams at the very top. That makes those the first thing a reader sees before moving on the play the song.

For a 'playing' approach, I assume readers probably know the chords, but not the song, so better to get straight into the song, but still making chord diagrams available for reference (e.g. at bottom).

With chord diagrams appearing between score image and song body layout (left), it seems to serve neither of those aims. Also, it creates a bit of cognitive friction, because the chord diagrams create an 'obstruction' between the later verse lyrics and the score, so it's just a little harder to flick the eye back up to the melody from verse 2/3.

In essence, I think there's a logic in keeping 'what you play' as one coherent body, and placing the 'how to play it' (e.g. diagrams) somewhere else, such as top or bottom.

I've noticed discussion of a top/centred diagrams feature, and think the right example (6.05) might also fit better with that aesthetic.

[sciurius]

Thanks. As usual, your opinions and rationales are very valuable.

[sciurius]

Hi Alyn, I've been busy with other things (GUI redesign) so it took a while.

I've fixed several problems w.r.t. the images. Can you please try _054 to see if it improved?

[gwyndaf]

No problem. I'm using release version for songbook updates, so can (properly) treat dev version as only for testing.

Initial testing (with _057) suggests that extra space between staves is now gone, so matches release behaviour again.

I had a few other instances of unexpected scaling behaviour (some described above), so I'll work through those today/tomorrow.

[gwyndaf]

OK, these look to be working nicely, with expected behaviour on the key symptoms:

• 'Horizontal rule' at 100% width now seems scaled and centred to available width (i.e. excluding chords column right), not overall page width.
• Multi-line ABC scores have consistent stave sizes, and (if it fits on one page) no difference whether split value is 0, 1 or not set.
• Long, two-page ABC score scales to full width on continuation page, so a bit larger than title page. Not a use case that arises for me, so I'm assuming this was your intent here.
• Lilypond score/tab output scales as expected. Probably a natural consequence, because I guess this is really about image scaling, which would affect all relevant delegates.

Next test is to review a production batch of songs where I can't remember whether I scaled scores (for consistent stave height) based on release or recent dev behaviour(!), so I'll need to go through and check those, but test samples suggest all is now working as expected.

Also, one improvement (from earlier dev versions, I think) is still present, which helps alignment of score snippets as images:

{start_of_abc-keyboard: Intro (and C chord riff)}
id=riff1
scale=0.76
%%singleline 1
X:1
K:C
M:4/4
L:1/8
"C"C2- CD EG Ac |

{end_of_abc}
{start_of_abc-keyboard: F chord riff}
id=riff2
scale=0.76
%%singleline 1
X:1
K:C
M:4/4
L:1/8
"F"F2- FG Ac df |

{end_of_abc}
{start_of_riffs-keyboard}
{comment-keyboard: Intro and C riff:    <img id="riff1" dy=-23 />          F riff:    <img id="riff2" dy=-23 />}


{end_of_riffs}

Release version gives

Dev version gives

That is, using the same scale and <img dy> values for both scores now results in them being vertically level, which seems a more intuitive, less hassle touch :)

[gwyndaf]

OK, looking over a collection of songs with short scores for riffs/motifs, some scale smaller (for same scale value) in dev _057 than release version. As far as I can tell, it's under these conditions:

• Chord diagrams shown right (doesn't arise with diagrams at bottom).
• Only one line of score, but applies to two-stave system as well as single stave.
• Score output is (without scaling) shorter than page width, e.g. just 2 bars, which needs less than half a page width.
• Doesn't arise where score fits full width, including those where I've tweaked ABC %% parameters to force a single line fit.

It seems like stave height output with dev _057 is about 86% of height from release version. That seems to correspond roughly to the ratio of available width to full page width. This seems to relate to earlier discussion.

These purely largely testing observations, rather than an issue. If this is the logical consequence of your work to produce more robust score scaling, I can easily work through my scores to change the scaling factor.

An interesting, but maybe unrelated observation: I'd been using %%singleline 1 by default for short scores. Previously, if a score ran to two lines, it helped constrain it to one, but (IIRC) had no effect on shorter scores. Now, if I remove that, short scores set a little wider, i.e. singleline 1 seems to compress the score, even when not necessary for fit. That may be a change in ABC processing, though.

[gwyndaf]

One more interesting case...
Don_t_Get_Around_Much_Anymore.cho.txt processed with my custom configs (can supply, but doesn't seem relevant).

Release output: Don_t_Get_Around_Much_Anymore_release.pdf
Dev _057 output: Don_t_Get_Around_Much_Anymore_057.pdf
It seems like _057 is bumping the score to the next page, even though there's enough space for it on the first page.

However, if I cut out the early verses, so there's plenty of space for the score, both versions produce identical output, with the score mid-way up the page. So it seems like the score's being wrongly judged too big for the remaining space.

My hypothesis: The score has split=0 to keep it all together. I think perhaps ChordPro is therefore assessing the height of the overall score image, to determine whether the un-split score can fit on this page, or must be bumped to the next. But perhaps it's making that assessment based on the height of the full-width score, not the score as scaled to fit the narrower available area, with diagrams right.

However, it seems I can work around this. If I set split=1, the score doesn't actually split! Probably because it doesn't really need to. I assume that's because the height of each line is assessed in turn, then judged whether there's space for it on the current page, and it's only then scaled to fit the page it's actually on.

So, as an experiment (with split=1), I add an extra line to the song, which moves the score to sit at the very bottom of the page (no space below) with release version. Same song with dev _057 pushes the fourth line to the next page, even though I know there's room for it on the title page.

That is, it seems like the fourth line's height it assessed based on full-width scaling, not as scaled down to fit alongside diagrams right, and the unscaled line is judged too high for the remaining space. That seems to confirm my hypothesis.

[gwyndaf]

Given that the last case mentioned involves a very specific set of conditions (including my various settings) that leave only just enough space at the bottom of the page, I've created a version that demonstrates the behaviour with simpler config settings. That might make it easier for you to reproduce the behaviour.

chordpro -X --config keyboard --define pdf.kbdiagrams.show=right Don_t_Get_Around_Much_Anymore_TESTING.cho.txt

Don_t_Get_Around_Much_Anymore_TESTING.cho.txt

[sciurius]

Thanks for the testing. I'm glad it works out nice.

As for the veritcal alignment of inline ABC phrases: The intention is that the lowest line of the staff is considered baseline.

some text <img id="abc1"/> some text <img id="abc2"/> more text

will yields what one intuitively would expect (regardless of scale).

Unfortunately there was a bug in the abc2svg that shipped with 6.060 that prevented this from working so the images were aligned to the bottom.

[sciurius]

'Horizontal rule' at 100% width now seems scaled and centred to available width (i.e. excluding chords column right), not overall page width.

In fact, I detect that the line after scaling is >= the width, so I leave it left aligned.

Multi-line ABC scores have consistent stave sizes, and (if it fits on one page) no difference whether split value is 0, 1 or not set.

Good.

Long, two-page ABC score scales to full width on continuation page, so a bit larger than title page. Not a use case that arises for me, so I'm assuming this was your intent here.

I think this is best. Consider a score on the 1st page with a full line shifted to page 2. Page 2 also contains another score with full lines. Then it is either (--- is page break) different scalings on the same page:

xxxxxxxxxxxxxxxxxxxxxxxxx
---
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxx

ZZZZZZZZZZZZZZZZZZZZZZZZZZZ
ZZZZZZZZZZZZZZZZ

or different scaling after page break but consistent on the page:

xxxxxxxxxxxxxxxxxxxxxxxxx
---
xxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx

ZZZZZZZZZZZZZZZZZZZZZZZZZZZ
ZZZZZZZZZZZZZZZZ

Lilypond score/tab output scales as expected. Probably a natural consequence, because I guess this is really about image scaling, which would affect all relevant delegates.

Correct.

[sciurius]

Given that the last case mentioned involves a very specific set of conditions

It's not that hard to reproduce.

split.cho.txt

One more lyrics line and it shifts to the next page. Initially still scaled ☺ so I needed to fix that, too.

_058 should do better.

[gwyndaf]

Sorry for slow response on this. Multi-line scores now seems to work more nicely, and don't split across pages when they don't need to.

I still get short scores scaling smaller in dev _060 compared to release version, as mentioned above.

Can you confirm this is now intended behaviour, and follows from scaling principles for diagrams on right? If so, I can revise scaling values for my various score snippets, but will hold off if this change isn't yet stable.

Current dev behaviour does seem to make sense. I can see from this set of outputs
9_to_5.cho.txt
9_to_5_dev060_default.pdf
9_to_5_dev060_right.pdf
9_to_5_release_default.pdf
9_to_5_release_right.pdf
that release version has no change in score scaling whether diagrams are default or right, but dev _060 now scales score smaller when chords are right. That seems like a consistent principle, which applies regardless of whether scores are full-width or narrower.

[sciurius]

In _065, the extra scaling is only applied if necessary. Is this better?

[gwyndaf]

Thanks Johan. I didn't have a strong view personally, but this saves me re-scaling many short scores. It's maybe a preferable approach because it's both consistent with release behaviour, and means that shorter scores will stay the same size regardless of diagrams' position.

Now, I see only one other behavioural change from release, but it seems to be a useful one that's worth keeping...

A few longer scores now scale larger with _065 than release version. They'd normally run close to available page width (excl. diagrams), and also have manual scale= factors that I've applied, but that's primarily to keep score sizes consistent through my songbook, not to fit the available width. With my manual scaling applied, their output width is now maybe 80-90% of available width (i.e. 10-20% space between score and diagrams).

If I adjust the scaling to bring their sizes back in line with release version (and same stave height as other scores), I find that needs scale=0.76. That's exactly the same scaling value I apply to short scores (where there's now no automatic scaling to accommodate diagrams right).

So, I think ChordPro is doing something quite smart and useful: maybe it's taking my manual scaling into account before assessing the the image size in relation to the available width. If my scaling already means the image will fit, no need to apply any further, automatic scaling.

I don't know if that reasoning is correct, but the practical implication is very useful: I can now apply the same scale factor to a lot more of my scores, and get the same output size (stave height) for them all, which is very useful because it saves a lot of trial and error to get consistent output sizes :)

[gwyndaf]

My apologies, I've only just spotted that the original issue seems to have returned, I think with dev _065 (and now _067).

I tried to make testing more methodical, so I think these examples cover the main scenarios.
Text_Scores.cho.txt
Text_Scores_release.pdf
Text_Scores_dev_067.pdf

Main issue now seems to be example D), last line scaling larger. It goes away if I use the split=0 workaround, so last line scaling matches the first three.

Maybe this is a side-effect of the 'smart' scaling feature: the first three lines are page-with so get auto-scaled, but the last line fits available space, so doesn't get scaled.

Also, example B) is an interesting consequence of 'smart' scaling, but a logical consequence of the principles, so I don't think it's a problem.