Auto-generated icon font library for iOS, watchOS and tvOS

I created a font using fontastic.me, installed with the .ttf file and all the SwiftGen generated Icon file has is import UIKit and a comment that says 'No Icon found'. I've tried it using FontAwesome's .ttf file and it works properly. Is there something I'm missing when creating the font or installing the pod?

Hey dzenbot! I am currently working on second project where I want to use Iconic, but we have a small issue. As Pods (in our experience) increase build time, we decided to move to Carthage instead. Here comes the problem, Iconic is only available through Pods and it does not seems right to use Pods together with Carthage. We also use SwiftGen on this project and it has this nice command line interface so it can be used in build phase run script.

Is there any plan to implement CLI and then distribute Iconic with brew? Would be killer feature for us :-)

Hey. Cool project.

Everything was working great for about 2 weeks, then I started getting this error:

Error Domain=com.apple.CoreText.CTFontManagerErrorDomain Code=105 "Could not register the font file(s)"

So, I checked out error code 105 -> kCTFontManagerErrorAlreadyRegistered

I looked through Iconic's source and it doesn't look like the "already registered" case was handled, so I thought I'd just handle it myself in the app delegate by unregistering the font first:

let bundle = NSBundle(forClass: Iconic.self)
if let url = bundle.URLForResource("Linearicons", withExtension: "ttf"){
       var error: Unmanaged<CFErrorRef>? = nil
       CTFontManagerUnregisterFontsForURL(url, .None, &error)
       Iconic.registerIconFont()
}

However, the call to CTFontManagerUnregisterFontsForURL also returns an error:

Error Domain=com.apple.CoreText.CTFontManagerErrorDomain Code=201 "Could not unregister the font file(s)"

So, I checkout out error code 201 -> kCTFontManagerErrorNotRegistered

Not registered... o.O

Have you run into this before - not being able to register nor unregister a font? Tried cleaning, deleting my derived data, deleting the simulator's data, and double checked the font urls, but no luck.

Could Iconic try to continue its initialization in the case when the error is 105 - already registered?

Any suggestions appreciated.

Thanks!

@dzenbot mind adding me as a co-owner of the CocoaPod so I can push new versions? Should just need to run pod trunk add-owner Iconic [email protected] to get it done. You will remain an owner. Thanks

Hey, I know this library is in beta but I still want to use it. It seems that every time I need to update my pod file I have to point out the location for my font file, which then takes some time until it regenerate the Icon class, more than that if I'm doing plain pod update it installs Iconic with the default Icon class and removes mine..

Is there a better workflow for this?

looks like we can only generate one font at a time because the source directory is override everytime. Wondering if the iconizer.sh can take a font directory (FONT_DIR) environment variable, in addition to the FONT_PATH, to generate for all the *.ttf files found in the directory?

I get this error when trying to compile my app to my device.

"/Users/johnrehbein/Library/Developer/Xcode/DerivedData/FlipBook-dvfxorfebyxoypbxslfercvccsye/Build/Products/Debug-iphoneos/Iconic/Iconic.framework/Iconic' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64"

I'm not really sure how to rebuild this framework, so an update would be nice. For now I've just disabled bitcode in my app.

addressing #23, #24, #2 and maybe #13 (although haven’t thoroughly tested yet).

outline changes:

1. Updated Iconizer.sh and the stencil files in order to generate multiple fonts without name collision and support the refactoring below.
2. refactor the Iconic.swift and stencils to generate more swifty code that better align with swift3 API guideline: guideline: 2.1. move most of the logic from Iconic.swift to the new protocol "IconFont" 2.2. Iconic class is now a placeholder to house the generated wrapper functions for objective-c compatibility (since they can't access enum extension and protocol). 2.3 the UI extensions become just thin wrappers around the powerful swift enum mainly for objective-c access. (note: Samples/Pods/Iconic/Source/FontAwesomeIcon.swift is generated from the new stencil/Iconizer.sh)
3. chnage catalog location and hierarchy in code generation to accomendate multi-font.
4. Changed Sample swift controllers to use the new style API.
5. Adjust unit tests accordingly; I did disable the UI extension tests since they are now nothing more than generated wrappers on the enum class that have already been tested in other 2 unit tests. The UI extensions are also exercised in both swift and objective-c controllers in the Sample project and they worked fine.

Resolves #87 Added a default case handler, and because the return type is not optional and we cannot throw inside a computed var it just does fatalError() with a message of where. Assuming we never had this before and it IS exhaustive, the compiler just doesn't know it - it won't be an issue.

Bumped swift to 5.0 without any other changes to remove compiler warning. Perhaps @robbiet480 is suitable reviewer?

Edit: This has been tested with a clean branch install and generates without issue or compiler warning in Xcode 11.3 and cocoa pods 1.8.4

Hello guys,

If I want to use UIImageView properties with UIImage coming from iconic font, for example how can I set UIImageView mode to Aspect Fit and get the size of the font adjust with the size of the imageView ?

Thanks best regards

The compiler fails to check how exhaustive some switches are with the warning "The compiler is unable to check that this switch is exhaustive in reasonable time".

The easiest solution is to add a default to these switch statements, to trick the compiler.

Fix https://github.com/home-assistant/Iconic/issues/87