After I had successfully implemented an {start_of_abc}/{end_of_abc} section in this song, I had added {start_of_grid}/{end_of_grid} sections. I was doing this work on PC, and then used Sync Libary | Update Folder from the PC, followed by Sync Library | Update Device for the tablet. Each time I did this, I compared what I was looking at in Windows vs Android tablet. At no time did I revise the working abc section.
At some point, I noticed that Windows has stopped rendering the {start_of_abc}/{end_of_abc} section on the PC. I don't recall when this occurred, because I was so focused on the grid sections
But it was still rendering fine on the tablet. I decided to add a comment on the tablet, then I used Sync Libary | Update Folder from the tablet, followed by Sync Library | Update Device for the PC.
The PC shows the new comment I entered on the tablet, however it still does not render the abc section, while the tablet does.
On the PC, I stopped Mobile Sheet, and restarted it, and opened the file again. Still not rendering the abc section.
Here is the file(ignore the comment for now, I intend to move it to just before the second Intro section, where it belongs). This file is from the Sync folder that is common to both PC and tablet.
The ABC was not rendered in my MobileSheets on Win11, nothing like "MobileSheets stopped rendering"
I removed everything except the ABC section and loaded the remaining file into Jef Moines online ABC editor http://moinejf.free.fr/js/edit-1.xhtml
Jef is the author of abc2svg, so his editor is something like the reference for abc2svg questions. Furthermore it displays good error messages that are very helpful for investigating ABC issues.
I added an empty line before {end_of_abc} to mark the end of the abc code. Otherwise Jef's editor reports {end_of_abc} as invalid abc code.A regular ABC tune starts at the X: line and ends at the first empty line. {end_of_abc} is a ChordPro directive so reporting it as not being valid ABC code is correct.
Fixing the reported error did not help, http://moinejf.free.fr/js/edit-1.xhtml renders the abc section, MobileSheets doesn't. So there's something wrong with MobileSheets.
The screenshot shows the error that was reported
Attached file GimmeThreeSteps.cho is the reduced version that I used for testing. Jef Moine doesn't report an error anymore, MobileSheets nevertheless doesn't render it.
03-14-2026, 09:06 AM (This post was last modified: 03-14-2026, 09:08 AM by Eddie H.)
ok, I uncovered a few mistakes on my part:
This was intended as a bass part, so the clef designation was missing:
Code:
K:D bass
The code I uploaded was after I had used MobileSheets to change the key on the tablet(from D to A) before syncing the PC to Upload to Device. But what I noticed in your post was that abc code now had a two mistakes: #E, C,#,
My code matches this. I'm saying this was sourced to me, not a mistake on your part
This is supposed to be just E, C,, since they original key implies C#. If I wanted to do this manually, I would have written ^C
Oddly, the other E's and C's were not changed.
Oddly, neither 1 Tune nor ABC edit with abc2svg show an error with #E, C,#, and that surprises me. I didn't think that was allowed?
Unfortunately, fixing those mistakes(I assume those are mistakes in abcnotation) does NOT allow MobilSheets to render the abc porion at all. Both 1 Tune nor ABC edit with abc2svg show no errors with the revised code:
I didn't mean to imply that "Mobile Sheets stopped rendering". What I wrote was " that Windows has stopped rendering the {start_of_abc}/{end_of_abc} section on the PC". I was trying to convey that MobileSheets on Windows stopped rendering the abc portion. MobileSheets on Windows renders everything else just fine.
The abc portion was rendering perfectly fine earlier in the day. That's what I started with before tackling the rest of the song, and I don't believe I touched it since getting it right.
03-15-2026, 03:09 AM (This post was last modified: 03-15-2026, 03:10 AM by Eddie H.)
Here's a similar issue. This file has a few sections of abc notation. But only the last one renders on a Windows 10 PC.
Aside from the musical notes used, I can't determine why the earlier sections don't render on Windows 10 PC.
I built all of the abc sections using ABC edit with abc2svg on PC, and copy pasted into MobileSheets on the PC. I then Synced Libraries, and found everything renders perfectly well on Android.
I'm really hoping I've made a stupid, but subtle mistake that I can fix and learn from, but I'm stumped.
@Mike: AutoSize Text calculates a size of 100 for grid and grid comment which is far too big
@Eddie:
- for sorting out problems like this I recommend splitting the score into small snippets and checking them one by one
- I'm not sure if nesting of {start_of_grid} inside {start_of_chorus} / {start_of_chorus} is supported in ChordPro
- for testing with http://moinejf.free.fr/js/edit-1.xhtml an empty before {end_of_abc}is required (as already mentioned)
- some commas are causing errors
The grid sizing issue seems to be somewhat dependent on the maximum auto font size, as it doesn't occur if you set a lower maximum size. Regardless, I see parts of it still go off the page, so the calculations don't seem to be quite right.
So the logic currently sizes grids independently from lyrics and chords. While this is correct behavior in order to handle situations where the grid font sizes need to be smaller than the lyrics/chords, I think it's undesired behavior when the grid font sizes can be larger than the lyrics/chords, as then you get inconsistent sizes across the page. So I'm going to change the logic so that grids will always be the same size as the lyrics unless they need to be smaller in order to fit.
Eddie's score is rendered fine on my Boox Tab Ultra C
The font size that is calculated by Auto Size seems correct assuming that only the chords are taken into account, which probably makes sense.
The grid comments go off the page (right margin) or overlap with the chords (left margin) because the margins are not wide enough with
{start_of_grid shape="1+4x4+1"}
So there's just an issue left with the ABC sections on Windows (which is said to be fixed in the next version)
I have set "Maximum Auto Font Size" to an unusually big value of 200 because I have some rare cases where I want really big font sizes. It doesn't do any harm so far.
(03-15-2026, 04:09 AM)Zubersoft Wrote: So the logic currently sizes grids independently from lyrics and chords. While this is correct behavior in order to handle situations where the grid font sizes need to be smaller than the lyrics/chords, I think it's undesired behavior when the grid font sizes can be larger than the lyrics/chords, as then you get inconsistent sizes across the page. So I'm going to change the logic so that grids will always be the same size as the lyrics unless they need to be smaller in order to fit.
Mike
Please leave it as it is. Sorry that I caused confusion. It often makes sense that the chords in grids are bigger than in the lyrics&chord sections.
It's better to have the option to fine tune font sizes and margin sizes manually even if it causes some additional effort
03-15-2026, 05:12 AM (This post was last modified: 03-15-2026, 05:12 AM by Zubersoft.)
Okay, if that's your desire, I'll leave it as it is currently, but I'll review the measurement code to see if I can make sure it accounts for comments properly.
It turns out the auto-sizing issues with the comments is due to a parsing error when shape="" is used. I have a fix in place for that now. I should mention that the grid chords and comments are sized independently to make them fit into the grid shape that has been specified, so if 1+4x4+1 is used, the comments are shrunk down to fix in their cells.
I didn't want to bother you with it, but if you are currently workong on Auto Size anyway:
it would be really convenient if the subtitle size could be also calculated independently. Currently it's combined with lyrics.
My subtitles are often pretty long and I wouldn't care if they are small. Currently long subtitles cause the lyrics font size to be really small. Especially for lyrics I want the font size exactly as big that the longest lyrics line uses the complete screen width. I attached an example.
That's actually a very simple bug for me to fix that occurs if the lyrics size winds up being larger than the chorus size (meaning there are chorus sections longer than any lyrics size, so they are both decreased in size to make them consistent and fit the screen), as there is code incorrectly setting the title and subtitle based on the lyrics size, even though right before that I correctly calculate the title and subtitle sizes independently. So it's fixed for the next update now.
