[Zubersoft]

Yes, it's also supported in both the iOS and Windows versions of MobileSheets.

Mike

[itsme]

@Mike: you wrote
"... I'm a little unsure of how I should handle scenarios where there are multiple songs in a single abc file (do I just use the first and ignore all the rest?). ..."
By now I use ABC, ChordPro and ChordPro with embedded ABC only for one song per file and this will probably stay my preference. But I came across examples where  ABC is used to create complete songbooks in a single file. This is pretty common in the ABC community e.g. by Irish folk musicians. If you decide to support that, it could be done similar to PDF songbooks containing bookmarks or with a UI similar to the CSV import dialog.

"Paul Hardy's Session Tunebook" is an example for such an Irish folk songbook.
https://pghardy.net/tunebooks/
https://pghardy.net/tunebooks/pgh_session_tunebook.abc

This is a song from this tunebook

Code:

X:1001
T:Aiken Drum
T:Willie Wood
T:There's a Man Came to our Town
R:Reel
C:Trad. Before 1820
O:Scotland
Z:Paul Hardy's Session Tunebook 2024 (see www.paulhardy.net). Creative Commons cc by-nc-sa licenced.
M:4/4
L:1/8
Q:1/4=140
K:D
de|"D"f2 f2 gfed|"G"B4 d3 B|"D"A3 B d2 A2|"E7"f2 e2 "A7"e2 de|"D"f2 f2 gfed|"G"B4 d3 B|"A7"A2 A2 B2 c2|"D"d6:|
|:de|"D"f2 f2 f2 ed|"G"g2 g2 b3 g|"D"f2 a2 f2 d2|"Em"f2 e2 "A7"e2 de|"D"f2 f2 gfed|"G"B4 d3 B|"A7"A2 A2 B2 c2|"D"d6:|

