Re: Vertically Centered Colon

[Gerriet M. Denkmann]

> On 29 Nov 2016, at 03:33, Doug Hill  wrote:
> 
> A couple of things to note:
> 
[…]
> In any case it's a bad idea to select the exact font since you have to choose 
> SF Display or Text which you don't want to do. It should be dynamically 
> selected at runtime based on the font size. This behavior is supported by 
> using System Font.
> 
> Anyways, I would check the font at runtime to make sure it’s SF.

thinFont =   font-family: “.SFUIDisplay-Ultralight"; font-weight: 
normal; font-style: normal; font-size: 70.00pt

> Otherwise, you need a font that supports the Vertically Centered Colon font 
> feature. You can check this feature by doing the following:
> • Select your desired font on your Mac for the attributed string in the font 
> panel
> • Click the Gear icon in the upper-left corner.
> • Select Typography…
> • Select 'Alternative Stylistic Sets'
> • Select ‘Vertically Centered Colon'

Well, this is kind of difficult: the Font Panel does not show fonts which have 
names which start with ‘.’.
So: no SF fonts in my Font Panel.



> Furthermore, I don’t see a way to set these  'Alternative Stylistic' 
> attributes from UIAttributedText.

Can be done like this:

NSDictionary *featureCenteredColon = @{ UIFontFeatureTypeIdentifierKey: 
@(kStylisticAlternativesType), 

UIFontFeatureSelectorIdentifierKey: @(kStylisticAltThreeOnSelector)
  };
NSArray *featureArray = @[ featureCenteredColon ];
NSDictionary *featureAtribute = @{ UIFontDescriptorFeatureSettingsAttribute: 
featureArray };

UIFontDescriptor *thinDescriptor = thinFont.fontDescriptor;
UIFontDescriptor *newDescr = [ thinDescriptor fontDescriptorByAddingAttributes: 
featureAtribute ];
UIFont *betterThinFont = [ UIFont fontWithDescriptor: newDescr  size: pointSize 
];



> A little experimentation might find the right one.

A “little” is kind of misleading. There are about 40 features, with up to 20 
alternatives each.


> OK, after doing some tests, UILabel indeed behaves like you mentioned with 
> the SF font. If there aren't numbers on either side of the colon, no vertical 
> centering. My guess would see if you can attempt to set the 
> kStylisticAlternativesType attribute, as noted below, but as previously 
> mentioned, will probably not work automatically due to the different fonts 
> for the numerals around the colon.
> 
> At this point, I’d say your working solution is probably as good as you're 
> going to get.

After you kindly mentioned kStylisticAlternativesType I started to try this. 
The documentation is quite helpful in mentioning that some flag “Turns the nth 
set of alternates on or off” for n = 1 … 20.

And luckily kStylisticAltThreeOnSelector does indeed turn centred colons on.

So now I have two working solutions: 
1. getting the special glyph for the centered colon (as suggested by Alistair) 
and:
2. using kStylisticAltThreeOnSelector (as suggested by you).

Thanks a lot. The hint of “kStylisticAlternativesType” was extremely helpful!

Kind regards,

Gerriet.


> 
> 
>> On Nov 28, 2016, at 11:12 AM, Gerriet M. Denkmann  
>> wrote:
>> 
>> 
>>> On 28 Nov 2016, at 23:42, Alastair Houghton  
>>> wrote:
>>> 
>>> On 28 Nov 2016, at 16:18, Gerriet M. Denkmann  wrote:
 
 
> On 28 Nov 2016, at 22:13, Eric E. Dolecki  wrote:
> 
> You could probably use an attributed string and add an attribute for the 
> last colon: NSBaselineOffsetAttributeName
 
 Yes; but this would be some rather desperate work-around.
 
 I was rather thinking of UIFontDescriptorFeatureSettingsAttribute with 
 some Feature type from SFNTLayoutTypes.h (in CoreText).
 I tried a few types, but no success so far.
