Is there a way to override the default "text-max-width" label wrapping and inject my own custom line breaks on a symbol feature label? Unfortunately for my current uses, "text-max-width" is strictly defined by em units and not actual character limits.
I'm attempting to break at specific characters and was hoping that setting "text-max-width" to 0 would give me control over line breaks. Currently if I inject "\n" within my string while "text-max-width" = 0, those custom breaks will be ignored and the label will instead be drawn as a single line.
Is there currently a way to work around this in mapbox-gl-js; or would this type of functionality be a new feature?
Just for clarification: \n in text-field is supported since v0.24.0. text-max-width defaults to 10em. Setting it to 0 disables all wrapping, including \n, in v0.33.1.
This may feel wrong, but setting text-max-width to Infinity should work.
The code responsible for text wrapping is in src/symbol/shaping.js, starting withshapeText(..., maxSize, ...). A quick look didn't reveal any problems with using Infinity, but I also found no other way.
Related
I would like the name of a custom component in Dymola to be displayed on two lines.
When I use %name or %paramName (where paramName is the name of a String parameter of the component) in the TextBox, the name gets written on one line, even when there is space for two, and even when i try to use any of the following: \n, <br>, \\n...
So the only solution I found so far was to create two parameters, nameLine1 and nameLine2, and to use them inside the TextBox, where I can put each parameter on a different line easily by using S+RET.
Yet I find this solution quite cumbersome. Is there any way to do it more easily?
No, I think not. That's a very general problem Dymola/Modelica has with text boxes in the graphical layer. There is no auto-wrap.
You have two options (unless you go for your multi-parameter-solution). Make sure that there is not font size set (which is the default), then:
Use text box with non-zero width. Dymola will try truncate the text (but it's not very good at it)
Use a text box with zero width. Dymola will automatically adjust the width to the content.
Oh, there is a third, maybe not so bad option: Don't use so long names.
In Bangla, Hosonto (U+09CD) is used to create a ligature, which joins adjacent letters. For example ক্ক is created using ক + ্ + ক. But sometimes we need a non-joining Hosonto (ক্ক). To make it possible, traditionally we use a Zero-width non-joiner (U+200C).
The problem with ZWNJ is that, when the line is too long and line wrapping occurs, the word is broken into two lines. To keep the word as a whole, I need a character, something like “Zero-width non-breaking non-joiner”. But I don’t see such character in Unicode. So I think, Word Joiner (U+2060) is the best option.
To me, Word Joiner sounds like “joins two words”. But in my case, I need to join two parts of a single word. So, the question is, is it correct to use Word Joiner here?
U+200C ZERO WIDTH NON-JOINER has no effect on line breaking. Its absence or presence does not change where line wrapping can occur. If inserting a ZWNJ within a word causes that word to be broken across lines, then whatever application you are using to view your text does not implement the standard correctly.
ZWNJ is the only correct character for your purposes. More than that, using U+2060 WORD JOINER could in fact lead to inconsistent results. Much like ZWNJ does not affect line breaks, WJ is not supposed to affect joining behaviour (it is defined as “transparent” in that regard). While the standard doesn’t explicitly mention cases like this to the best of my knowledge, one could reasonably argue that inserting a WJ between the two letters in your example should not change the way they are displayed.
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".
I recently found out about adaptive-wrap.el, which works very well with unscaled text. But as I often use Emacs (24.3) in text-scale-mode, I have noticed that the wrap prefix does not scale with the remainder of the text.
As you can see, the second and third lines are only indented by the width of the unscaled prefix. How do I change adaptive-wrap.el to account for different text scales?
This might seem like the pettiest of requests, but I may as well try and remove a tiny bit of unexpected behaviour.
adaptive-wrap.el
Using iReport 4.5.0, I'm setting these two properties and values:
net.sf.jasperreports.text.truncate.at.char=true
net.sf.jasperreports.text.truncate.suffix=...
The intent is to add "..." to the end of textfields whenever they must be truncated, and that the truncation determination happens at the character level, rather than at the word level. This works as expected when exporting to PDF. However, when exporting to HTML, the last truncated token (with the suffix appended) will often, though not always, wrap incorrectly. (It does this even though StretchType is set to No Stretch.) Example:
If I change net.sf.jasperreports.text.truncate.at.char=false (so that it breaks on words instead of characters) it seems to work more often, but only because word breaks usually leave more space for the suffix. The unexpected line wrapping still occurs with word breaks, especially if I increase the length of the given suffix.
My best guess is that the HTML exporter measurement isn't precisely calculating the width required by the given suffix (if it's calculating it at all).
Can anyone confirm?
Any suggestions as to a workaround?
It seems like with StretchType set to No Stretch, that the HTML exporter should probably also set white-space:nowrap. However, although that would prevent the line from wrapping, the end of the suffix would be partially hidden (due to overflow:hidden styling).
"My best guess is that the HTML exporter measurement isn't precisely calculating the width required by the given suffix (if it's calculating it at all)."
I confirm that this is surely the reason.
But there's not really a simple workaround. Your PDF is good, so you're doing something right. Well... you're doing lots of things right. ;-)
In HTML you don't know--in a very fundamental way--the precise details of the font that will render the text. You can certainly specify the font. But the client machine might not have it. Or it might have one that is the same... but not quite the same. Or the client might choose to use a different font or different size via various client-side override mechanisms.
If you try different fonts, you should notice slightly different results. You may be able to find one that works better more often. (Clearly, this isn't 100% perfect.)
If you aren't using Font Extensions, then you should. If you are using Font Extensions, then you can specify the list of fonts in descending preference that ought to be used in the HTML. This should give you enough control to get behavior that is good in a large number of cases. Often you can make it perfect in all of the cases that you care about.