In an AudioUnit plugin, I'm using NSFont.
NSFontManager* fontManager = [NSFontManager sharedFontManager];
NSFont* nativefont = [fontManager fontWithFamily:[NSString stringWithCString: fontFamilyName.c_str() encoding: NSUTF8StringEncoding ] traits:fontTraits weight:5 size:fontSize ];
NSMutableParagraphStyle* style = [[NSMutableParagraphStyle alloc] init];
[style setAlignment : NSTextAlignmentLeft];
NSMutableDictionary* native2 = [[NSMutableDictionary alloc] initWithObjectsAndKeys:
nativefont, NSFontAttributeName,
style, NSParagraphStyleAttributeName,
nil];
// .. later
void someFunction(NSMutableDictionary* native2)
{
float lineGap = [native2[NSFontAttributeName] leading];
Compiler says (about last line): assigning to 'float' from incompatible type 'NSCollectionLayoutSpacing * _Nullable'
NOTE: This has only failed recently since switching to Xcode 11.1, on an older version of XCode it built OK. Any help appreciated.
In your code, the expression native2[NSFontAttributeName] is of unknown type, and therefore of type id. The compiler will let you send an object of type id any message without complaint, but it has no context for determining the type of the message's return value.
You want to get the leading property of NSFont, but the compiler is just picking any leading property selector at random and I'm guessing it has ended up choosing the leading property of NSCollectionLayoutEdgeSpacing which has a return type of NSCollectionLayoutSpacing not float.
I suspect that casting the expression [(NSFont*)(native2[NSFontAttributeName]) leading] would do the trick, but if I were writing this code I'd simply refer to the original (typed) object, since you already have it:
float lineGap = nativefont.leading;
Related
I'm using the NSAttributedString UIKit Additions to draw an attributed string in a UIView. The problem I have is that despite using a value of NSWritingDirectionNatural for the baseWritingDirection property of my paragraph style, text always defaults to left-to-right.
Here's how I form the attributed string (simplified):
NSString *arabic = #"العاصمة الليبية لتأمينها تنفيذا لقرار المؤتمر الوطني العام. يأتي ذلك بعدما أعلن اللواء الليبي المتقاعد خليفة حفتر أنه طلب من المجلس الأعلى للقض الدولة حتى الانتخابات النيابية القادمة";
NSMutableParagraphStyle *paragraph = [[NSMutableParagraphStyle alloc] init];
paragraph.baseWritingDirection = NSWritingDirectionNatural;
paragraph.lineBreakMode = NSLineBreakByWordWrapping;
NSMutableDictionary *attributes = [[NSMutableDictionary alloc] init];
attributes[NSParagraphStyleAttributeName] = paragraph;
NSAttributedString *string = [[NSAttributedString alloc]
initWithString:arabic
attributes:attributes];
And here's how I draw the text:
- (void)drawRect:(CGRect)rect {
[self.attributedText drawWithRect:rect
options:NSStringDrawingUsesLineFragmentOrigin
context:nil];
}
And yet it still flows from left to right:
What am I missing?
I don't believe the writing direction will be automatically set for you using baseWritingDirection unless you switch languages on the device:
"If you specify NSWritingDirectionNaturalDirection, the receiver resolves the writing direction to either NSWritingDirectionLeftToRight or NSWritingDirectionRightToLeft, depending on the direction for the user’s language preference setting."
For some reason the text you have still doesn't seem to work even with arabic selected without adding the language to your supported localizations. This character seemed to work without doing that for me: كتب
Also, it looks like Xcode reverses the characters in hardcoded arabic strings so that may be screwing with some of this copy and paste.
You can use agiletortoises's suggestion or NSLinguisticTagger's Language tag scheme to manually set the language.
I can't explain why it does not work the way you have it written, but I've been using a solution to explicitly set the direction based on known RTL languages, which used this as a starting point:
https://stackoverflow.com/a/16309559
No idea if this is related or not, but when I tested the right-to-left support in Auto Layout, it didn't work until I added a localization for that language (Arabic, Hebrew, etc) to the app.
Is there any replacement for Windows's CreateFont(..) function in OSX?
I've tried to use NSFontDescriptor and its matchingFontDescriptorsWithMandatoryKeys: method, but this method doesn't find the "closest" font, it finds the matched characteristics and also it can return nil.
Is there any way to find the closest font by specified characteristics (like a CreateFont) in OSX?
UPDATED
Something strange happens with NSFontDescriptor..
I have two pieces of code:
on Cocoa:
NSDictionary* fontTraits = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithInt:NSFontSansSerifClass], NSFontSymbolicTrait,
[NSNumber numberWithFloat:0.4], NSFontWidthTrait,
nil];
NSDictionary* fontAttributes = [NSDictionary dictionaryWithObjectsAndKeys:
fontTraits, NSFontTraitsAttribute,
nil];
NSFontDescriptor* fontDescriptor = [NSFontDescriptor fontDescriptorWithFontAttributes:fontAttributes];
NSArray* matchedDescriptors = [fontDescriptor matchingFontDescriptorsWithMandatoryKeys:nil];
And using CoreText API:
CFMutableDictionaryRef fontTraits = CFDictionaryCreateMutable(kCFAllocatorDefault, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
float weight = 0.4;
CFNumberRef fontWeight = CFNumberCreate(kCFAllocatorDefault, kCFNumberFloat32Type, &weight);
CFDictionaryAddValue(fontTraits, kCTFontWeightTrait, fontWeight);
int symbolicTraits = kCTFontSansSerifClass;
CFNumberRef fontSymbolicTraits = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &symbolicTraits);
CFDictionaryAddValue(fontTraits, kCTFontSymbolicTrait, fontSymbolicTraits);
CFMutableDictionaryRef fontAttributes = CFDictionaryCreateMutable(kCFAllocatorDefault, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
CFDictionaryAddValue(fontAttributes, kCTFontTraitsAttribute, fontTraits);
CTFontDescriptorRef fontDescriptor = CTFontDescriptorCreateWithAttributes(fontAttributes);
CFArrayRef matchedDescriptors = CTFontDescriptorCreateMatchingFontDescriptors(fontDescriptor, 0);
I've created the same font descriptors in both cases, but in first case matchedDescriptors is nil and with CoreText API there are some fonts in matchedDescriptors. Is it a bug?
But in general, if I pass nil to XXXMatchingFontDescriptorsXXX as mandatory attribute, should it return at least one descriptor?
I would please file a Radar if you haven't. I just got bit by this same difference in behavior myself.
A surprising thing while debugging, I found that [fontDescriptor matchingFontDescriptorWithMandatoryKeys:] is actually defined, though not documented, and functions as expected for a single descriptor that is. Meaning, it works just like CTFontDescriptorCreateMatchingFontDescriptor().
While [fontDescriptor matchingFontDescriptorsWithMandatoryKeys:] definitely appears broken to me.
I found this problem when I was using [UIFont fontWithDescriptor:size:], and it was matching things just fine, and as expected. Then I switched to [fontDescriptor matchingFontDescriptorsWithMandatoryKeys:nil], and it returned nil for the same descriptor.
Something felt off, so I compared with CoreText APIs as you did, and came to the conclusion that I am sharing with you here.
I know you are looking at the list versions of these methods, I figured I would share that I went with this method in a UIFontDescriptor category:
- (nullable instancetype)my_matchingFontDescriptorWithMandatoryKeys:(nullable NSSet<UIFontDescriptorAttributeName> *)mandatoryKeys {
return (__bridge_transfer UIFontDescriptor *)CTFontDescriptorCreateMatchingFontDescriptor((__bridge CTFontDescriptorRef)self, (__bridge CFSetRef)mandatoryKeys);
}
I often use Transformable for Core Data attributes, so I can change them later.
However, it seems like, if I want to use NSPredicate to find a NSManagedObject, using "uniqueKey == %#", or "uniqueKey MATCHES[cd] %#", it's not working as it should.
It always misses matching objects, until I change the attributes of the uniqueKey of the matching object to have specific class like NSString, or NSNumber.
Can someone explain the limitation of using NSPredicate with Transformable attributes?
Note: I'm not sure when/if this has changed since 5/2011 (from Scott Ahten's accepted answer), but you can absolutely search with NSPredicate on transformable attributes. Scott correctly explained why your assumptions were broken, but if Can someone explain the limitation of using NSPredicate with Transformable attributes? was your question, he implied that it is not possible, and that is incorrect.
Since the is the first google hit for "Core Data transformable value search nspredicate" (what I searched for trying to find inspiration), I wanted to add my working answer.
How to use NSPredicate with transformable properties
Short, heady answer: you need to be smart about your data transformers. You need to transfrom the value to NSData that contains what I'll call "primitive identifying information", i.e. the smallest, most identifying set of bytes that can be used to reconstruct your object. Long answer, ...
Foremost, consider:
Did you actual mean to use a transformable attribute? If any supported data type -- even binary data -- will suffice, use it.
Do you understand what transformable attributes actually are? How they pack and unpack data to and from the store? Review Non-Standard Persistent Attributes in Apple's documentation.
After reading the above, ask: does custom code that hides a supported type "backing attribute" work for you? Possibly use that technique.
Now, past those considerations, transformable attributes are rather slick. Frankly, writing an NSValueTransformer "FooToData" for Foo instances to NSData seemed cleaner than writing a lot of adhoc custom code. I haven't found a case where Core Data doesn't know it needs to transform the data using the registered NSValueTransformer.
To proceed simply address these concerns:
Did you tell Core Data what transformer to use? Open the Core Data model in table view, click the entity, click the attribute, load the Data Model Inspector pane. Under "Attribute Type: Transformable", set "Name" to your transformer.
Use a default transformer (again, see the previous Apple docs) or write your own transformer -- transformedValue: must return NSData.
NSKeyedUnarchiveFromDataTransformerName is the default transformer and may not suffice, or may draw in somewhat-transient instance data that can make two similar objects be different when they are equal.
The transformed value should contain only -- what I'll call -- "primitive identifying information". The store is going to be comparing bytes, so every byte counts.
You may also register your transformer globally. I have to do this since I actually reuse them elsewhere in the app -- e.g. NSString *name = #"FooTrans"; [NSValueTransformer setValueTransformer:[NSClassFromString(name) new] forName:name];
You probably don't want to use transforms heavily queried data operations - e.g. a large import where the primary key information uses transformers - yikes!
And then in the end, I simply use this to test for equality for high-level object attributes on models with NSPredicates -- e.g. "%K == %#" -- and it works fine. I haven't tried some of the various matching terms, but I wouldn't be surprised if they worked sometimes, and others not.
Here's an example of an NSURL to NSData transformer. Why not just store the string? Yeah, that's fine -- that's a good example of custom code masking the stored attribute. This example illustrates that an extra byte is added to the stringified URL to record if it was a file URL or not -- allowing us to know what constructors to use when the object is unpacked.
// URLToDataTransformer.h - interface
extern NSString *const kURLToDataTransformerName;
#interface URLToDataTransformer : NSValueTransformer
#end
...
// URLToDataTransformer.m - implementation
#import "URLToDataTransformer.h"
NSString *const kURLToDataTransformerName = #"URLToDataTransformer";
#implementation URLToDataTransformer
+ (Class)transformedValueClass { return [NSData class]; }
+ (BOOL)allowsReverseTransformation { return YES; }
- (id)transformedValue:(id)value
{
if (![value isKindOfClass:[NSURL class]])
{
// Log error ...
return nil;
}
NSMutableData *data;
char fileType = 0;
if ([value isFileURL])
{
fileType = 1;
data = [NSMutableData dataWithBytes:&fileType length:1];
[data appendData:[[(NSURL *)value path] dataUsingEncoding:NSUTF8StringEncoding]];
}
else
{
fileType = -1;
data = [NSMutableData dataWithBytes:&fileType length:1];
[data appendData:[[(NSURL *)value absoluteString] dataUsingEncoding:NSUTF8StringEncoding]];
}
return data;
}
- (id)reverseTransformedValue:(id)value
{
if (![value isKindOfClass:[NSData class]])
{
// Log error ...
return nil;
}
NSURL *url = nil;
NSData *data = (NSData *)value;
char fileType = 0;
NSRange range = NSMakeRange(1, [data length]-1);
[data getBytes:&fileType length:1];
if (1 == fileType)
{
NSData *actualData = [data subdataWithRange:range];
NSString *str = [[NSString alloc] initWithData:actualData encoding:NSUTF8StringEncoding];
url = [NSURL fileURLWithPath:str];
}
else if (-1 == fileType)
{
NSData *actualData = [data subdataWithRange:range];
NSString *str = [[NSString alloc] initWithData:actualData encoding:NSUTF8StringEncoding];
url = [NSURL URLWithString:str];
}
else
{
// Log error ...
return nil;
}
return url;
}
#end
Transformable attributes are usually persisted as archived binary data. As such, you are attempting to compare an instance of NSData with an instance of NSString or NSNumber.
Since these classes interpret the same data in different ways, they are not considered a match.
you can try this way
NSExpression *exprPath = [NSExpression expressionForKeyPath:#"transformable_field"];
NSExpression *exprKeyword = [NSExpression expressionForConstantValue:nsdataValue];
NSPredicate *predicate = [NSComparisonPredicate predicateWithLeftExpression:exprPath rightExpression:exprKeyword modifier:NSDirectPredicateModifier type:NSEqualToPredicateOperatorType options:0];
Is there any equivalent method in AppKit (for Cocoa on Mac OS X) that does the same thing as UIKit's [NSString sizeWithFont:constrainedToSize:]?
If not, how could I go about getting the amount of space needed to render a particular string constrained to a width/height?
Update: Below is a snippet of code I'm using that I expect would produce the results I'm after.
NSDictionary *attributes = [NSDictionary dictionaryWithObjectsAndKeys:
[NSFont systemFontOfSize: [NSFont smallSystemFontSize]], NSFontAttributeName,
[NSParagraphStyle defaultParagraphStyle], NSParagraphStyleAttributeName,
nil];
NSSize size = NSMakeSize(200.0, MAXFLOAT);
NSRect bounds;
bounds = [#"This is a really really really really really really really long string that won't fit on one line"
boundingRectWithSize: size
options: NSStringDrawingUsesFontLeading
attributes: attributes];
NSLog(#"height: %02f, width: %02f", bounds.size.height, bounds.size.width);
I would expect that the output width would be 200 and the height would be something greater than the height of a single line, however it produces:
height: 14.000000, width: 466.619141
Thanks!
Try this one:
bounds = [value boundingRectWithSize:size options:NSLineBreakByWordWrapping | NSStringDrawingUsesLineFragmentOrigin attributes:attributes];
The newer NSExtendedStringDrawing category API (methods with the NSStringDrawingOptions argument) behaves in the single line mode. If you want to measure/render in multi line mode, want to specify NSStringDrawingUsesLineFragmentOrigin.
EDIT: You should be able to do things the normal way in Lion and later. The problems described below have been fixed.
There is no way to accurately measure text among the current Mac OS X APIs.
There are several APIs that promise to work but don't. That's one of them; Core Text's function for this purpose is another. Some methods return results that are close but wrong; some return results that seem to mean nothing at all. I haven't filed any bugs on these yet, but when I do, I'll edit the Radar numbers into this answer. You should file a bug as well, and include your code in a small sample project.
[Apparently I have already filed the Core Text one: 8666756. It's closed as a duplicate of an unspecified other bug. For Cocoa, I filed 9022238 about the method Dave suggested, and will file two NSLayoutManager bugs tomorrow.]
This is the closest solution I've found.
If you want to constrain the string to a certain size, you use -[NSString boundingRectWithSize:options:attributes:]. The .size of the returned NSRect is the size you're looking for.
Here is a more complete example of how you can do this using boundingRectWithSize.
// get the text field
NSTextField* field = (NSTextField*)view;
// create the new font for the text field
NSFont* newFont = [NSFont fontWithName:#"Trebuchet MS" size:11.0];
// set the font on the text field
[field setFont:newFont];
// calculate the size the textfield needs to be in order to display the text properly
NSString* text = field.stringValue;
NSInteger maxWidth = field.frame.size.width;
NSInteger maxHeight = 20000;
CGSize constraint = CGSizeMake(maxWidth, maxHeight);
NSDictionary* attrs = [NSDictionary dictionaryWithObjectsAndKeys:NSFontAttributeName,newFont, nil];
NSRect newBounds = [text boundingRectWithSize:constraint
options:NSLineBreakByWordWrapping | NSStringDrawingUsesLineFragmentOrigin
attributes:attrs];
// set the size of the text field to the calculated size
field.frame = NSMakeRect(field.frame.origin.x, field.frame.origin.y, field.frame.size.width, newBounds.size.height);
Of course, for additional info, take a look at the Apple documentation:
Options for the attributes dictionary
boundingRectWithSize
If you search the documentation for NSString, you will find the "NSString Application Kit Additions Reference", which is pretty much analogous to the UIKit counterpart.
-[NSString sizeWithAttributes:]
is the method you are looking for.
I'm trying to create an attributed string with a strikethrough, however, this simple task seems to be harder to figure out than I anticipated. Here is what I have currently (which is not working). Thanks for the help!
NSAttributedString *theTitle = [[[NSAttributedString alloc] initWithString:#"strikethrough text" attributes:[NSDictionary dictionaryWithObjectsAndKeys:[NSColor whiteColor], NSForegroundColorAttributeName, NSUnderlinePatternSolid, NSStrikethroughStyleAttributeName, nil]] autorelease];
First, the value for NSStrikethroughStyleAttributeName must be an NSNumber, not a simple integer. Second, I think you have to include NSUnderlineStyleSingle:
...:[NSDictionary dictionaryWithObjectsAndKeys:
...,
[NSNumber numberWithInteger:NSUnderlinePatternSolid | NSUnderlineStyleSingle],
NSStrikethroughStyleAttributeName,
nil]...
You can also simply use:
NSAttributedString *theAttributedString;
theAttributedString = [[NSAttributedString alloc] initWithString:theString
attributes:#{NSStrikethroughStyleAttributeName:
[NSNumber numberWithInteger:NSUnderlineStyleSingle]}];
Update :
Swift 2.0 version
let theAttributedString = NSAttributedString(string: theString, attributes: [NSStrikethroughColorAttributeName: NSUnderlineStyle.StyleSingle])
func addAttributes(attrs: [String : AnyObject], range: NSRange)
NSUnderlineStyleAttributeName:
The value of this attribute is an NSNumber object containing an integer.
Since the NSUnderlineStyle enum's rawValue is Int Type, you should initialize a NSNumber Object with it
Swift2.1:
attrStr.addAttributes([NSStrikethroughStyleAttributeName: NSNumber(integer: NSUnderlineStyle.StyleSingle.rawValue)], range: NSMakeRange(x, y))
x is the location, the start of your text
y is the length of the text
Swift 4:
NSAttributedString(string: "test string", attributes: [.strikethroughStyle: NSUnderlineStyle.styleSingle.rawValue])
Swift 5:
NSAttributedString(string: "test string", attributes: [.strikethroughStyle: NSUnderlineStyle.single.rawValue])
Mind the fact that .strikethroughStyle and .underlineStyle expect an integer value (specifically an NSNumber), therefore we're using NSUnderlineStyle's .rawValue in the examples.
(Setting NSUnderlineStyle causes unrecogognized selector exception)