>>> 
>>> The problem you’ve got is that unless the font has a feature that 
>>> specifically allows you to change *any* colon (as opposed to a colon 
>>> between two numerals), you aren’t going to be able to do it by turning on 
>>> an OpenType feature.  Even if you can, there doesn’t appear to be a 
>>> standard feature code for this, so you’d be reliant on Apple not changing 
>>> it in the future.
>> 
>> The WWDC 2015 talk seemed to suggest that there is a standard feature for 
>> this.
>> But there are about 40 feature types in SFNTLayoutTypes.h - no idea what to 
>> use.
>> 
>> 
>>> What you *could* do instead is get Core Text (or Cocoa Text) to lay out a 
>>> string e.g. “12:00”, then grab the glyph for the centred colon directly 
>>> from that string and use it explicitly, e.g. by attaching a 
>>> kCTGlyphInfoAttributeName attribute to your string with the value set to an 
>>> appropriately constructed CTGlyphInfoRef.
>> 
>> done once:
>> 
>> CGRect frame = { {0,0},{99,99}}; 
>> UITextView *dummyTextView = [ [UITextView alloc] initWithFrame: frame 
>> textContainer: nil ];
>> dummyTextView.text = @“23:21”;
>> dummyTextView.font = thinFont;
>> NS

Re: Vertically Centered Colon

[Gerriet M. Denkmann]

> On 29 Nov 2016, at 00:40, Quincey Morris 
>  wrote:
> 
> On Nov 28, 2016, at 07:01 , Gerriet M. Denkmann  wrote:
>> 
>> But in my case I have “21:37:44” where ““21:37” is bold and “:44” is thin.
> 
> 
> c.  Given that you work so much with non-Latin scripts, I find it surprising 
> that you would make assumptions about how a time is represented. (Again, of 
> course, you may have decided this is the correct approach for your scenario, 
> but it strikes me as worth commenting on.)

I just checked all 739 locales available in iOS. The time format is pretty 
consistent:
“H.mm.ss"
"H:mm.ss”
“HH.mm.ss"
“H:mm:ss"
“HH:mm:ss” (more than 89% use this)

all should be displayed correctly.
Those locales which use ‘:’ will see a nice vertically centered colon, those 
with ‘.’ a non-centered FULL STOP.

Thanks to alerting me to this issue (my old code assumed two digit hours, which 
would not have worked in about 55 locales).

Kind regards,

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to detect rotation in progress in viewDidLayoutSubview

[Andreas Falkenhahn]

On 28.11.2016 at 16:50 David Duncan wrote:

> I think you can do everything you need to do in layoutSubviews
> (fundamentally it doesn’t matter if the device rotates or not, you
> just want to keep the view centered in its superview).

Right, makes sense.

> In general you should do as much as possible in layoutSubviews type
> methods. However sometimes you really do want to do something
> temporary specifically due to a transition between sizes,
> orientations, or size classes, and hence why we provide the
> “willTransitionTo” methods. If it isn’t a temporary change, then you
> don’t want the transition methods, as they are not always called at
> points when layoutSubviews will be.

Ok, I've now ditched "willTransitionTo" completely and everything is
done in my UIView's layoutSubviews method now. Seems to work fine.

Just one last thing: the documentation of layoutSubviews mentions
that this method, as its name implies, is meant to make adjustments
to subviews. But my UIView doesn't have any subviews at all. So
currently I'm basically (ab?)using layoutSubviews to make adjustments
to the UIView itself, not to its subviews, since there are none.
Is that allowed?

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to detect rotation in progress in viewDidLayoutSubview

[David Duncan]

