Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
   Compare ISP   Rate your ISP
   Glossary   Glossary
Please login or register.

Login with username, password and session length
Advanced search  


Author Topic: Long-standing iOS Shortcuts - my displayed text: layout bug  (Read 413 times)


  • Senior Kitizen
  • ******
  • Posts: 10410
  • Retd s/w dev; A&A; 3x7km lines; Firebrick
Long-standing iOS Shortcuts - my displayed text: layout bug
« on: October 31, 2021, 04:57:15 AM »

When I draw text in a black full-screen window in iPadOS Shortcuts, the layout of my text is wrong. I get lines of text prematurely wrapped at a width of n characters, almost all of the time, and the width is not even half that if the full-screen window. The action I am using is called Quick <something>. This problem is not new, iirc it predates iOS 14, but it was introduced in a new iOS release and I canít remember now which one. It was working fine before.

The bug only affects one Shortcuts routine. I noticed that there is an option button associated with the action which says something like "full screen" and Iíve gone through and checked that that is set to enabled on every drawing action. It is absolutely certain that the bug was introduced by a new Shortcuts release, but as a sanity check, I tried to search the strings that were about to be displayed, to look for CR or \n in them just in case I had gone mad and had a bug somehow inserting newline characters, or maybe that Shortcuts itself was doing the same.

The line wrap makes a complete mess of the displayed text layout and makes the result unreadable, crippling the usefulness of the program, which is an overview report generator to first check connections to modems and DSL lines are correct not mixed up, and check that DSL lines are happy. Itís massive: c. 450 actions! And thatís not including all the lines-of-code count in the many external subroutines that it calls.

Anyone got any suggestions on how to fix it? Or how to report the bug to Apple ?

Apple would never be able to run it successfully to reproduce the situation because it depends on so many other subroutines and it requires my modems and router to be connected if one wishes to get typical representative displayed output. It would just die without all the subroutines, and correctly display lots of error messages if all the required hardware is not attached. Indeed one of its functions is to check that the DSL lines are correct ones. (Done by examining reported BBEUIDs, or whatever theyíre called; I forget now,)


  • Senior Kitizen
  • ******
  • Posts: 10410
  • Retd s/w dev; A&A; 3x7km lines; Firebrick
Re: Long-standing iOS Shortcuts - my displayed text: layout bug
« Reply #1 on: November 12, 2021, 03:09:57 AM »

I have done some more debugging of this. I inserted a line of code to replace every "\n" with "xxx\n" and it worked sort-of as expected, but didnít make an replacement where Iím seeing the funny premature line-wraps at less than half of window width. So that proves that there is no spurious "\n" lurking inside the strings that I am using when I display the whole lot on the screen. (Mind you, I should perhaps have checked for a "\r" as well! CR ASCII 13 that is of course as opposed to the stupid *nix LF ASCII 10. Note to self - need to close that.)

I also tried pre-concatenating the strings that Iím displaying and then displaying the combined whole latter, instead of the way itís done now, which is by referencing each of the relevant strings in an object like a format string in a printf(), used before the end result is then displayed. In Shortcuts this is currently done by a Text object, which makes references to the various strings required and intersperses them in some places with literal text, indeed just like the first argument of a printf(). I tried this alternative method of preparing the result for display just in case there was something evil in the Shortcuts Text object, but that didnít make sense because in other programs I have managed to get it to display longer/wider text, longer/wider by far and have never had a problem.

Can anyone think of anything I might be missing?

Hereís what we know :

1. Premature line wrap in displayed text in Shortcuts

2. Display is in a very wide window - full screen on an iPad Pro largest screen model, portrait mode

3. Only happens in one program, but see #8.

4. Width is about 30-40 chars, not sure exactly, and also itís not a monospaced font.

5. Introduced, in iOS 14 iirc, - see,25185.msg425338.html#msg425338 - proof that it is a bug in Shortcuts and isnít my code that is bugged.

6. Checked for spurious LFs in text (could have been introduced by Shortcuts engine! donít necessarily have to be my doing)

7. Width of display is more than 2 x that at which the premature wrap occurs, so definitely enough pixel width

8. Duplicated the problem Shortcuts routine in question, and the copy fails in the same way, so itís not specifically  down to the one file object in the file system; so what does Ďone programí really mean? (Specifically, I made a second file with a different name that is an exact copy of the problem routine by using the Shortcuts "duplicate" option, and ran the copy, and that exhibited the bug.)

9. Havenít yet checked for presence of spurious CRs. Anything else similar I need to worry about?


Debugging the program / isolating the cause or trigger:

10. Could make a minimal program and try that but Iím not sure how far we could get, not because the approach isnít valid, but because the problem routine is absolutely massive (458 actions), so trying to approach that routine in steps from a minimal initial would be a truly Herculean task. The idea of adding a line of code or making a change, and seeing which change causes the bug to appear has some merit, but youíre just doing Appleís work for them.

11. Should report it to Apple as a regression, how to do this?

12. To report it to Apple, how to get the code to them? Plus needs dozens of subroutines to be accompanying it to.

13. Environment per-site is required. And if Apple devs want to see the code producing typical, representative output, so that they can be sure to observe the bug properly, they possibly need my network with my router, modems etc. There is one routine that defines the current site and all per-site variables are in a big struct in there. For example, how many modems, what are their Ďslotí numbers, what are they called, what are their admin i/f IP addresses and a dozen other things.

14. Because #13 is a killer, Apple would perhaps need to debug the code remotely, which could be done in fact as far as networking goes, but there would doubtless be some other difficulties.

15. It might be that debugging the real accurate current program isnít essential; a modified version could exhibit the bug while missing out many of the true subroutines. The subroutines could be replaced with either trivial code that gives typical return values, or even constants could be substituted in the main routine in place of calls to subroutines. It might be that even a large amount of such surgery would not prevent the bug from appearing.


Note re #8: iOS 14.0 is where they changed from monospaced to proportional font and screwed up a lot of existing apps that way, and worse, made it impossible to write some apps as thereís no option to use monospaced fonts, nor is there a function to get the width of a string in pixels. As an example, I had written a routine to display a horizontal bar chart but this relied on the fact that a monospaced font was being used, and specifically on the fact that an ordinary ASCII space 20h was the same width as one of the sold block characters that I was using to build the bars.  (BTW, having a convenience function to find where a long string displayed in a given font breaks at a pixel wrap width of x, with or without options for finding white space or other line break opportunities.) I donít suppose the bug is directly connected with the change in font. Thank goodness in iOS 15 Apple introduced an option in the display function Quick Look() which is full-screen vs modest-sized window, but you canít control or inquire about the size of either window-size nor can you select the value of the which-size window option at runtime.

Note re #11: Apple perhaps wonít be delighted to receive a bug report, as the regression is not in iOS 15 but in iOS 14.0 (or maybe even earlier.