Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

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,)

[Weaver]

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 https://forum.kitz.co.uk/index.php/topic,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.