> On Nov 29, 2016, at 11:30 AM, Andreas Falkenhahn  
> wrote:
> 
> On 28.11.2016 at 16:50 David Duncan wrote:
> 
>> I think you can do everything you need to do in layoutSubviews
>> (fundamentally it doesn’t matter if the device rotates or not, you
>> just want to keep the view centered in its superview).
> 
> Right, makes sense.
> 
>> In general you should do as much as possible in layoutSubviews type
>> methods. However sometimes you really do want to do something
>> temporary specifically due to a transition between sizes,
>> orientations, or size classes, and hence why we provide the
>> “willTransitionTo” methods. If it isn’t a temporary change, then you
>> don’t want the transition methods, as they are not always called at
>> points when layoutSubviews will be.
> 
> Ok, I've now ditched "willTransitionTo" completely and everything is
> done in my UIView's layoutSubviews method now. Seems to work fine.
> 
> Just one last thing: the documentation of layoutSubviews mentions
> that this method, as its name implies, is meant to make adjustments
> to subviews. But my UIView doesn't have any subviews at all. So
> currently I'm basically (ab?)using layoutSubviews to make adjustments
> to the UIView itself, not to its subviews, since there are none.
> Is that allowed?

It is generally bad form to modify a view’s own geometry inside of 
layoutSubviews (frame, bounds, center, transform, and a few related layer 
properties), and more generally not outside of initialization time. Also keep 
in mind that when I mentioned layoutSubviews above, I also mean the 
UIViewController methods viewWillLayoutSubviews and viewDidLayoutSubviews – and 
in that case the ‘self’ that you shouldn’t modify is self.view.

That said, I imagined your view hierarchy was Window => ViewController.View => 
ContentView, at which point ViewController modifying ContentView inside of 
viewWillLayoutSubviews (for example) is fully kosher.

> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.com
> 

--
David Duncan


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Vertically Centered Colon

[Doug Hill]

> On Nov 29, 2016, at 1:33 AM, Gerriet M. Denkmann  wrote:
> 
>> On 29 Nov 2016, at 03:33, Doug Hill  wrote:
>> 
>> A little experimentation might find the right one.

> 
> A “little” is kind of misleading. There are about 40 features, with up to 20 
> alternatives each.
> 
> …
> After you kindly mentioned kStylisticAlternativesType I started to try this. 
> The documentation is quite helpful in mentioning that some flag “Turns the 
> nth set of alternates on or off” for n = 1 … 20.
> 
> And luckily kStylisticAltThreeOnSelector does indeed turn centred colons on.

Wow, it's awesome that this works! And now that I know how to set these 
attributes for a UILabel, I might try using some other features of SF font, 
such as contextual fractional forms for any fraction.

But seriously, why didn’t Apple document what those stylistic alernative type 
attribute constants are? Are they supposed to change? Did they not know what 
they correspond to when creating the header? Did they not expect that 
developers would use this feature?
I suppose if I have some time I’ll try them out and see if I can do my own 
documentation. For reference, here are a few different forms that I was able to 
create with TextEdit:

http://breaqz.com/font/AlternateStylisticForms.pdf

This includes examples of the following:

• Vertically centered colon
• Straight-sided six and nine
• Open Four
• One storev a (e.g. alternate lowercase ‘a’ form)
• Small Capitals
• Contextual Fractional Forms (fractional form for any fraction)
• Monospaced Numbers

Doug Hill


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Vertically Centered Colon

[Quincey Morris]

On Nov 29, 2016, at 09:38 , Doug Hill  wrote:
> 
> But seriously, why didn’t Apple document what those stylistic alernative type 
> attribute constants are? Are they supposed to change? Did they not know what 
> they correspond to when creating the header? Did they not expect that 
> developers would use this feature?

My guess is because there aren’t any definitions, but these are instead 
optional font-specific features with generic identifications. And, lo and 
behold, when I went to check on this:


en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features
 


there they are [well, I presume this is them] under the heading “Ligation and 
alternate forms features intended for all scripts” as “Stylistic Set 1 – 20”. 
Indeed, if you look at the example of Stylistic Set 04 here:

ilovetypography.com/OpenType/opentype-features.html

it even looks like the meaning of the set is somehow defined within the font.

(Note that there appear to be “stylistic alternates”, and “stylistic sets” 
which are a specific kind of stylistic alternate, so the whole system seems 
more complicated than I was able to grasp in 5 minutes of searching.)

