I'm doing some text rendering in Cocoa using NSAttributedString, and setting the font and underline properties, etc. However, I can't figure out how I can change the text's tracking. Any suggestions?
I don't think font tracking is an exposed property for text layout with attributed strings.
You could perhaps use the available expansion attribute on whitespace, and manually insert whitespace characters with scaling factors to influence their width, but I expect that would be a fiddly hack for anything other than trivial cases.
The only other route I can think of is to use your own custom attributes along with an NSLayoutManager subclass. The cocoa text system is extremely flexible, but with that flexibility comes a greater degree of complexity.
My solution so far has simply been to use the kerning attribute, as tracking and kerning are similar. Is there any better solution?
Related
I'm doing color transformations on glyphs rendered with CTFontDrawGlyphs, but I do not want to do those transformations to the emoji glyphs, since they have already a meaningful color information.
So, when I have a CTRun of glyphs, can I detect if it is actually emoji/color font?
I can do a string compare to the postscript name with "AppleColorEmoji", but seems awfully wasteful to do all the time, and somewhat hacky if there ever happens to be another font with the same features.
Ah, I can get the symbolic traits with CTFontGetSymbolicTraits, and check for kCTFontTraitColorGlyphs (or kCTFontColorGlyphsTrait), which, while undocumented, is available in the public headers.
I'm trying to change the letter spacing in a NSFont (such as Gill Sans). Is this possible or will I need to load my own custom font?
Though I suppose fonts might specify some kerning hints, kerning is really an attribute of rendered text. So the answer to your question depends on how you're going to render your text to the screen.
If you're using NSAttributedString, you can look at the NSKernAttributeName attribute (see the Constants section in the documentation. If you're using CoreText and CFAttributedString, you can look at the kCTKernAttributeName attribute (see the Constants section in the documentation.
If you're using something else to render text, then the answer (if there is one; not all text rendering methods support advanced customization) will be dependent on that something else.
Say we have an overlay DHTML panel on a web page that contains two buttons in the top occupying whole width of the dialog, like this:
Text for Button 1 and Button 2 should be localized. Content of checkbox group is static and should not be localized.
There can be a big difference between button text width in different languages (~100% extra space in comparison with English version).
The question is which strategy to apply for sizing Button 1 and Button 2 depending on the length of the text content:
Make buttons fixed width and truncate text content with ellipsis.
Make buttons fixed width and wrap text content on the subsequent lines making buttons grow in height.
Make buttons fixed width but make them wide enough to host text in all languages without truncation or wrapping.
Make buttons dynamically adjust width and make panel grow horizontally with their size.
I am leaning towards using third or forth option according to the several UI localization best practices that were found:
Preparing the User Interface for Localization
Best Practices for Globalization and Localization
Globalization Step-by-Step - UI Considerations
Still we have some debate in the team discussing the best option and it would be interesting to hear concious outer voice of the community.
I am interested in the best approach for this specific case as well general guidelines for solving web UI sizing issues in regards of localization.
Thanks!
As you perhaps know, text shortened with ellipsis (or with a single dot) could be incomprehensible:
How compr. is th.?
You should seen a lot of this staff in mobile area (phones, tablets, etc.), such translations look ugly. OK, with lower screen resolutions you actually end up with no choice (unless you can create some auto-scrolling text). But in case of web interface you certainly have a choice.
Typically, there are two kind of solutions corresponding to your points #3 and #4. Personally, I am leaning to #4 - make buttons auto-sizable. This of course will result with inconsistently sized buttons, but there is little we can do about it.
If you cannot use solution #4 (i.e. UI Designer is strong opponent of this technique), you may modify solution #3 a bit. Basically, what I used in past projects was, I had buttons of fixed sizes and default size was capable to fit most of languages (except Polish and Russian of course), but I also had several CSS classes that defined wider buttons. When localizing into "too long" languages I simply used the most wide button class I could. If the text still didn't fit, then I asked the translators for shortening it (usually re-phrasing it and shorten the text with a single dot as a last resort).
However, please keep in mind that it increases localization costs. This is the reason I would not recommend this method.
As for solution #2, you will end up with ugly looking UI. You simply have no control over how browser will wrap a text, and you will have a lot of texts that go outside the button clipping rectangle (overlap it).
As for solution #1, using ellipsis is a bad idea for two reasons. First one is, ellipsis is not valid in many languages (this especially regards to Asian languages). The second one is, as I understand you want to do that automatically. In this case, you won't be able to measure strings - their actual, on screen size, written with a fall-back font. In case of web UI, you don't know whether user has particular font installed, so you will be guessing the size (OK, with Dojo you can theoretically measure it on the client side). This will of course result in overlapping text (if you decide on dynamic shortening over your chosen font) or totally incomprehensible text (if you decide on shortening after say 8 characters). I had a project which started to use static shortening, it was a total mess. Then we switch to dynamic and it is still not good enough.
To counter potential UI Designer argument that goes "we have no space for string expansion", I can only say that means that you designed the interface incorrectly for it is too crowded. This is the point where I18n goes hand in hand with UI design best practices: strive for simplicity (in UI design). The result would be easy to use and easy to localize application.
I want to have a subscript and superscript in my GUI in Matlab. So far I have tried to use x_2 and x^2 and neither of them work. Is there anyone who knows how to do this?
Thanks in advance!
From http://www.mathworks.com/matlabcentral/newsreader/view_thread/158410#398940
You can use an undocumented feature of all Matlab uicontrols, which is
the fact that they use underlying Java Swing controls, and these in
turn accept any valid HTML strings. So you can do the following for
example:
uicontrol('string','<html><b>1<sub>2</sub>3<sup>4</sup>5</b></html>')
This is equivalent to the tex string '\bf1_23^45\rm'. You can set font
faces, colors, sizes, bold/italic and any other valid HTML 3.0
property. It's limited, but should do the trick in most conceivable
cases.
The same is true for tooltips, by the way: try setting multi-line
(<br>) multi-colored (<font color="red"> ... </font>) tooltip once and
you'll never use the standard boring single-line black tooltip
again...
And just in case you were wondering - yes, it also works for menus,
listboxes etc.
This could probably also be asked as "Is kCTKernAttributeName a misnomer?"
I need to change the letter spacing/tracking of some text in iOS. (The font I'm using is a little too tight at small sizes.) There are core graphics routines that will change character spacing, but those routines don't handle Unicode. There are other core graphics routines that are defined in terms of glyphs but those seem like a world of hurt, among other things, not having the safety net of reverting back to system fonts for glyphs that don't exist in my font.
So core text seems like the way to do this and core text supports kCTKernAttributeName on CFAttributedString. I think this will do what I want, though this really isn't kerning since kerning is a generally a character-pair attribute and this (appears to be, from the docs) just a uniform adjustment to the glyph advance for all glyphs, i.e., tracking.
If anyone knows before I go down the rather painful path of converting to the core text API ...
kCTKernAttribute name should do what you want. Setting it over a range of text adjusts the inter-glyph spacing consistently, irrespective of the specific glyphs.
I think part of the problem is that kerning seems to have been a virtual synonym of tracking (it's still just "adjust the spacing between (letters or characters) in a piece of text to be printed" in the dictionary that comes with OS X), and is now adopting just the meaning of pair kerning because of the redundancy. Probably an etymologist would be better placed to comment on that side of things...