What does it mean for a CTLine to have "string access"? - iphone

I'm trying to solve a hairy problem with UILabel, and I've gotten most of it figured out, except for one thing: I'm having a challenge understanding what it means for a CTLine to have "string access".
The method that I'd like to use is CTLineGetOffsetForStringIndex. Here's a link to the documentation for the method.
Here's the part of the documentation that I don't understand (emphasis is mine):
The primary offset along the baseline for charIndex, or 0.0 if the
line does not support string access.
When I'm running this method, I'm getting 0.0 back, so I guess that means the line doesn't support string access - but what does that mean, exactly?

The statement "the line does not support string access" may be inferred as meaning that the line of text may not be treated as a sequence of characters that may be accessed by the index of each character.
This may open up a large discussion about visual characters versus non-visual characters, and glyphs versus characters. But to simplify the discussion, assume that a line of text may have one of the following states:
more than zero characters (characters which translate to either glyphs or whitespace within the same line) are present in the line of text in question
there are no characters in the line of text which occupy any "space"
Now to provide some rationale for this inference.
Apple's documentation provides a description of Text Kit, upon which UILabel is built:
The UIKit framework includes several classes whose purpose is to display text in an app’s user interface: UITextView, UITextField, and UILabel, as described in Displaying Text Content in iOS. Text views, created from the UITextView class, are meant to display large amounts of text. Underlying UITextView is a powerful layout engine called Text Kit. If you need to customize the layout process or you need to intervene in that behavior, you can use Text Kit. For smaller amounts of text and special needs requiring custom solutions, you can use alternative, lower-level technologies, as described in Lower Level Text-Handling Technologies.
Text Kit is a set of classes and protocols in the UIKit framework providing high-quality typographical services that enable apps to store, lay out, and display text with all the characteristics of fine typesetting, such as kerning, ligatures, line breaking, and justification. Text Kit is built on top of Core Text, so it provides the same speed and power. UITextView is fully integrated with Text Kit; it provides editing and display capabilities that enable users to input text, specify formatting attributes, and view the results. The other Text Kit classes provide text storage and layout capabilities. Figure 8-1 shows the position of Text Kit among other iOS text and graphics frameworks.
Figure 8-1 Text Kit Framework Position
Text Kit gives you complete control over text rendering in user interface elements. In addition to UITextView, UITextField and UILabel are built on top of Text Kit, and it seamlessly integrates with animations, UICollectionView and UITableView. Text Kit is designed with a fully extensible object-oriented architecture that supports subclassing, delegation, and a thorough set of notifications enabling deep customization.
The answer to the related question mentions several classes such as NSTextStorage, NSLayoutManager, and NSTextContainer.
Consider that the UILabel uses all the above classes to provide the end result of displaying text in the parent UIView, which the end user sees on the screen. A layout manager (an instance of NSLayoutManager) coordinates data flow between the text view, the text container, and the text storage, resulting in the display of characters in the view. The layout manager maps the characters to glyphs, and figures out which lines to use to lay out the glyphs. The layout manager also figures out how to display things like underline and strikethrough, which are not part of the glyphs.
Important to this discussion is the fact that the Layout Manager lays out lines of text. If that line of text is selectable, the user may select visible characters in the line. In this particular case, there is "string access" for the line.
A similar concept is the method posted in the solution to related question:
func boundingRect(forGlyphRange glyphRange: NSRange, in container: NSTextContainer) -> CGRect
Returns a single bounding rectangle (in container coordinates) enclosing all glyphs and other marks drawn in the given text container for the given glyph range, including glyphs that draw outside their line fragment rectangles and text attributes such as underlining.
Finally, the reference discussion for the function CTLineGetOffsetForStringIndex speaks about graphical offsets which are suitable for drawing custom carets. The carets may be used to show insertion points or text selection. The primary and secondary offsets may be thought of as beginning and end indices for a string -- a sequence of characters. If there is no sequence of characters for a given line, there can be no selected characters, no carets, no range of glyphs. Therefore no "string access".

Related

Why does the TextBox character ordering change with FlowDirection RightToLeft

