alexdenisov / fontasticicons Goto Github PK

Update fontawesome to v 3.2.0. Currently 3.1.0 is used. The new version has new icons in it.

This is probably a matter of taste, but I've been using a fork of my own lately that uses correct Font Awesome names for each of the FIFontAwesomeIcon methods, from the Font Awesome website (makes it much easier to find icons to use). Is this something you're interested in merging into master? (Keep in mind, I've not done anything about the 3.0 stuff.)

If so, I'll submit a pull request after I add in backwards-compatibility methods that won't break others' API. What do you think?

• Separate each font with subspec to avoid including all fonts
• Break sample into separate xcodeproj/podfile

@kreeger identified misnamed glyphs in Font Awesome (cf #13) as did @beholdr (cf #11) for Iconic. Entypo may also. All currently non-testable 😾

• JSON/CSS is linked in strings files (maybe font maintainers could publish something better)
• I assume Ruby for generation scripts

I know you've got this line of code that should take this into consideration, but as of the latest pull request that was merged, I'm seeing fuzziness on retina devices for icons. Any idea what's up?

I don't quite understand a lot of CoreText stuff yet, but is it possible something's up in FIIconLayer+FIRenderer.m, like in -setTransformForContext:bounds:iconBounds:, or perhaps -scaleForBounds:iconBounds:?

Hi, I have a weird issue. I have 2 targets for a client (free, pro -- yes, antiquated but whatever).

I am using FontasticIcons in both targets via CocoaPods.

It works great for the one target but I'm seeing a different icon in the other target!

I have no idea why and haven't had time to dive into your code yet. I am wondering if you knew off the top of your head what's up.

Here are the images

http://imgur.com/moIN4,k5kkt#0

http://imgur.com/moIN4,k5kkt#1

I am using 0.1.0 BTW

What do you guys think? I know 3 popular alternatives:

1. OCUnit (default underlying others)
2. Kiwi (most popular for BDD see also Cedar)
3. Specta (@github supports it and I personally use their ReactiveCocoa, Mantle, and libextobjc projects extensively)
4. Etcetra

I also left a TODO in my upcoming patch. Thoughts?

Drawing stroke if needed:

icon.borderWidth = 3.f;
icon.borderColor = [UIColor redColor];

Paving the way for #20: Font Awesome has since released 3.0; Entypo Social was merged into Entypo; Iconic added a stroked variant (which can be approximated by applying a negative strokeWidthRatio to any FIIconRendering conforming class cf #16). All fonts also feature subtler updates.

• Version fonts using git submodules (CocoaPods/CocoaPods#442)
• Add and deprecate changes

In "FIFont+Private.h" class. Following method is crashing:

+ (instancetype)fontWithResourcePath:(NSString *)aPath {
    static dispatch_once_t once[1];
    dispatch_once(once, ^{ fonts = [NSMutableDictionary dictionary]; });
    aPath = [self pathForResource:aPath];
    if (!fonts[aPath]) @synchronized (fonts) {
        fonts[aPath] = [[self alloc] initWithFontData:[NSData dataWithContentsOfFile:aPath]];
    }
    return fonts[aPath];
}

The crash is because [self pathForResource:aPath]; is returning nil.

At least two icons in Iconic font are confused between each other: xIcon and xAltIcon shows check instead of cross, and checkIcon and checkAltIcon shows cross instead of check.

The sample renders Font Awesome noticeably slow because its controller doesn't defer rendering.

• Either table view with N icons per row or iOS 6-only collection view or GMGridView
• Refactor into storyboard
• Magnify icon on tap
• Zoom and rotate fullscreen icon
• Control/gesture to scale stroke
• Fuzzy search header in icon list

@interface FIFontAwesomeIcon (Forwarding)

• (instancetype)glass;
• (instancetype)music;
• (instancetype)search;
• (instancetype)envelope;

Should they be '+' instead of '-' ?

Struggling with simply setting icons to buttons I wondered whether it'd be more accessible implementing rasterization subclassing CALayer that could be composed into any UIView?

The README has gotten a little stale. For instance I think the most common FI use case would be like button.image = icon.imageWithBounds:bounds color:color; whereas power users should prefer layers instead of views. How should docs be surfaced? It could all go in README but that might discourage contribution or thorough explanations. Jekyll Pages are great for promotion but inconvenient to maintain because they require web design and development. Gollum wikis are my preference. Brainstorming topics:

Usage

• AppleDoc for headers depended by FontasticIcons.h (like FIIcon.h)
• Changelog (preferably before this milestone)
• Update screenshots and clean up sample (using storyboard?) #23
• Basic usage (like -imageWithBounds:color:)
• Advanced usage (like rendering icons with layer effects)
• Design (what conceptually are fonts, icons, and renderers)

Contribution

• Bleeding edge access (use pod 'FontasticIcons', :branch => 'development')
• Adding and contributing icon sets (currently in flux)
• Feature branches named after issues like osx-support-18
• PRs target development and must stabilize a few days before merged
• Deprecation formalized in categories