I’m ready to stand corrected, but — unless there’s a separate registry or 
convention on what the sets mean — this appears to me to indicate that the 
centered colon may only work for SF and perhaps a set of other Apple-tweaked 
fonts that are intended to have the same behavior.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Vertically Centered Colon

[Doug Hill]

> On Nov 29, 2016, at 10:04 AM, Quincey Morris 
>  wrote:
> 
> On Nov 29, 2016, at 09:38 , Doug Hill  > wrote:
>> 
>> But seriously, why didn’t Apple document what those stylistic alernative 
>> type attribute constants are? Are they supposed to change? Did they not know 
>> what they correspond to when creating the header? Did they not expect that 
>> developers would use this feature?
> 
> My guess is because there aren’t any definitions, but these are instead 
> optional font-specific features with generic identifications. And, lo and 
> behold, when I went to check on this:
> 
>   
> en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features
>  
> 
> 
> there they are [well, I presume this is them] under the heading “Ligation and 
> alternate forms features intended for all scripts” as “Stylistic Set 1 – 20”. 
> Indeed, if you look at the example of Stylistic Set 04 here:
> 
>   ilovetypography.com/OpenType/opentype-features.html 
> 
> 
> it even looks like the meaning of the set is somehow defined within the font.
> 
> (Note that there appear to be “stylistic alternates”, and “stylistic sets” 
> which are a specific kind of stylistic alternate, so the whole system seems 
> more complicated than I was able to grasp in 5 minutes of searching.)
> 
> I’m ready to stand corrected, but — unless there’s a separate registry or 
> convention on what the sets mean — this appears to me to indicate that the 
> centered colon may only work for SF and perhaps a set of other Apple-tweaked 
> fonts that are intended to have the same behavior.

Indeed many of these features are likely SF font specific. However, these 
features are known to Apple’s developers. For example, check out the Typography 
settings of a font in the Macintosh Font Panel. It knows which features are 
available for any font and shows their name when switching fonts. So the 
mapping between OpenType setting and SF font feature is known somewhere, but 
not to SDK users.

But thanks for the links, very good info which I don’t understand all of it 
either. You can go down this font rat-hole as far as you want; I don’t think it 
ever ends. :)

Doug
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to detect rotation in progress in viewDidLayoutSubview

[Andreas Falkenhahn]

On 29.11.2016 at 17:35 David Duncan wrote:


>> On Nov 29, 2016, at 11:30 AM, Andreas Falkenhahn  
>> wrote:

>> On 28.11.2016 at 16:50 David Duncan wrote:

>>> I think you can do everything you need to do in layoutSubviews
>>> (fundamentally it doesn’t matter if the device rotates or not, you
>>> just want to keep the view centered in its superview).

>> Right, makes sense.

>>> In general you should do as much as possible in layoutSubviews type
>>> methods. However sometimes you really do want to do something
>>> temporary specifically due to a transition between sizes,
>>> orientations, or size classes, and hence why we provide the
>>> “willTransitionTo” methods. If it isn’t a temporary change, then you
>>> don’t want the transition methods, as they are not always called at
>>> points when layoutSubviews will be.

>> Ok, I've now ditched "willTransitionTo" completely and everything is
>> done in my UIView's layoutSubviews method now. Seems to work fine.

>> Just one last thing: the documentation of layoutSubviews mentions
>> that this method, as its name implies, is meant to make adjustments
>> to subviews. But my UIView doesn't have any subviews at all. So
>> currently I'm basically (ab?)using layoutSubviews to make adjustments
>> to the UIView itself, not to its subviews, since there are none.
>> Is that allowed?

> It is generally bad form to modify a view’s own geometry inside of
> layoutSubviews (frame, bounds, center, transform, and a few related
> layer properties), and more generally not outside of initialization
> time. Also keep in mind that when I mentioned layoutSubviews above,
> I also mean the UIViewController methods viewWillLayoutSubviews and
> viewDidLayoutSubviews – and in that case the ‘self’ that you shouldn’t modify 
> is self.view.

