I'm floating some text around an image using CoreText and kCTJustifiedTextAlignment to show the text justiefied - but with larger images, smaller text-areas and less whitespaces CoreText does not only widen whitespaces but also the margin between the letters.
See here:
This sometimes looks really awful, so I searched for some alternatives or workarounds but only found the advice to do it myself by adding more whitespaces after each whitespace to match the width and using kCTLeftTextAlignment.
It sounds like a lot of snares to deal with, so I thought, I'd ask here, maybe anyone has an idea how to deal with that issue.
The basic question here is "so what do you want?" The other obvious answer is "full justify unless... some rules I'm going to make up like if there's only one word."
If you want that kind of control, then you need to drop down to the CTLine level and create justified lines only when you want them. Assuming you already know a bit about CoreText, this code should hopefully make sense. It justifies the line only if it isn't the last line of the paragraph.
CFIndex lineCharacterCount = CTTypesetterSuggestLineBreak(self.typesetter, startIndex, boundsWidth);
CTLineRef line = CTTypesetterCreateLine(self.typesetter, CFRangeMake(startIndex, lineCharacterCount));
// Fetch the typographic bounds
CTLineGetTypographicBounds(line, &(*ascent), &(*descent), &(*leading));
// Full-justify all but last line of paragraphs
NSString *string = self.attributedString.string;
NSUInteger endingLocation = startIndex + lineCharacterCount;
if (endingLocation >= string.length || [string characterAtIndex:endingLocation] != '\n') {
CTLineRef justifiedLine = CTLineCreateJustifiedLine(line, 1.0, boundsWidth);
CFRelease(line);
line = justifiedLine;
}
So we create a normal CTLine based on the CTTypesetter suggestion. Then we apply some rule (only one word? Not the end of the paragraph? Whatever.) If we pass, then we create a new, justified line. (I'm not certain why CTTypesetter can't create a justified line itself.)
For a full example of this, see PinchText. It's much more complicated than you need, but it shows how to do all the layout with lots of comments.
Related
I have a plist file which I decode to load data onto my application.
This plist file contains String type values that gets mapped to UILabel's text property.
I noticed that the truncating behavior of the text in the label is not always the same.
To be more specific, the three dots that are added when the text is truncated are, as opposed to my expectation, two kinds: one being ... and the other being ⋯ which appears to be this unicode character in this link.
I checked UILabel's attribute settings but I was unable to find any settings related to this behavior.
Has anyone else experienced this problem and standardized the truncating character to be ...?
Here is the image describing the problem mentioned above. Both labels have 2 lines and have new line escape character inserted between the first line and the second line of text. I am posting a link to this image because apparently I don't have enough reputation to post an image.
varying truncating characters of UILabel
IMO this is a bug in UILabel, and it may be worth opening a Feedback about it.
TL;DR: I recommend using TTTAttributedLabel.
Long-winded answer, because this was such an interesting question:
UILabel uses a different ellipsis based on the language script being truncated. As you've noticed, for most scripts, they use HORIZONTAL ELLIPSIS (…), or something very similar. But for Chinese, Japanese, and Korean (CJK), they use MIDLINE HORIZONTAL ELLIPSIS (⋯), or again, something very similar. The only other exception I've found is Burmese, which uses three circles that I don't recognize.
In my tests, all the following used …: Latin, Cyrillic, Bengali, Arabic, Hebrew, Hindi, Thai, Kannada, Nepali, and Mongolian (I kid. iOS can't layout Mongolian. Nobody can layout Mongolian, but it still uses …). UILabel even uses … for Lao, even though I thought ຯ was specifically for that, but I guess eventually everything becomes Latin.
The problem with UILabel being so clever for CJK and Burmese is that it decides what character to use exclusively by looking at the first character being removed. And it thinks SPACE is Latin (or at least not "special").
So what to do? My recommendation is probably to use TTTAttributedLabel, since it lets you configure the truncation character, and more importantly, is open source so you can fix it if it's not working the way you want.
The second option would be to truncate the text by hand using techniques like the one described in How to change truncate characters in UILabel?. There are probably better ways to do it using CTFrameGetVisibleStringRange instead of constantly shrinking the string until it fits, but I don't know if it's worth the effort. (If that path sounds useful, I could probably write up something that does it. It's just probably not worth the trouble.)
And the final option I know is to replace the SPACE character with an "equivalent" CJK character. The closest I've found that works is HANGUL FILLER (U+3164), but I don't like it. It's too wide, and I expect that it will make Korean uncomfortable to read (but I rarely try to read Korean, so I may be wrong here):
With SPACE: 안녕 하세요
With FILLER: 안녕ㅤ하세요
There's also HALFWIDTH HANGUL FILLER (U+FFA0), which is better, but UILabel seems to make it zero width (this may be a font issue, so maybe worth trying):
With SPACE: 안녕 하세요
With HALF: 안녕ﾠ하세요
let string = "안녕 하세요"
let filler = "\u{3164}"
label.text = string.replacingOccurrences(of: " ", with: filler)
OTOH, you may run into the same problem if you use any other non-CJK characters, like Latin punctuation or Arabic numerals. So this solution may not scale. And you should make sure that Voice Over properly ignores it.
I am trying to draw an NSAttributedString (actually, a constructed NSMutableAttributedString) where the "original" text has been struck and replacement text inserted above it (I'm trying to replicate the look/feel of an Ancient Greek manuscript).
My technique is a combination of NSBaselineOffsetAttributeName with NSKernAttributeName, but it appears that using a negative value for NSKernAttributeName "wipes away" the strikethrough of the text, even if the characters don't overlap.
If I put an extra space after the "A" character (in the original text), the "A" gets the strikethrough, but the "EI" is also offset to the right. So, it appears that the offset/kerning of the "EI" text affects how much of the strikethrough actually occurs.
Here's what I'd like to reproduce (I don't care about the angle; it's not about a picture-perfect reproduction; just the gist):
Here's what is currently happening:
This is when I add an extra space after the strikethrough:
So, the only other thing I can think of would be to render a separate NSAttributedString in the correct place, separate from the current one, but I have no idea how to calculate the location of a specific character in an NSAttributedString when it's drawn. I'm drawing to a PDF, not to any on-screen control like a UILabel. Alternatively, I could draw the "strikethrough" myself as a line, but that seems to still require knowing the coordinates for the text in question, which is calculated on-the-fly, and I hope to use this method to reproduce a large sample of ancient texts, which means doing it by hand just isn't a good answer here.
Anything I'm missing, or any out-of-the-box ideas to try?
A multiline auto typing text box class (which uses an SKNode as the parent) is created using basically 2 elements:
an SKSpriteNode that acts as text box frame & background image/texture holder.
an NSMutableArray containing a set limited amount (rows) of NSStrings that each have a set character length.
After modifying this text box class so that it can be initialized with any frame width & height, I realized I didn't program the NSMutableArray to automatically change its content in a such way that it nicely fits within the background node (with a bit of padding involved as well). So here I am wondering how to do that since NSString's can only return the character count and not the width & height of each string in points (points could have maybe helped me create character constraints in some way).
Right now, the NSMutableArray uses a hardcoded maximum character count per NSString & a maximum row count for the entire array (it's 5 rows right now and when that limit is reached, a new "page"/array is created). This forces me to manually re-adjust these parameters every time I change the background node frame size which defeats the purpose of the class allowing the background frame to change.
Thing is, I'm trying to solve this in such a way that when I post this class on github, I want the solution to take into consideration any fontName & fontSize.
What are my options for solving this problem?
I've done something similar to this. It doesn't work 100% as to what you want, but should be similar enough. It uses a root node and from there, it will build multi-line text using an array of NSString which will in turn be used to build the SKLabelNode.
I'll outline what I did. I should also say I only run this when new text is set. In other words, I do not incur the penalty of deriving the information every frame. Only once.
The generalized steps are:
You will iterate over each character in the text string. Note I do this because my code supports word wrapping as well as other alignment capabilities. So for me, I want that level of control. As this is being done only upon creation, I'm fine with the overhead. If you don't want to word wrap you could always just create an array of words and work from there.
As you iterate over each character, you'll be generating an array of lines. Where each line in the array is a line that will fit in your frame. For now let's not worry about vertical constraints. So here we are primarily worried about width. For the current line, each character you are iterating over will get added to the current line. For this potential line string, you will use NSString's sizeWithAttributes, which is configured for your font. For example in my code it is an NSDictionary which contains: NSFontAttributeName : [UIFont fontWithName:self.fontName size:self.size]. This will be used to check the width, if that width exceeds the frame width, you are overrunning the line.
So the code may look something like:
size = [line sizeWithAttributes:attributes];
if (size.width > maxTextWidth) {
needNewline = YES;
}
If you have overrun a line, you need to determine if you are word wrapping. If you are, you can just add the current line (minus one character) to the lines array. If not you have prune off the last word in the current line and then add that to the array of lines.
The tricky parts are dealing with whitespace and handling non-word wrapped overflow. I have not addressed whitespace but you need to consider this very much in your code. Additionally, you also do want to factor in leading pixels, etc.
Once you have your array of lines, you can then create your children SKLabelNodes. I add them to the root, which allows me to move the group anywhere it needs to be.
The real key here is the lines array generation.
I'm working on an app where I need all lines of text to be Justified alignment. The app will display 2 lines of text over the top of an image, creating an Advert like feeling to the picture. The problem is that both these lines of text need to be justified, but the 2nd line of text will never be justified. Or if I draw both lines separately then neither will be justified.
If you specify kCTJustifiedTextAlignment in CoreText or NSJustifiedTextAlignment on NSTextField/View all but the last line of text are justified. The last line is aligned naturally.
Is there a way to force the final line of a textfield or textview to be justified, so fill the width of the view?
I've thought about using CTLine to draw each line separately, and specifying something on those to make all of them justified, but I'm not sure how to go about that either.
Thanks
Thanks to omz's comment I stumbled across CTLineCreateJustifiedLine, which gives me just what I wanted. I'd still be interested if someone has a solution using a Cocoa Control (NSTextView), but i'd be surprised if there was anything tbh.
CTLineRef line = CTLineCreateWithAttributedString((__bridge CFAttributedStringRef)attString);
line = CTLineCreateJustifiedLine(line, 1.0, dirtyRect.size.width);
CTLineDraw(line, context);
CFRelease(line);
We have an app that is dependent heavily on kCTParagraphStyleSpecifierParagraphSpacing to manage spacing between paragraphs, which can vary throughout a body of text. For editing performance, we implemented our main Core Text view as a collection of CTFrames that are drawn/redrawn when appropriate.
We've found that if a paragraph uses a nonzero kCTParagraphStyleSpecifierParagraphSpacing as one of its CTParagraphStyleSettings attributes, this paragraph spacing is ignored if that paragraph is the first item in a CTFrame, even if there is a another paragraph preceding it in the text fed to the framesetter.
I suppose this behavior makes sense if you're drawing to a PDF intended to be printed, but given that we're trying to present our text a a single, scrollable and contiguous block of text, it is giving us problems. Is there any way to work around this problem?
If you can't change the behavior with a CTParagraphStyleSetting, I think it's a bug, or Apple thinks that behavior makes sense. Anyway, to get the result that you desire, I think the best way is to use CTTypesetter and handle lineSpacing and paragraphSpacing yourself. I think the CTFrame implementation is quite buggy, as I just run into another not long ago.
For rolling your own solution, you will need CTTypesetterSuggestClusterBreak or CTTypesetterSuggestLineBreak to calculate char count of each line. Line height can be the font size, and you add lineSpacing when drawing each line. When you encounter a newline(\n) character, add paragraphSpacing before drawing next line.
With CTTypesetter, things are more controllable, of course, it also adds some difficulties since you have to handle line breaks and indentation. But this is the only way I can think of to get a more desired result.
Good luck.