In my UWP app I have a textbox.
I want the user to be able to type Farsi / Persian text (right to left) into the textbox so I set the FlowDirection property to RighToLeft.
The text can be entered and is displayed correctly:
When I save the text, and inspect the property during debugging, i see the same character order as on screen:
The same character order applies for the stored value when viewed with mssql management studio:
When I add a '.' or a '!' at the end of the text, the WPF textbox still displays what I expect,
but the text I get back from the text property puts the exclamation mark at the right side of the string.
It is also stored this way in the sql database:
When loading the database value (with the exclamation point on the right) into the textbox it shows the exclamation point correctly on the left side. There must be some magic happening here that I am not aware of, or maybe the problem is that the debug preview / mssql preview does not support displaying RTL values.
My problem is that this magic does not work in other situations.
When I load the database value and put it in a microsoft word document, it seems to do no conversion and place the text in the document exactly as it is in the database, resulting in the exclamation point to be shown on the 'wrong' side.
I would like to understand the 'magic' that takes place in displaying / storing these strings, so I can output it correctly in MS Word. And Yes, I have set the paragraph where I output the values in word to RTL.
In Unicode, all characters have directional properties that get used in the Unicode Bidirectional Algorithm for determining how characters are ordered visually. Most characters have a "strong" directional property, but not all. In particular, most punctuation characters are considered directionally neutral.
The visual ordering of neutral characters is determined by the characters that surround them. For example, the exclamation mark ! is neutral; if it occurs between two left-to-right characters, it will be treated as though it also is a left-to-right character. But if it occurs between two right-to-left characters, it will be treated as though it is a right-to-left character.
In your example, though, the exclamation mark occurs at the end of the string. So, it has a strong-direction character on one side, but nothing on the other side. In this case, another factor comes into play, which is that the paragraph as a whole has a base direction.
The Unicode Bidi Algorithm allows two ways that apps can handle the paragraph base direction:
the app can set the base direction explicitly, regardless of the string content in the paragraph; or
the app can let the base direction be derived implicitly from the string: the base direction is determined by the first strong-directional character in the string.
In your UWP app, when you set the flow direction to RTL, then the paragraph base direction (for purposes of the Bidi Algorithm) is RTL. With an Arabic-script string that ends with the exclamation mark, the directionality of the exclamation is set to RTL because of the paragraph base direction, and so it appears at the left end of the string. But when you view the control property value in an IDE, the IDE is presenting that property string in a control that has LTR base direction. That is causing the exclamation at the logical end of the string to appear visually at the right end.
Note that apps will often conflate base direction and alignment, though these are really distinct things. In Word, you can set the paragraph base direction in the Paragraph settings dialog, and when you do it will set the alignment to match by default:
But you can override the paragraph alignment to have a RTL base direction with left alignment:
Note that the visual order of the exclamation mark is affected by the paragraph base direction but not by the alignment. The Unicode Bidi Algorithm doesn't pay attention to the alignment.
This article gives a good overview of how the Bidi Algorithm works: https://www.w3.org/International/articles/inline-bidi-markup/uba-basics.
If you want to explore how the Bidi Algorithm works in more detail, you can read the spec, Unicode Standard Annex #9, Unicode Bidirectional Algorithm; and check out this Unicode utility that explains how the rules of the algorithm apply to sample strings you can provide.

Swift: Unicode transformations: How to generate a rainbow infinity symbol