> That said, I imagined your view hierarchy was Window =>
> ViewController.View => ContentView, at which point ViewController
> modifying ContentView inside of viewWillLayoutSubviews (for example) is fully 
> kosher.

It is actually just Window => ViewController.View. I really only have
a single UIView initialized by my UIViewController in loadView() and
that's it.

So it's forbidden to move this view in the UIViewController's 
viewDidLayoutSubviews()
because it is the root view and not a subview? But how should I do it then?

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to detect rotation in progress in viewDidLayoutSubview

[David Duncan]

> On Nov 29, 2016, at 2:50 PM, Andreas Falkenhahn  
> wrote:
> 
> On 29.11.2016 at 17:35 David Duncan wrote:
> 
> 
>>> On Nov 29, 2016, at 11:30 AM, Andreas Falkenhahn  
>>> wrote:
> 
>>> On 28.11.2016 at 16:50 David Duncan wrote:
> 
 I think you can do everything you need to do in layoutSubviews
 (fundamentally it doesn’t matter if the device rotates or not, you
 just want to keep the view centered in its superview).
> 
>>> Right, makes sense.
> 
 In general you should do as much as possible in layoutSubviews type
 methods. However sometimes you really do want to do something
 temporary specifically due to a transition between sizes,
 orientations, or size classes, and hence why we provide the
 “willTransitionTo” methods. If it isn’t a temporary change, then you
 don’t want the transition methods, as they are not always called at
 points when layoutSubviews will be.
> 
>>> Ok, I've now ditched "willTransitionTo" completely and everything is
>>> done in my UIView's layoutSubviews method now. Seems to work fine.
> 
>>> Just one last thing: the documentation of layoutSubviews mentions
>>> that this method, as its name implies, is meant to make adjustments
>>> to subviews. But my UIView doesn't have any subviews at all. So
>>> currently I'm basically (ab?)using layoutSubviews to make adjustments
>>> to the UIView itself, not to its subviews, since there are none.
>>> Is that allowed?
> 
>> It is generally bad form to modify a view’s own geometry inside of
>> layoutSubviews (frame, bounds, center, transform, and a few related
>> layer properties), and more generally not outside of initialization
>> time. Also keep in mind that when I mentioned layoutSubviews above,
>> I also mean the UIViewController methods viewWillLayoutSubviews and
>> viewDidLayoutSubviews – and in that case the ‘self’ that you shouldn’t 
>> modify is self.view.
> 
>> That said, I imagined your view hierarchy was Window =>
>> ViewController.View => ContentView, at which point ViewController
>> modifying ContentView inside of viewWillLayoutSubviews (for example) is 
>> fully kosher.
> 
> It is actually just Window => ViewController.View. I really only have
> a single UIView initialized by my UIViewController in loadView() and
> that's it.
> 
> So it's forbidden to move this view in the UIViewController's 
> viewDidLayoutSubviews()
> because it is the root view and not a subview? But how should I do it then?

Correct, because the owning UIWindow owns the frame of the view controller’s 
view, and may change it at any time.

The simplest way to fix your specific issue is to just set the contentMode to 
AspectFit. This will automatically center and scale the content for the current 
orientation to fit within the given bounds.

> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.com 
> 
--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Vertically Centered Colon

[Rick Mann]

> On Nov 29, 2016, at 09:38 , Doug Hill  wrote:
> 
> Wow, it's awesome that this works! And now that I know how to set these 
> attributes for a UILabel, I might try using some other features of SF font, 
> such as contextual fractional forms for any fraction.

Oh, wow, contextual fractional forms! This is *perfect* for the app I'm working 
on currently.

I'm late to this thread. Does this stuff only work for attributed strings? Do I 
apply the alternate form attribute to the string "99/100" in order to get the 
fractional form?

Thanks!


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Vertically Centered Colon

[Gerriet M. Denkmann]

