In our app we are storing fonts for custom objects as strings containing the font name (as retrieved from the font panel) and instantiate fonts using
+ (NSFont *)fontWithName:(NSString *)fontName
Now when loading or importing files we'd like to check whether the font name will actually resolve on the current system.
Due to certain design restrictions we need to perform the check in plain old C/C++, i.e. these days using CoreText.
However, there doesn't seem to exist an equivalent CoreText API call working similarly to fontWithName::
CTFontCreateWithName always returns a font as it uses a fallback strategy
CTFontCopyFullName appears to use different names than wha is accepted/used by NSFont..?
So basically the question is:
How can we use CoreText functionality to check whether a font exists on the current system and the font can be instantiated successfully using [NSFont fontWithName:] later..?
It appears that CTFontCopyPostScriptName() will always return a valid result for any string that is understood by [NSFont fontWithName:] - and vice versa.
At least in my experiments across 10.8 - 10.10 and using valid and made-up font names the results of CTFontCopyPostScriptName() could always be used to verify a font name will be valid for NSFont.
Edit #1
Some experimentation shows that it's a good idea to also add a fallback with CTFontCopyFamilyName() to be on the safe side.
Related
Is it technically possible to use two different font in the same
DrawHTMLTextBox while using Debenu Quick PDF Library 10?
Is it possible with any other libraries which can be used in a PHP
project (Not preferred)?
Currently it is not possible to use two different fonts in the string that you pass to the DrawHTMLTextBox function in Debenu Quick PDF Library. If you want to use a different font for different parts of the string you'll need to use DrawHTMLText instead and change the font using SetHTMLNormalFont prior to each section of the string being drawn.
Using this method you'll need to keep track of the width and height of the text you're drawing yourself but you can do that using the GetHTMLTextHeight, GetHTMLTextWidth and GetHTMLTextLineCount.
I'm building a QuickLook plugin. I want to change the width of the windows that pops up when user hits the spacebar.
I've read there are two keys in the info.plist file of the project where height and width are customisable. Even if I change those values I can't get the size of the preview windows to my desired one.
I don't know what else to try. Any idea?
Thanks!
Thought I'd dig a little on this. I have not tried any of the following suggestions, so nobody get their hopes up. I'll assume you're using the generator callback:
OSStatus (*GeneratePreviewForURL)(
void *thisInterface,
QLPreviewRequestRef preview,
CFURLRef url,
CFStringRef contentTypeUTI,
CFDictionaryRef options
);
Before anything else, you might manually check the options dictionary argument and verify that the kQLPreviewPropertyWidthKey and kQLPreviewPropertyHeightKey keys are indeed mapped to the desired CFNumber values.
Referring to each of these properties, the Apple QuickLook programming guide says:
Note that this property is a hint; Quick Look might set the width
automatically for some types of previews. The value must be
encapsulated in a CFNumber object.
(Edit: If your preview representation is flexible, you might try finding a preview type for which QuickLook honors your size hints, as per the statement above. Just a thought.)
Running nm on the QuickLook framework binary revealed some undocumented kQLPreviewProperty-- constants as well as the aforementioned width and height keys. One that caught my attention was kQLPreviewPropertyAutoSizeKey. Recalling Apple's statement about ignoring the hints to set the size automatically, this might be significant? Following the convention in QuickLook.framework/Headers/QLBase.h, you might try declaring
extern const CFStringRef kQLPreviewPropertyAutoSizeKey;
Then you could try associating a CFNumber 0 with that property key in the options dictionary. There are other undocumented keys of note, such as kQLPreviewPropertyAttributesKey.
Back to the Info.plist you mentioned, Apple says about those keys QLPreviewWidth and QLPreviewHeight:
This number gives Quick Look a hint for the width (in points) of
previews. It uses these values if the generator takes too long to
produce the preview. (emphasis added)
This is where someone makes the terrible suggestion of calling sleep() in your generator. But I'm perplexed as to why Apple would make following the size hints dependent on the generator latency. (?)
Edit: Also note the above statement says the Info.plist hints must be expressed in points (not pixels), a unit dependent on the user's screen resolution.
Recently I was developing a Quick Look Plugin myself which uses HTML+CSS and faced the same problem.
The solution for my was to test the plugin not within Xcode and qlmanage as the executable but instead to try the real .qlgenerator from my user library.
When invoking the generator from my user library, the Quick Look window was resized exactly the way I specified in the *-Info.plist.
I've run into the same problem, and may offer some clues: In my case I'm generating an image quick look preview for my custom file format. I initiate the preview context to draw my preview into using
CGContextRef QLPreviewRequestCreateContext(QLPreviewRequestRef preview, CGSize size, Boolean isBitmap, CFDictionaryRef properties);
The curious thing is that if I set isBitmap to true, quick look adjusts the preview panel size to the size specified for the context (up to a certain size at least). But if you set isBitmap to false, it seems to disregard the context size and instead always shows a full size preview panel with the vector graphics image scaled to cover the entire panel.
So, if you use a bitmap graphical preview context, it seems the preview panel will be set to the size of the context you specify. However, I haven't found any way to set the size of the panel when using a vector graphic preview context (which is what I want).
Consider the following, I have paragraph data being sent to a view which needs to be placed over a background image, which has at the top and the bottom, fixed elements (fig1)
Fig1.
My thought was to split this into 4 labels (Fig1.example2) my question here is how I can get the text to flow through labels 1 - 4 given that label 1,2 & 3 ar of fixed height. I assumed here that label 3 should be populated prior to 4 hence the layout in the attached diagram.
Can someone suggest the best way of doing this with maybe an example?
Thanks
Wish I could help more, but I think I can at least point you in the right direction.
First, your idea seems very possible, but would involve lots of calculations of text size that would be ugly and might not produce ideal results. The way I see it working is a binary search of testing portions of your string with sizeWithFont: until you can get the best guess for what the label will fit into that size and still look "right". Then you have to actually break up the string and track it in pieces... just seems wrong.
In iOS 6 (unfortunately doesn't apply to you right now but I'll post it as a potential benefit to others), you could probably use one UILabel and an NSAttributed string. There would be a couple of options to go with here, (I haven't done it so I'm not sure which would be the best) but it seems that if you could format the page with html, you can initialize the attributed string that way.
From the docs:
You can create an attributed string from HTML data using the initialization methods initWithHTML:documentAttributes: and initWithHTML:baseURL:documentAttributes:. The methods return text attributes defined by the HTML as the attributes of the string. They return document-level attributes defined by the HTML, such as paper and margin sizes, by reference to an NSDictionary object, as described in “RTF Files and Attributed Strings.” The methods translate HTML as well as possible into structures of the Cocoa text system, but the Application Kit does not provide complete, true rendering of arbitrary HTML.
An alternative here would be to just use the available attributes, setting line indents and such according to the image size. I haven't worked with attributed strings at this level, so I the best reference would be the developer videos and the programming guide for NSAttributedString. https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/AttributedStrings/AttributedStrings.html#//apple_ref/doc/uid/10000036-BBCCGDBG
For lesser versions of iOS, you'd probably be better off becoming familiar with CoreText. In the end you'll be rewarded with a better looking result, reusability/flexibility, the list goes on. For that, I would start with the CoreText programming guide: https://developer.apple.com/library/mac/#documentation/StringsTextFonts/Conceptual/CoreText_Programming/Introduction/Introduction.html
Maybe someone else can provide some sample code, but I think just looking through the docs will give you less of a headache than trying to calculate 4 labels like that.
EDIT:
I changed the link for CoreText
You have to go with CoreText: create your AttributedString and a CTFramesetter with it.
Then you can get a CTFrame for each of your textboxes and draw it in your graphics context.
https://developer.apple.com/library/mac/#documentation/Carbon/Reference/CTFramesetterRef/Reference/reference.html#//apple_ref/doc/uid/TP40005105
You can also use a UIWebView
That we can use a custom font within my app is not a secret, but I can't reach this and wonder why.
Of course I searched the whole web for this problem but nowhere found something similar, so this is why I finally need to ask this.
What I'm trying: I'm on my way to create a small game and draw always my whole gamefield. Good, this works just fine with the default fonts, but doesn't with my custom font...
I added my .ttf-Font (I tried two different) to my project using drag and drop and copy it to my project folder. Next I added MyFontXY.ttf to my Info.plist using UIAppFonts and an array.
Next I tried to use it with [UIFont fontWithName:#"MyFontXY.ttf" size:12] - ok fine, doesn't work. I searched for the real name of the font and tried [UIFont fontWithName:#"My Font XY" size12] but it doesn't work, too.
So I tried several things after this like cleaning, reimport, change the name, ... but nothing happened. I also used NSLog(#"%#",[UIFont fontFamilies]) to find out which fonts are available, but my font wasn't there.
I also checked if the numbers were available with this font and they are, so I excluded a lot of possibilities now.
What can I do now? Does someone has this problem too?
You need to add the fonts to your target, for instance by manually adding them in the "Copy Bundle Resources" phase of your target
Encountering a weird problem here. I'm developing a game for my school project (non-commercial), and I'm using a custom font Black Chancery (free under GNU GPL). I followed the instructions from multiple sources, which includes:
Add the font to the project (TTF).
Modify app-Info.plist to add the font to it ("Fonts provided by application").
Using [UIFont fontWithName:#"BlackChancery" size:30] when the font is needed.
I could get the font displayed in the Simulator, however when I load it into my iPad, the default system font is used. I'm pretty sure there isn't a problem with the font itself as it displays in the simulator, and I've used FontForge to open the font without any warnings (following from This Question).
Any help is greatly appreciated. Thanks! :)
I can only guess as you haven't posted the contents of your plist or a directory listing of the bundle, but many cases of "resource works on the simulator but not on the device" are caused by the fact that the OS X filesystem is normally configured to be case-insensitive while the filesystem on the device is case sensitive. For example, if your file is named "BlackChancery.TTF" and your plist refers to it as "BlackChancery.ttf", it will be found on the simulator but not on the device.
I was having problem with font not recognizing, I fixed it by checking the correct name of the font by checking info of the font file by Get Info option. In my case the file name was written xyzfont.ttf but actually it was XyzFont.TTF in the info, i replaced and it worked.
Hope, it helps someone.
Another Way
I have come across one more way of finding the correct name, is by installing the font in the FontBook..
Just open FontBook from Finder and select User now from File->Add Fonts select the font you want to add into your application, after little processing the FontBook will show the Font listed in with the Correct name, use the name in the FontBook ignoring the actual ttf file name you have imported or, added to plist.. It should work..
I had the same problem which was resolved with a slight variation on iphonc's solution. The case sensitivity was directly related to the file extension. The problem was associated with my font file named: Choc.TTF
I had to remove the reference to the file in xCode 4.1
Rename the file to Choc.ttf (note lower case file extension)
Add the reference back into xCode
Perform a clean and re-build for the device
Conclusion (in my particular case):
Case sensitivity applies not JUST to the file name, but to the file extension as well (i.e. iOS device appears to tolerate only lower case).
My answer is different from all the rest. I had a problem because the font was all one word and lowercase "compassnormal.ttf" and the name in the file was Compass. So, my code was:
[UIFont fontWithName:#"Compass" size:24]]
Bundle Resource said:
compassnormal.ttf
~info.plist said:
compassnormal.ttf
None of this worked until I changed the actual filename to match it's official name in fontbook.
deleted all references from Bundle Resources and ~info.plist;
added font with updated name to Bundle Resources;
updated plist with new name;
tested in simulator and on device, Voila!
I have also experienced a problem with fonts containing the dash (-) character. Remove that character from your font names and try with that.
So your font named Gotham-Black.ttf should be named GothamBlack.ttf
Also check that your fonts are not zero bytes. I had this same issue and it turned out that my font files had emptied themselves at some stage. Probably when rearranging them in XCode and AppCode.
You have to use the real font name in the [UIFont fontWithName:#"... method! Not the ttf filename!!!
This real name is mostly far away from the filename. Just open the rtf in the Mac font utility. In the header you see the font family!!! Only the family!!! if you now use
NSArray *fontNames = [UIFont fontNamesForFamilyName:#"MyFontNameFamily"];
NSLog(#"%#", fontNames);
in your code, you get the real real real name in the console ;-)
But in the plist entry you still need the (case sensitive) filename!!!
I have the same issue on Xcode 6. My file name was My Font.ttf, it doesn't work. I manage to make it works when I rename it to My Font.TTF, just change the file extension to uppercase.