In xcode, developing for iOS "\u{1F3F3}\u{FE0F}\u{200D}\u{1F308}" is a rainbow flag.
"\u{1F3F3}" is a white flag, and "\u{1F308}" is a rainbow. The middle symbols "\u{FE0F}\u{200D}" are invisible symbols used to join these two together to make the rainbow flag symbol.
I am trying to combine unicode characters to make a rainbow infinity symbol, but not exactly sure how to implement this.
Not sure if there is an already existing unicode character or apple api I can use to do this, but would appreciate learning how to do this
I wouldn't mind having an infinity symbol over the rainbow flag either (like the apple anti-lgbt flag incident) as an alternative.
Emoji fonts are still just fonts. If they don’t contain a specific glyph, then they cannot display that glyph. The reason “🏳️‍🌈” looks like a rainbow flag is because someone drew a picture of a rainbow flag and then defined their font in such a way that the sequence <U+1F3F3, U+FE0F, U+200D, U+1F308> would be displayed using that specific image. Much like how someone first had to define the precise shape of the letter “A” in their font and then apply that glyph to the codepoint U+0041.
There is no image-rendering code that instinctively knows how to apply the colours of 🌈 to the shape of 🏳️ and then automatically generates a new glyph on the fly. It’s all explicitly pre-defined.
U+200D is the so-called Zero Width Joiner (ZWJ), so emoji sequences using that character are appropriately named Zero Width Joiner Sequences. They were originally invented by Apple to support emoji that weren’t part of the Unicode standard (in particular, variants of 💏, 💑, and 👪️ with different gender configurations), but later other vendors jumped on board as well and nowadays they are officially part of Unicode as an alternative way for defining new emoji without having to encode entirely new characters. Currently, about a third of all officially recommended emoji are ZWJ sequences.
In theory, any person can make up their own ZWJ sequences just by joining existing characters together (as was their original intent). In your case, “♾️+ZWJ+🌈” or <U+267E, U+FE0F, U+200D, U+1F308> would be an obvious sequence for a rainbow-coloured infinity symbol. You just have to create your own font containing the glyph you want, and then distribute that font to other people so that they can see the same glyph as you. There are just a few problems:
Making fonts with colourful glyphs is not easy. I couldn’t tell you whether there even exist freely available tools for that task.
There are four different formats for emoji fonts (used by Apple, Google, Microsoft, and Mozilla respectively) and they generally do not work on each other’s platforms, so you would need to create not just one, but several fonts unless you don’t care about people on other operating systems.
Installing your own fonts is not possible on most mobile phones, so your custom emoji would mostly only be available to desktop users.

Can I use semi-graphics to display badges in terminal?

I want to display some single-line badges (with rounded corners) in terminal but I am not aware of any box characters to use for start and end of labels. Are there any?
The label text would be normal text on coloured background, the only issue is that i need some elements to make it more visually appealing.
Not semicircles, but there will be more box-type graphics characters soon. Unicode 13.0, scheduled for March 2020*, will have a new block: "Symbols for Legacy Computing". This was designed for emulation of various 1970s and '80s computers, but some of the characters could also be useful for more modern purposes. This PDF has the code chart.
*Of course, that's just when the codepoints become official, you will still need to find a font that has the characters.
Apparently this is not possible as I failed to find any Unicode characters that do that.
The only one closer to enabling building a badge-like construct is U+258C also known as left half block: ▌.
Its sibling is U+2590.
Obviously that it does not have rounded corners so this would not help a lot visually.

Where to get a reference image for any unicode code point?

I am looking for an online service (or collection of images) that can return an image for any unicode code point.
Unicode.org does not have an image for each one, consider for example
http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=31cf
EDIT: I need to use these images programmatically, so the code chart PDFs provided at unicode.org are not useful.
The images in the PDF are copyrighted, so there are legal issues around extracting them. (I am not a lawyer.) I suspect that those legal issues prevent a simple solution from being provided, unless someone wants to go to the trouble of drawing all of those images. It might happen, but seems unlikely.
Your best bet is to download a selection of fonts that collectively cover the entire range of characters, and display the characters using those fonts. There are two difficulties with this approach: combining characters and invisible characters.
The combining characters can easily be detected from the Unicode database, and you can supply a base character (such as NBSP) to use for displaying them. (There is a special code point intended for this purpose, but I can't find it at the moment.)
Invisible characters could be displayed with a dotted square box containing the abbreviation for the character. Those you may have to locate manually and construct the necessary abbreviations. I am not aware of any shortcuts for that.

How to make the 1st line in certain amount of text in a Label bold?

I have about 400 character length string with a heading called Details. In this 'Details' is to be bold and of fontsize 19. While all the remaining text starts in the next line and should be of fontSize 18 like the contents. How can I do all this by using a UILabel?
Plz help me...
You can't do it with a stock UILabel as of SDK 3.2. You can create an NSAttributedString that specifies particular styles (like bold) for particular parts of the string, but there isn't a simple way to actually render it. This is unlike In Max OS X, which has NSAttributedString(AppKitAdditions), which allows you to draw an attributed string in a single line of code. If you want to render it, you can, but you'll have to delve into one of the lower level APIs (such as Core Text).
You're probably much better off using two UILabels. Make the first one bold, and make the second one cover multiple lines.
Since UILabel does not support attributed strings, you have two options:
Subclass UILabel and override -drawRect:
Create 2 UILabels, one of which will display the heading, the other showing the rest of your text. You can choose to wrap the two labels into your own view if necessary.
You could use a UIWebView with an HTMLString of <strong>First part</strong> second part