> On 30 Nov 2016, at 09:18, Doug Hill  wrote:
> 
> 
>> On Nov 29, 2016, at 3:58 PM, Rick Mann  wrote:
>> 
>> 
>>> On Nov 29, 2016, at 09:38 , Doug Hill  wrote:
>>> 
>>> Wow, it's awesome that this works! And now that I know how to set these 
>>> attributes for a UILabel, I might try using some other features of SF font, 
>>> such as contextual fractional forms for any fraction.
>> 
>> Oh, wow, contextual fractional forms! This is *perfect* for the app I'm 
>> working on currently.
>> 
>> I'm late to this thread. Does this stuff only work for attributed strings?
> 
> I believe you can use [UIFont fontWithDescriptor:size] with a non-attributed 
> string but if you want to mix font styles in a single string, then you need 
> attributed.

I just tried:

someLabel.font = fontVariationWithCenteredColons;
someLabel.text = @“abc:xyz”;

and it works.

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Vertically Centered Colon

[Doug Hill]

> On Nov 29, 2016, at 3:58 PM, Rick Mann  wrote:
> 
> 
>> On Nov 29, 2016, at 09:38 , Doug Hill  wrote:
>> 
>> Wow, it's awesome that this works! And now that I know how to set these 
>> attributes for a UILabel, I might try using some other features of SF font, 
>> such as contextual fractional forms for any fraction.
> 
> Oh, wow, contextual fractional forms! This is *perfect* for the app I'm 
> working on currently.
> 
> I'm late to this thread. Does this stuff only work for attributed strings?

I believe you can use [UIFont fontWithDescriptor:size] with a non-attributed 
string but if you want to mix font styles in a single string, then you need 
attributed.

> Do I apply the alternate form attribute to the string "99/100" in order to 
> get the fractional form?

It would appear that you need to apply this style to a character sequence of: a 
multi-digit number followed by a ‘/‘ then another multi-digit number.

Good luck!

Doug
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Vertically Centered Colon

[Doug Hill]

After some trial and error, I figured out how to accomplish the San Francisco 
font features described below. I updated my document to include the code to 
turn on each feature.

http://breaqz.com/font/AlternateStylisticForms.pdf

 I should make a sample app or blog post but time doesn’t permit at the moment. 
Hope this all helps!

Doug Hill


> On Nov 29, 2016, at 9:38 AM, Doug Hill  wrote:
> 
> I suppose if I have some time I’ll try them out and see if I can do my own 
> documentation. For reference, here are a few different forms that I was able 
> to create with TextEdit:
> 
> http://breaqz.com/font/AlternateStylisticForms.pdf
> 
> This includes examples of the following:
> 
> • Vertically centered colon
> • Straight-sided six and nine
> • Open Four
> • One storev a (e.g. alternate lowercase ‘a’ form)
> • Small Capitals
> • Contextual Fractional Forms (fractional form for any fraction)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Vertically Centered Colon

[Alex Zavatone]

On Nov 30, 2016, at 12:10 AM, Doug Hill wrote:

> After some trial and error, I figured out how to accomplish the San Francisco 
> font features described below. I updated my document to include the code to 
> turn on each feature.
> 
> http://breaqz.com/font/AlternateStylisticForms.pdf
> 
> I should make a sample app or blog post but time doesn’t permit at the 
> moment. Hope this all helps!
> 
> Doug Hill

This doc might help
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM09/AppendixF.html

> 
> 
>> On Nov 29, 2016, at 9:38 AM, Doug Hill  wrote:
>> 
>> I suppose if I have some time I’ll try them out and see if I can do my own 
>> documentation. For reference, here are a few different forms that I was able 
>> to create with TextEdit:
>> 
>> http://breaqz.com/font/AlternateStylisticForms.pdf
>> 
>> This includes examples of the following:
>> 
>> • Vertically centered colon
>> • Straight-sided six and nine
>> • Open Four
>> • One storev a (e.g. alternate lowercase ‘a’ form)
>> • Small Capitals
>> • Contextual Fractional Forms (fractional form for any fraction)
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com