It demonstrates some song header details:
X: is the song number. It's mandatory and starts a new song. At first glance the number seems to be unique within the file, but that's definitely not required. 
T: is the song title. I have chosen this song because it shows that (not only) in Irish folk it happens that the same song might have more than one title. If I were you I would create a new song in MobileSheets for every X: and use the first T: field after the X: to populate the song title in the MobileSheets database. Additional T: titles could be rendered like {subtitle: directives in a ChordPro file. I would appreciate (and proposed that already elsewhere) if MobileSheets supported "alternative titles", not only for ABC files.
Other song header fields could be used to populate more fields in the MobileSheets database C: = composers, M: = signatures, R: = genres, K: = keys and so on.

"King Street Sessions Tunebook" http://www.pacholo.com/mike/tunebook/KSS.abc is another example for an ABC songbook.

[Zubersoft]

I don't mind supporting these things eventually, but everytime there is scope creep in talking about what I should support, it means I would either have to push back the implementation until I have a lot more bandwidth, or it delays other features if I try to switch to working on it. It if I want to support extracting information for a single song's metadata in an ABC file, that seems straightforward if I just ignore every other song in that file. If I have to start trying to support functionality similar to CSV files where users can pick what songs to extract from the .abc file, that starts adding more and more things I have to work on, and it starts becoming a much larger effort, so I'm less likely to make any changes in the short term. So it's helpful to have these things as two separate conversations - what I should try to support in the short term, what I should aim to support in the long term.

Mike

[itsme]

@Mike: I fully agree that there are too many topics in this single thread and it would be good to separate them in different threads.

- handling of %%leftmargin, %%rightmargin, %%pagescale and %% directives in general
- vertical auto-sizing a song
- multiple songs in a single ABC file
- alternative titles
- and even more

[itsme]

- multiple songs in a single ABC file
@Mike: sorry if my post was not clear and could be misunderstood as another feature request
My intention was just to answer your question and help to clarify how (as far as I know) multiple songs are written in a single ABC file.
Supporting multiple songs in a single ABC file has no priority for me and can be postponed imho. Rendering just the first song of an imported ABC file is perfectly fine for now.

[itsme]

- vertical auto-sizing a song
I doubt that automatical auto-sizing of a song is a good approach. There are too many parameters involved to implement a general solution. Laurent's example is a pretty specific one - maybe he has lots of this kind, but that's not all. Songs with a small number of lines would get large spaces in between, songs with many lines would become too crowded, how about songs with lyrics under the notation, how about songs with several verses below the standard notation, how about displays with different aspect ratio and so on, questions are endless.
Nevertheless it might be great to have a possibility to tweak the line spacing of ABC notation.

[itsme]

- handling of %%leftmargin, %%rightmargin, %%pagescale and %% directives in general
The explanation how in particular %%pagescale is implemented was VERY helpful. 
I noticed that %%pagescale works differently in MobileSheets and in the ChordPro program and could not understand what's going on. That's hopefully clarified for me now.
My main usage for ABC is integrating ABC sections into ChordPro files. In that case the page margins specified in Settings - Text File Settings - Page Margins are applied also to the ABC section. Margins per song are not possible (?). This is perfectly fine for my needs and fully sufficient.
Text File Settings - Page Margins currently have no effect on pure ABC files. I don't miss it and have no opinion on applying them also to ABC files. It would probably not be enough for Laurent anyway.

[itsme]

- alternative titles
I asked for alternative titles before, it just came up again in connection with these ABC examples. It's still on my wishlist, but not with a high priority. Currently I'm using Custom Group for alternative titles which is not a good workaround and blocks Custom Group for other usages. But using Custom or Custom2 would not be any better. A good implementation of alternative titles would require several changes in database and UI so I can understand that we won't get it in the near future. Maybe you can keep it in mind when you start implementing song versioning.

[laurent]

I have some feedback from Jean-François Moine, the developer of abc2svg.
He answered after one week, and it turned out he took the challenge at heart and actually developed a standalone javascript file called fit2box.js just for this feature !

Here is his response in the mailing list:
https://groups.io/g/abcusers/topic/111991054#msg23023


I believe you only need, once the .js file is loaded, to inject "%%fit2box WIDTH HEIGHT" in the file header of the .abc file, where width and height are in pixels (more technical details in his response)

I'm not sure if all users will want this feature activated for all files.
I imagine that, to control whether or not to add %%fit2box, there would either be a global setting that instructs to inject %%fit2box to all .abc files we open, or we could leave this as a per-file setting and add a custom ABC parameter like "%%fit2screen" that Mobilesheets would detect and replace with "%%fit2box WIDTH HEIGHT".


What do you think, Mike, could it be part of some future release of Mobilesheets?

[Zubersoft]

I think this would need to be something users can set per file, because it overrides many settings including:

leftmargin
rightmargin
pagewidth
stretchstaff
stretchlast

That, or I would have to modify the code not to remove the margins for users that still want to be able to have margins while forcing the score to stretch to the maximum amount while still respecting those margins. My current plan is to have an ABC settings dialog that can be accessed while an ABC file is loaded that lets you change properties for that ABC file, including the page scaling and margins. I could add a setting there to control if "fitbox" is used, but I then have to decide whether I would still honor those margin settings, or if I have to disable the margins while the fitbox setting is active. I'm open to feedback on this.

Mike

[laurent]

I'm discussing with Jean-François about it. 
I'm saying that as you already set page height and page width, we could have a %%fit2page with no arguments instead of a %%fit2box width height.
My expectations would be that it would still honor the margins set in the file so the calculated box would be the size of the page minus the margins.

If he agrees to this, I suppose the implementation would be almost free for you, or am I missing something?

[laurent]

For the margins, this is a tricky question. 
I think there are two types of margins:
1. The margins I set on a file to make it look how I want in terms of spacing between the notes, I think it's less readable when they are spread too far apart. I add left and right margins on the file but this is not ideal because it depends on the format of my device and the idea is to be able to keep the same file for all devices.
2. The margins I would set differently depending on the device, because on my tablet notes are visible very close to the borders, but on my phone with a screen protector, they aren't that clear. These margins ideally should be additive to the ones set in the file.

I don't really like to set the right and left margins though, I would prefer to be able to set an aspect ratio for the score, like 9/16 for example and %%fit2page would then maximize width and height according to that ratio.

[itsme]

In the moment I don't find the time to investigate that topic in detail. So just some thoughts:
- how is "fit to page" related to the "fixed page size" feature that already exists in MobileSheets?
- most of my ABC use cases are snippets of a few lines of standard notation embedded into lyrics & chords or grids. For these cases "fit to page" as discussed here is not relevant, is that correct?

[Zubersoft]

Correct - I would think "Fit to page" would only be something you'd want to use for a full page abc file. The fixed page size feature is basically how you can control what values are passed into abc2svg, as it will render to the width and height specified for the fixed page size.

Mike