When I delete a line in a plain text file in TextEdit on Big Sur (only), the cursor stays in the correct position, but the window scrolls up to the start of the file. I would expect no scrolling to occur.
To reproduce:
create a new file and convert it to plain text
make it 50 lines long. It can have any content, e.g. 1 character per line
reduce the height of the window to 20 lines, to ensure scrolling can be observed
scroll to end of file
use backspace to delete a line or 2 from near the end of the file.
Observed result: window scrolls to the top of the file
Expected result: no scrolling
Is there any workaround, or a setting that can be changed so that this behaviour is not observed?
The issue appears to be fixed in macOS 11.1 (20C69), released on December 14, 2020.
Related
The following was found in Embarcardero RAD Studio 10.2. I have not looked at other versions.
If you have a TRichEdit on your form that contains existing text (more than 1021 characters), and change the WordWrap (or any other recreate window) property, then the component will sometimes insert additional blank lines in the middle of your existing text. It appears to depend on where the CR/LF characters land.
To demonstrate the problem, paste the following text into the Lines property of a TRichEdit on a form in Delphi:
01xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx78
02xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
03xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
04xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
05xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
06xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
07xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
08xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
09xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
10xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
11x456789012345678901234567890123456789012345678901234567890123456789012345678
12xxxxxxx1xxxxxxxxx2xxxxxxxxx3xxxxxxxxx4xxxxxxxxx5xxxxxxxxx6xxxxxxxxx7xxxxxxxx
13x4567890123456789012345678901234567890123456789012345678901
x
The purpose of the sample text above is to have 1024 characters (counting the CR/LF at the end of the preceding lines) when you get to the last line (the 'x' on its own). What comes after does not matter.
Now, with the above text in your TRichEdit, and still in design mode, toggle the WordWrap property a few times. (The same thing should happen if you set up your form to do it at runtime.) If your Delphi does the same as mine, the last line (the 'x' on its own) will start to separate from the earlier lines as new lines are inserted.
If you change the length of the 13th line - add or remove just one character - the problem seems to go away.
I say "seems to go away" because the 1022/1023 position for CR/LF is not the only sensitive positions. I found more further on (when playing with larger text), but not always on the 1k borders (I think, not studied in detail).
I found the problem with WordWrap, but it happens with any of the properties that recreate the window handle (I think) - certainly BorderStyle does the same thing.
Has anyone else seen this? Is it too much to ask if someone could try the above test in Delphi 10.3 to see if it's fixed?
Probably the only reliable fix (if 10.3 doesn't fix it) is to avoid using TRichEdit, or - and this is my next step for testing the problem - to create and use a derivation that inserts code to save and restore content during handle recreation. Any other ideas?
UPDATE At runtime the problem only happens if the PlainText property is true. At designtime it happens whether that property is true or not.
I have a UILabel with Arabic text which contains the word اسماً, last character is the letter Alef with the mark Fathah. This mark is somehow causing the word to be misaligned vertically with the rest of the text.
When removing the mark, the word is back to correct baseline
The font is iOS system font, this doesn't happen with the Ariel font.
This is an issue with the iOS system font.
I've opened a new project to test it and added only a UITextField with an Arabic string which includes the char اً as the placeholder and it had the same behaviour.
This has been fixed on iOS 11.
On iOS 10 in a UILabel, the letter יִ (a yud with a chirik under it) is getting displayed as a circle instead of the way it's supposed to appear.
Other vowels and letters (e.g. יֵ יַ יֶ יֹ) are being displayed ok.
I submitted this as a bug to apple (bug id 28561355 on https://bugreport.apple.com).
Even if apple can fix this in a future version of iOS, is there anything I can do now, to hack this to work? I can just replace the yud-chirik with a plain yud, but I'd rather try and keep the display as it's supposed to be.
Thanks.
UPDATE: It seems that if I change the font to the default apple font (instead of a custom font that I was using), then the yud-chirik appears, but the chirik appears in the wrong place. It appears directly under the yud instead of at the bottom with all the other vowels.
I know after ios6, setAttributeString could help to change the line space,
but if I'm typing in the textview, may I change the line space, on ios7 setAttributeString seems work but not on iOS 6
I think you can't change line space of textfield in iOS 6 because there is no API call available for iOS 6. Although you can use core text for this. Look this code for this https://github.com/mattt/TTTAttributedLabel
There was a bug in iOS 6, that causes line height to be ignored when font is set. See answer to NSParagraphStyle line spacing ignored and longer bug analysis at Radar: UITextView Ignores Minimum/Maximum Line Height in Attributed String.
When I write arabic text containing the letter kasra (unicode character 0x650, phonetic equivalent i) to a button, the kasra is not displayed. Thus, the word mumkin appears as mumkn. If I inspect the NSString in Xcode, the kasra is present, but the kasra is not displayed in the iPhone simulator or on a real iPad. The other two short vowels (fatha and damma) are displayed correctly.
The arabic letter kasra (unicode character 0x650) is missing from all of the built-in IOS7 fonts that i have tried.
The solution was to build a different font into my app- I used AGA-Rasheeq-Bold.
This may be a bug. I just tried it in the storyboard editor and it does not seem to work. I created a string in the MAC Notes application, copied and pasted. It displays correctly in the left hand properties panel, but not in the button itself. Could you provide the exact Unicode string? You may need to open a bug report with Apple.
I can confirm that it works correctly in a Label field, but not a Button (IOS 6.1 and Xcode 4.6.3)
Try attributed text. This seems to work around the issue.