Mixing
UILabel wrong word wrap in iOS 11
I have problem with application using XIBs without autolayout. I don't know if this is important information.
I have UILabel with 2 lines using word wrap. In iOS 10 word wrap was working correctly, and first line contained one word + special character, for example ampersand. Example:
Then on iOS 11 word wrap is working somehow wrong and puts ampresand to the second line:
This is problematic as longer words, that normally fitted on second line now are not being shown correctly. Any idea what has changed? I know about safeArea but it doesn't look like reason. Any ideas how to move that ampersand to the top where is plenty of space for it?
Rest of the settings: 
ios iphone uilabel ios11
edited Nov 9 '17 at 8:30
Artem Kirillov
288318
asked Sep 13 '17 at 14:21
studentbistudentbi
16325
add a comment |
I have problem with application using XIBs without autolayout. I don't know if this is important information.
I have UILabel with 2 lines using word wrap. In iOS 10 word wrap was working correctly, and first line contained one word + special character, for example ampersand. Example:
Then on iOS 11 word wrap is working somehow wrong and puts ampresand to the second line:
This is problematic as longer words, that normally fitted on second line now are not being shown correctly. Any idea what has changed? I know about safeArea but it doesn't look like reason. Any ideas how to move that ampersand to the top where is plenty of space for it?
Rest of the settings:
ios iphone uilabel ios11
edited Nov 9 '17 at 8:30
Artem Kirillov
288318
asked Sep 13 '17 at 14:21
studentbistudentbi
16325
2
I just hit the same issue and can only guess: It seems the text wrapping algorithm has changed in iOS 11 so the result is more balanced/looks more boxed.
– Sebastian
Sep 14 '17 at 14:02
Looks like we have the same issue too. This seems like a bug, because UILabel has historically been used in situations where we want to simulate typical word processor (or web browser) word wrap, not figuring out the smallest box that can hold all the text.
– David Dunham
Oct 6 '17 at 19:30
I'm seeing the same issue (with ampersands). If I build the app with Xcode 8 (against iOS 10) then run that build on iOS 11 I see the new word-wrapping behaviour. So, even when notionally providing backward-compatibility with an iOS 10 app, iOS 11 is word-wrapping differently.
– Geoff Hackworth
Oct 16 '17 at 7:50
I believe it’s a bug to force this behavior and finally got around to filing 36021540 with Apple. If anyone else files, you can reference this.
– David Dunham
Dec 13 '17 at 16:46
This issue is coming from ios 11
– Sazid Iqabal
Nov 1 '18 at 11:21
add a comment |
I have problem with application using XIBs without autolayout. I don't know if this is important information.
I have UILabel with 2 lines using word wrap. In iOS 10 word wrap was working correctly, and first line contained one word + special character, for example ampersand. Example:
Then on iOS 11 word wrap is working somehow wrong and puts ampresand to the second line:
This is problematic as longer words, that normally fitted on second line now are not being shown correctly. Any idea what has changed? I know about safeArea but it doesn't look like reason. Any ideas how to move that ampersand to the top where is plenty of space for it?
Rest of the settings:
ios iphone uilabel ios11
edited Nov 9 '17 at 8:30
Artem Kirillov
288318
asked Sep 13 '17 at 14:21
studentbistudentbi
16325
I have problem with application using XIBs without autolayout. I don't know if this is important information.
I have UILabel with 2 lines using word wrap. In iOS 10 word wrap was working correctly, and first line contained one word + special character, for example ampersand. Example:
Then on iOS 11 word wrap is working somehow wrong and puts ampresand to the second line:
This is problematic as longer words, that normally fitted on second line now are not being shown correctly. Any idea what has changed? I know about safeArea but it doesn't look like reason. Any ideas how to move that ampersand to the top where is plenty of space for it?
Rest of the settings:
ios iphone uilabel ios11
ios iphone uilabel ios11
edited Nov 9 '17 at 8:30
Artem Kirillov
288318
asked Sep 13 '17 at 14:21
studentbistudentbi
16325
edited Nov 9 '17 at 8:30
Artem Kirillov
288318
asked Sep 13 '17 at 14:21
studentbistudentbi
16325
edited Nov 9 '17 at 8:30
Artem Kirillov
288318
edited Nov 9 '17 at 8:30
Artem Kirillov
288318
edited Nov 9 '17 at 8:30
Artem Kirillov
288318
288318
asked Sep 13 '17 at 14:21
studentbistudentbi
16325
asked Sep 13 '17 at 14:21
studentbistudentbi
16325
asked Sep 13 '17 at 14:21
studentbistudentbi
16325
16325
2
I just hit the same issue and can only guess: It seems the text wrapping algorithm has changed in iOS 11 so the result is more balanced/looks more boxed.
– Sebastian
Sep 14 '17 at 14:02
Looks like we have the same issue too. This seems like a bug, because UILabel has historically been used in situations where we want to simulate typical word processor (or web browser) word wrap, not figuring out the smallest box that can hold all the text.
– David Dunham
Oct 6 '17 at 19:30
I'm seeing the same issue (with ampersands). If I build the app with Xcode 8 (against iOS 10) then run that build on iOS 11 I see the new word-wrapping behaviour. So, even when notionally providing backward-compatibility with an iOS 10 app, iOS 11 is word-wrapping differently.
– Geoff Hackworth
Oct 16 '17 at 7:50
I believe it’s a bug to force this behavior and finally got around to filing 36021540 with Apple. If anyone else files, you can reference this.
– David Dunham
Dec 13 '17 at 16:46
This issue is coming from ios 11
– Sazid Iqabal
Nov 1 '18 at 11:21
add a comment |
2
I just hit the same issue and can only guess: It seems the text wrapping algorithm has changed in iOS 11 so the result is more balanced/looks more boxed.
– Sebastian
Sep 14 '17 at 14:02
Looks like we have the same issue too. This seems like a bug, because UILabel has historically been used in situations where we want to simulate typical word processor (or web browser) word wrap, not figuring out the smallest box that can hold all the text.
– David Dunham
Oct 6 '17 at 19:30
I'm seeing the same issue (with ampersands). If I build the app with Xcode 8 (against iOS 10) then run that build on iOS 11 I see the new word-wrapping behaviour. So, even when notionally providing backward-compatibility with an iOS 10 app, iOS 11 is word-wrapping differently.
– Geoff Hackworth
Oct 16 '17 at 7:50
I believe it’s a bug to force this behavior and finally got around to filing 36021540 with Apple. If anyone else files, you can reference this.
– David Dunham
Dec 13 '17 at 16:46
This issue is coming from ios 11
– Sazid Iqabal
Nov 1 '18 at 11:21
2
2
I just hit the same issue and can only guess: It seems the text wrapping algorithm has changed in iOS 11 so the result is more balanced/looks more boxed.
– Sebastian
Sep 14 '17 at 14:02
I just hit the same issue and can only guess: It seems the text wrapping algorithm has changed in iOS 11 so the result is more balanced/looks more boxed.
– Sebastian
Sep 14 '17 at 14:02
Looks like we have the same issue too. This seems like a bug, because UILabel has historically been used in situations where we want to simulate typical word processor (or web browser) word wrap, not figuring out the smallest box that can hold all the text.
– David Dunham
Oct 6 '17 at 19:30
Looks like we have the same issue too. This seems like a bug, because UILabel has historically been used in situations where we want to simulate typical word processor (or web browser) word wrap, not figuring out the smallest box that can hold all the text.
– David Dunham
Oct 6 '17 at 19:30
I'm seeing the same issue (with ampersands). If I build the app with Xcode 8 (against iOS 10) then run that build on iOS 11 I see the new word-wrapping behaviour. So, even when notionally providing backward-compatibility with an iOS 10 app, iOS 11 is word-wrapping differently.
– Geoff Hackworth
Oct 16 '17 at 7:50
I'm seeing the same issue (with ampersands). If I build the app with Xcode 8 (against iOS 10) then run that build on iOS 11 I see the new word-wrapping behaviour. So, even when notionally providing backward-compatibility with an iOS 10 app, iOS 11 is word-wrapping differently.
– Geoff Hackworth
Oct 16 '17 at 7:50
I believe it’s a bug to force this behavior and finally got around to filing 36021540 with Apple. If anyone else files, you can reference this.
– David Dunham
Dec 13 '17 at 16:46
I believe it’s a bug to force this behavior and finally got around to filing 36021540 with Apple. If anyone else files, you can reference this.
– David Dunham
Dec 13 '17 at 16:46
This issue is coming from ios 11
– Sazid Iqabal
Nov 1 '18 at 11:21
This issue is coming from ios 11
– Sazid Iqabal
Nov 1 '18 at 11:21
add a comment |
5 Answers
5
active
oldest
votes
This could very likely be an intentional change by Apple to prevent widowed lines. From a design perspective, it is preferred to avoid having a single word on a line of text. So it seems that UILabel now breaks the line in a way that the second line of text always has at least 2 words on it.
It is surprising that there is no documentation or way to disable this behavior though.
Also here's a good article about "widowed" and "orphaned" text.
answered Oct 23 '17 at 19:35
brynbodaylebrynbodayle
6,00612648
After testing I can conclude that iOS 11 does pull an additional word down with an orphaned word.
– Mississippi
Oct 30 '17 at 10:38
I can also verify this behavior of UILabels after changing the text in my app, it correctly wrapped the words.
– Marcel T
Nov 6 '17 at 8:48
Oh, this is interesting.
– damirstuhec
Nov 7 '18 at 18:52
1
But only with a two-line label? I'm seeing it allow a single-word last line when there are more than two lines total.
– Tom Hamming
Nov 14 '18 at 22:49
What I can't understand though is with is the width of the label left bigger than the actual displayed text. This way it's impossible to align, for example, an emoji next to a 2 lines label.
– Iulian Onofrei
Nov 15 '18 at 11:52
add a comment |
Launching the app with the arguments -NSAllowsDefaultLineBreakStrategy NO (an undocumented defaults setting) seems to force back to the old behavior. Alternatively, you can set NSAllowsDefaultLineBreakStrategy to NO in NSUserDefaults at startup (Apple registers a default of YES for that value when UILabel or the string drawing code is initialized, it appears, so you would need to register an overriding value after that, or insert it into the NSArgumentDomain, or just set the default persistently).
Apple may consider that private API and reject apps that use it; I'm not sure. I have not tried this in a shipping app. However, it does work in quick testing -- saw the setting in NSUserDefaults and found changing it altered the behavior.
edited Jul 6 '18 at 15:23
Iulian Onofrei
4,13634279
answered Mar 2 '18 at 5:47
Carl LindbergCarl Lindberg
2,4071320
add a comment |
This is not really an answer, but I want to add an illustration of how it is a general problem, not at all related to ampersands.
Both of these UILabels have identical width constraints, and the text is almost identical. But the second has the word wrap I would expect. The first is incorrect, the "about" can clearly stay on the first line.
answered Oct 20 '17 at 18:48
David DunhamDavid Dunham
7,23532639
add a comment |
It seems that replacing the space before the ampersand with a non-breaking space (U+00A0) keeps the ampersand on the same line. Depending on how you are generating the text for the label, this might not be easy to automate (maybe you really do need the ampersand to be on the second line in some cases).
answered Oct 16 '17 at 8:35
Geoff HackworthGeoff Hackworth
6761610
add a comment |
An option may be to use a UITextView instead -- that does not seem to have this behavior. If you set the NSTextContainer.lineFragmentPadding to 0, the textContainerInset to UIEdgeInsetsZero, and turn off all scrolling (scrollEnabled, bounces, scroll indicators, etc.) it will display similarly to a UILabel, though not with as much constraint flexibility. It's not a drop-in replacement, but in some situations it's acceptable.
answered Mar 2 '18 at 5:57
Carl LindbergCarl Lindberg
2,4071320
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f46200027%2fuilabel-wrong-word-wrap-in-ios-11%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
This could very likely be an intentional change by Apple to prevent widowed lines. From a design perspective, it is preferred to avoid having a single word on a line of text. So it seems that UILabel now breaks the line in a way that the second line of text always has at least 2 words on it.
It is surprising that there is no documentation or way to disable this behavior though.
Also here's a good article about "widowed" and "orphaned" text.
answered Oct 23 '17 at 19:35
brynbodaylebrynbodayle
6,00612648
After testing I can conclude that iOS 11 does pull an additional word down with an orphaned word.
– Mississippi
Oct 30 '17 at 10:38
I can also verify this behavior of UILabels after changing the text in my app, it correctly wrapped the words.
– Marcel T
Nov 6 '17 at 8:48
Oh, this is interesting.
– damirstuhec
Nov 7 '18 at 18:52
1
But only with a two-line label? I'm seeing it allow a single-word last line when there are more than two lines total.
– Tom Hamming
Nov 14 '18 at 22:49
What I can't understand though is with is the width of the label left bigger than the actual displayed text. This way it's impossible to align, for example, an emoji next to a 2 lines label.
– Iulian Onofrei
Nov 15 '18 at 11:52
add a comment |
This could very likely be an intentional change by Apple to prevent widowed lines. From a design perspective, it is preferred to avoid having a single word on a line of text. So it seems that UILabel now breaks the line in a way that the second line of text always has at least 2 words on it.
It is surprising that there is no documentation or way to disable this behavior though.
Also here's a good article about "widowed" and "orphaned" text.
answered Oct 23 '17 at 19:35
brynbodaylebrynbodayle
6,00612648
After testing I can conclude that iOS 11 does pull an additional word down with an orphaned word.
– Mississippi
Oct 30 '17 at 10:38
I can also verify this behavior of UILabels after changing the text in my app, it correctly wrapped the words.
– Marcel T
Nov 6 '17 at 8:48
Oh, this is interesting.
– damirstuhec
Nov 7 '18 at 18:52
1
But only with a two-line label? I'm seeing it allow a single-word last line when there are more than two lines total.
– Tom Hamming
Nov 14 '18 at 22:49
What I can't understand though is with is the width of the label left bigger than the actual displayed text. This way it's impossible to align, for example, an emoji next to a 2 lines label.
– Iulian Onofrei
Nov 15 '18 at 11:52
add a comment |
This could very likely be an intentional change by Apple to prevent widowed lines. From a design perspective, it is preferred to avoid having a single word on a line of text. So it seems that UILabel now breaks the line in a way that the second line of text always has at least 2 words on it.
It is surprising that there is no documentation or way to disable this behavior though.
Also here's a good article about "widowed" and "orphaned" text.
answered Oct 23 '17 at 19:35
brynbodaylebrynbodayle
6,00612648
This could very likely be an intentional change by Apple to prevent widowed lines. From a design perspective, it is preferred to avoid having a single word on a line of text. So it seems that UILabel now breaks the line in a way that the second line of text always has at least 2 words on it.
It is surprising that there is no documentation or way to disable this behavior though.
Also here's a good article about "widowed" and "orphaned" text.
answered Oct 23 '17 at 19:35
brynbodaylebrynbodayle
6,00612648
edited Jan 2 at 19:22
answered Oct 23 '17 at 19:35
brynbodaylebrynbodayle
6,00612648
answered Oct 23 '17 at 19:35
brynbodaylebrynbodayle
6,00612648
answered Oct 23 '17 at 19:35
brynbodaylebrynbodayle
6,00612648
6,00612648
After testing I can conclude that iOS 11 does pull an additional word down with an orphaned word.
– Mississippi
Oct 30 '17 at 10:38
I can also verify this behavior of UILabels after changing the text in my app, it correctly wrapped the words.
– Marcel T
Nov 6 '17 at 8:48
Oh, this is interesting.
– damirstuhec
Nov 7 '18 at 18:52
1
But only with a two-line label? I'm seeing it allow a single-word last line when there are more than two lines total.
– Tom Hamming
Nov 14 '18 at 22:49
What I can't understand though is with is the width of the label left bigger than the actual displayed text. This way it's impossible to align, for example, an emoji next to a 2 lines label.
– Iulian Onofrei
Nov 15 '18 at 11:52
add a comment |
After testing I can conclude that iOS 11 does pull an additional word down with an orphaned word.
– Mississippi
Oct 30 '17 at 10:38
I can also verify this behavior of UILabels after changing the text in my app, it correctly wrapped the words.
– Marcel T
Nov 6 '17 at 8:48
Oh, this is interesting.
– damirstuhec
Nov 7 '18 at 18:52
1
But only with a two-line label? I'm seeing it allow a single-word last line when there are more than two lines total.
– Tom Hamming
Nov 14 '18 at 22:49
What I can't understand though is with is the width of the label left bigger than the actual displayed text. This way it's impossible to align, for example, an emoji next to a 2 lines label.
– Iulian Onofrei
Nov 15 '18 at 11:52
After testing I can conclude that iOS 11 does pull an additional word down with an orphaned word.
– Mississippi
Oct 30 '17 at 10:38
After testing I can conclude that iOS 11 does pull an additional word down with an orphaned word.
– Mississippi
Oct 30 '17 at 10:38
I can also verify this behavior of UILabels after changing the text in my app, it correctly wrapped the words.
– Marcel T
Nov 6 '17 at 8:48
I can also verify this behavior of UILabels after changing the text in my app, it correctly wrapped the words.
– Marcel T
Nov 6 '17 at 8:48
Oh, this is interesting.
– damirstuhec
Nov 7 '18 at 18:52
Oh, this is interesting.
– damirstuhec
Nov 7 '18 at 18:52
1
1
But only with a two-line label? I'm seeing it allow a single-word last line when there are more than two lines total.
– Tom Hamming
Nov 14 '18 at 22:49
But only with a two-line label? I'm seeing it allow a single-word last line when there are more than two lines total.
– Tom Hamming
Nov 14 '18 at 22:49
What I can't understand though is with is the width of the label left bigger than the actual displayed text. This way it's impossible to align, for example, an emoji next to a 2 lines label.
– Iulian Onofrei
Nov 15 '18 at 11:52
What I can't understand though is with is the width of the label left bigger than the actual displayed text. This way it's impossible to align, for example, an emoji next to a 2 lines label.
– Iulian Onofrei
Nov 15 '18 at 11:52
add a comment |
Launching the app with the arguments -NSAllowsDefaultLineBreakStrategy NO (an undocumented defaults setting) seems to force back to the old behavior. Alternatively, you can set NSAllowsDefaultLineBreakStrategy to NO in NSUserDefaults at startup (Apple registers a default of YES for that value when UILabel or the string drawing code is initialized, it appears, so you would need to register an overriding value after that, or insert it into the NSArgumentDomain, or just set the default persistently).
Apple may consider that private API and reject apps that use it; I'm not sure. I have not tried this in a shipping app. However, it does work in quick testing -- saw the setting in NSUserDefaults and found changing it altered the behavior.
edited Jul 6 '18 at 15:23
Iulian Onofrei
4,13634279
answered Mar 2 '18 at 5:47
Carl LindbergCarl Lindberg
2,4071320
add a comment |
Launching the app with the arguments -NSAllowsDefaultLineBreakStrategy NO (an undocumented defaults setting) seems to force back to the old behavior. Alternatively, you can set NSAllowsDefaultLineBreakStrategy to NO in NSUserDefaults at startup (Apple registers a default of YES for that value when UILabel or the string drawing code is initialized, it appears, so you would need to register an overriding value after that, or insert it into the NSArgumentDomain, or just set the default persistently).
Apple may consider that private API and reject apps that use it; I'm not sure. I have not tried this in a shipping app. However, it does work in quick testing -- saw the setting in NSUserDefaults and found changing it altered the behavior.
edited Jul 6 '18 at 15:23
Iulian Onofrei
4,13634279
answered Mar 2 '18 at 5:47
Carl LindbergCarl Lindberg
2,4071320
add a comment |
Launching the app with the arguments -NSAllowsDefaultLineBreakStrategy NO (an undocumented defaults setting) seems to force back to the old behavior. Alternatively, you can set NSAllowsDefaultLineBreakStrategy to NO in NSUserDefaults at startup (Apple registers a default of YES for that value when UILabel or the string drawing code is initialized, it appears, so you would need to register an overriding value after that, or insert it into the NSArgumentDomain, or just set the default persistently).
Apple may consider that private API and reject apps that use it; I'm not sure. I have not tried this in a shipping app. However, it does work in quick testing -- saw the setting in NSUserDefaults and found changing it altered the behavior.
edited Jul 6 '18 at 15:23
Iulian Onofrei
4,13634279
answered Mar 2 '18 at 5:47
Carl LindbergCarl Lindberg
2,4071320
Launching the app with the arguments -NSAllowsDefaultLineBreakStrategy NO (an undocumented defaults setting) seems to force back to the old behavior. Alternatively, you can set NSAllowsDefaultLineBreakStrategy to NO in NSUserDefaults at startup (Apple registers a default of YES for that value when UILabel or the string drawing code is initialized, it appears, so you would need to register an overriding value after that, or insert it into the NSArgumentDomain, or just set the default persistently).
Apple may consider that private API and reject apps that use it; I'm not sure. I have not tried this in a shipping app. However, it does work in quick testing -- saw the setting in NSUserDefaults and found changing it altered the behavior.
edited Jul 6 '18 at 15:23
Iulian Onofrei
4,13634279
answered Mar 2 '18 at 5:47
Carl LindbergCarl Lindberg
2,4071320
edited Jul 6 '18 at 15:23
Iulian Onofrei
4,13634279
edited Jul 6 '18 at 15:23
Iulian Onofrei
4,13634279
edited Jul 6 '18 at 15:23
Iulian Onofrei
4,13634279
4,13634279
answered Mar 2 '18 at 5:47
Carl LindbergCarl Lindberg
2,4071320
answered Mar 2 '18 at 5:47
Carl LindbergCarl Lindberg
2,4071320
answered Mar 2 '18 at 5:47
Carl LindbergCarl Lindberg
2,4071320
2,4071320
add a comment |
add a comment |
This is not really an answer, but I want to add an illustration of how it is a general problem, not at all related to ampersands.
Both of these UILabels have identical width constraints, and the text is almost identical. But the second has the word wrap I would expect. The first is incorrect, the "about" can clearly stay on the first line.
answered Oct 20 '17 at 18:48
David DunhamDavid Dunham
7,23532639
add a comment |
This is not really an answer, but I want to add an illustration of how it is a general problem, not at all related to ampersands.
Both of these UILabels have identical width constraints, and the text is almost identical. But the second has the word wrap I would expect. The first is incorrect, the "about" can clearly stay on the first line.
answered Oct 20 '17 at 18:48
David DunhamDavid Dunham
7,23532639
add a comment |
This is not really an answer, but I want to add an illustration of how it is a general problem, not at all related to ampersands.
Both of these UILabels have identical width constraints, and the text is almost identical. But the second has the word wrap I would expect. The first is incorrect, the "about" can clearly stay on the first line.
answered Oct 20 '17 at 18:48
David DunhamDavid Dunham
7,23532639
This is not really an answer, but I want to add an illustration of how it is a general problem, not at all related to ampersands.
Both of these UILabels have identical width constraints, and the text is almost identical. But the second has the word wrap I would expect. The first is incorrect, the "about" can clearly stay on the first line.
answered Oct 20 '17 at 18:48
David DunhamDavid Dunham
7,23532639
answered Oct 20 '17 at 18:48
David DunhamDavid Dunham
7,23532639
answered Oct 20 '17 at 18:48
David DunhamDavid Dunham
7,23532639
answered Oct 20 '17 at 18:48
David DunhamDavid Dunham
7,23532639
7,23532639
add a comment |
add a comment |
It seems that replacing the space before the ampersand with a non-breaking space (U+00A0) keeps the ampersand on the same line. Depending on how you are generating the text for the label, this might not be easy to automate (maybe you really do need the ampersand to be on the second line in some cases).
answered Oct 16 '17 at 8:35
Geoff HackworthGeoff Hackworth
6761610
add a comment |
It seems that replacing the space before the ampersand with a non-breaking space (U+00A0) keeps the ampersand on the same line. Depending on how you are generating the text for the label, this might not be easy to automate (maybe you really do need the ampersand to be on the second line in some cases).
answered Oct 16 '17 at 8:35
Geoff HackworthGeoff Hackworth
6761610
add a comment |
It seems that replacing the space before the ampersand with a non-breaking space (U+00A0) keeps the ampersand on the same line. Depending on how you are generating the text for the label, this might not be easy to automate (maybe you really do need the ampersand to be on the second line in some cases).
answered Oct 16 '17 at 8:35
Geoff HackworthGeoff Hackworth
6761610
It seems that replacing the space before the ampersand with a non-breaking space (U+00A0) keeps the ampersand on the same line. Depending on how you are generating the text for the label, this might not be easy to automate (maybe you really do need the ampersand to be on the second line in some cases).
answered Oct 16 '17 at 8:35
Geoff HackworthGeoff Hackworth
6761610
answered Oct 16 '17 at 8:35
Geoff HackworthGeoff Hackworth
6761610
answered Oct 16 '17 at 8:35
Geoff HackworthGeoff Hackworth
6761610
answered Oct 16 '17 at 8:35
Geoff HackworthGeoff Hackworth
6761610
6761610
add a comment |
add a comment |
An option may be to use a UITextView instead -- that does not seem to have this behavior. If you set the NSTextContainer.lineFragmentPadding to 0, the textContainerInset to UIEdgeInsetsZero, and turn off all scrolling (scrollEnabled, bounces, scroll indicators, etc.) it will display similarly to a UILabel, though not with as much constraint flexibility. It's not a drop-in replacement, but in some situations it's acceptable.
answered Mar 2 '18 at 5:57
Carl LindbergCarl Lindberg
2,4071320
add a comment |
An option may be to use a UITextView instead -- that does not seem to have this behavior. If you set the NSTextContainer.lineFragmentPadding to 0, the textContainerInset to UIEdgeInsetsZero, and turn off all scrolling (scrollEnabled, bounces, scroll indicators, etc.) it will display similarly to a UILabel, though not with as much constraint flexibility. It's not a drop-in replacement, but in some situations it's acceptable.
answered Mar 2 '18 at 5:57
Carl LindbergCarl Lindberg
2,4071320
add a comment |
An option may be to use a UITextView instead -- that does not seem to have this behavior. If you set the NSTextContainer.lineFragmentPadding to 0, the textContainerInset to UIEdgeInsetsZero, and turn off all scrolling (scrollEnabled, bounces, scroll indicators, etc.) it will display similarly to a UILabel, though not with as much constraint flexibility. It's not a drop-in replacement, but in some situations it's acceptable.
answered Mar 2 '18 at 5:57
Carl LindbergCarl Lindberg
2,4071320
An option may be to use a UITextView instead -- that does not seem to have this behavior. If you set the NSTextContainer.lineFragmentPadding to 0, the textContainerInset to UIEdgeInsetsZero, and turn off all scrolling (scrollEnabled, bounces, scroll indicators, etc.) it will display similarly to a UILabel, though not with as much constraint flexibility. It's not a drop-in replacement, but in some situations it's acceptable.
answered Mar 2 '18 at 5:57
Carl LindbergCarl Lindberg
2,4071320
answered Mar 2 '18 at 5:57
Carl LindbergCarl Lindberg
2,4071320
answered Mar 2 '18 at 5:57
Carl LindbergCarl Lindberg
2,4071320
answered Mar 2 '18 at 5:57
Carl LindbergCarl Lindberg
2,4071320
2,4071320
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f46200027%2fuilabel-wrong-word-wrap-in-ios-11%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
I just hit the same issue and can only guess: It seems the text wrapping algorithm has changed in iOS 11 so the result is more balanced/looks more boxed.
– Sebastian
Sep 14 '17 at 14:02
Looks like we have the same issue too. This seems like a bug, because UILabel has historically been used in situations where we want to simulate typical word processor (or web browser) word wrap, not figuring out the smallest box that can hold all the text.
– David Dunham
Oct 6 '17 at 19:30
I'm seeing the same issue (with ampersands). If I build the app with Xcode 8 (against iOS 10) then run that build on iOS 11 I see the new word-wrapping behaviour. So, even when notionally providing backward-compatibility with an iOS 10 app, iOS 11 is word-wrapping differently.
– Geoff Hackworth
Oct 16 '17 at 7:50
I believe it’s a bug to force this behavior and finally got around to filing 36021540 with Apple. If anyone else files, you can reference this.
– David Dunham
Dec 13 '17 at 16:46
This issue is coming from ios 11
– Sazid Iqabal
Nov 1 '18 at 11:21