Vertically Centered Colon

[Gerriet M. Denkmann]

iOS 10.1.1

WWDC 2015,Session 804: Introducing the New System Fonts tells (at about 23:23) 
about Vertically Centered Colons.
But I do not understand, how to turn this on.

It works automatically (in SF) with colons surrounded by digits.

But in my case I have “21:37:44” where ““21:37” is bold and “:44” is thin. And 
the ‘:’ in front of “44” is not surrounded by digits. So I want to turn this 
feature on explicitly.

How to do this?

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

[Eric E. Dolecki]

You could probably use an attributed string and add an attribute for the
last colon: NSBaselineOffsetAttributeName

On Mon, Nov 28, 2016 at 10:02 AM Gerriet M. Denkmann 
wrote:

> iOS 10.1.1
>
> WWDC 2015,Session 804: Introducing the New System Fonts tells (at about
> 23:23) about Vertically Centered Colons.
> But I do not understand, how to turn this on.
>
> It works automatically (in SF) with colons surrounded by digits.
>
> But in my case I have “21:37:44” where ““21:37” is bold and “:44” is thin.
> And the ‘:’ in front of “44” is not surrounded by digits. So I want to turn
> this feature on explicitly.
>
> How to do this?
>
> 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/edolecki%40gmail.com
>
> This email sent to edole...@gmail.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

How to convert from decomposed to precomposed UTF-8 on iOS

[Andreas Falkenhahn]

(I'm sorry, but this mail isn't really about Cocoa but I've checked all
the lists hosted on lists.apple.com and I haven't found a list which
is suitable so I'll try here.)

I need to convert a char array that contains decomposed UTF-8 characters
(as used by HFS) into a precomposed UTF-8 char array. How can I do that on
iOS please?

On macOS I can simply use CreateTextEncoding(), TECCreateConverter(),
and TECConvertText() but apparently these APIs aren't available on iOS.

Any ideas?

-- 
Best regards,
 Andreas Falkenhahn  mailto: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 27, 2016, at 7:25 AM, Andreas Falkenhahn  
> wrote:
> 
> On 27.11.2016 at 00:04 David Duncan wrote:
> 
>> What are you trying to accomplish?
> 
> I want to keep my UIView centered on the screen so I need to
> change its position when the device rotates. I'm currently
> moving the UIView to the new position using
> 
>[myView setFrame:...];
> 
> in viewDidLayoutSubviews(). 

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).

> 
>> For most developers just looking at the aspect ratio in
>> viewDidLayoutSubviews is sufficient. 
> 
> Right, this would probably be a nicer way than using a flag.
> 
>> If you only want to do
>> something for rotating, doing it as an alongside animation in
>> viewWillTransitionToSize is usually what you want.
> 
> Do you mean that I should move the UIView in my "animateAlongsideTransition"
> block instead of viewDidLayoutSubviews()? This seems to work as
> well but I don't really know anything about those animation
> handlers so I felt more comfortable doing this in viewDidLayoutSubviews().

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.

> 
>> Also from your last thread, if you are trying to fix up a
>> transform, it may be easier to use contentMode instead of transform
>> for this case. AspectFit vs AspectFill will do the common letterbox
>> vs clip without you needing to do anything further.
> 
> Yes, I'm actually using contentMode now. If this is set to
> UIViewContentModeScaleToFill, I can just change the bounds
> of the UIView and I'll get GPU-accelerated scaling for free
> 
> -- 
> 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: How to convert from decomposed to precomposed UTF-8 on iOS

[David Duncan]

> On Nov 28, 2016, at 10:36 AM, Andreas Falkenhahn  
> wrote:
> 
> (I'm sorry, but this mail isn't really about Cocoa but I've checked all
> the lists hosted on lists.apple.com and I haven't found a list which
> is suitable so I'll try here.)
> 
> I need to convert a char array that contains decomposed UTF-8 characters
> (as used by HFS) into a precomposed UTF-8 char array. How can I do that on
> iOS please?
> 
> On macOS I can simply use CreateTextEncoding(), TECCreateConverter(),
> and TECConvertText() but apparently these APIs aren't available on iOS.

NSString should have what you need – it has methods to obtain a corresponding 
NSString in forms C/D/KC/KD. Look for decomposed/precomposed properties.

> 
> Any ideas?
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto: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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.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: How to convert from decomposed to precomposed UTF-8 on iOS

[Andreas Falkenhahn]

On 28.11.2016 at 16:54 David Duncan wrote:

>> On Nov 28, 2016, at 10:36 AM, Andreas Falkenhahn  
>> wrote:

>> (I'm sorry, but this mail isn't really about Cocoa but I've checked all
>> the lists hosted on lists.apple.com and I haven't found a list which
>> is suitable so I'll try here.)

>> I need to convert a char array that contains decomposed UTF-8 characters
>> (as used by HFS) into a precomposed UTF-8 char array. How can I do that on
>> iOS please?

>> On macOS I can simply use CreateTextEncoding(), TECCreateConverter(),
>> and TECConvertText() but apparently these APIs aren't available on iOS.

> NSString should have what you need – it has methods to obtain a
> corresponding NSString in forms C/D/KC/KD. Look for
> decomposed/precomposed properties.

Thanks, NSString.precomposedStringWithCanonicalMapping did the trick.

-- 
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: Vertically Centered Colon

[Gerriet M. Denkmann]

> 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. 

> 
> On Mon, Nov 28, 2016 at 10:02 AM Gerriet M. Denkmann  
> wrote:
> iOS 10.1.1
> 
> WWDC 2015,Session 804: Introducing the New System Fonts tells (at about 
> 23:23) about Vertically Centered Colons.
> But I do not understand, how to turn this on.
> 
> It works automatically (in SF) with colons surrounded by digits.
> 
> But in my case I have “21:37:44” where ““21:37” is bold and “:44” is thin. 
> And the ‘:’ in front of “44” is not surrounded by digits. So I want to turn 
> this feature on explicitly.
> 
> How to do this?
> 
> 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

[Alastair Houghton]

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.

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.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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 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.

a. Are you using an attributed string whose text is “21:37:44”, or two 
unattributed strings?

b. You have a — I don’t know exactly what to call it — “logical” or 
“consistency” problem inherent in this situation, because it’s not obvious 
which font the second “:” should be in. I’m not suggesting you’re incapable of 
making a decision, but that your actual problem is a consequence of this 
underlying ambiguity. What would you do if the “:” glyphs were radically 
different in the two fonts?

c. Where does the colon character come from in the first place? Specifically, 
you’re using a formatted time string, which could be expected to come from 
(say) a DateFormatter. How do you know there are going to be any colons at all, 
let alone two of them? 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.)

What I’m suggesting is that perhaps you should treat this as something like a 
code smell, and re-evaluate whether changing fonts in the middle of the time 
string is a good idea.

FWIW.

___

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]

I have old iOS attributed strong code that explicitly handles superscripting 
specific characters in an NS attributed string from the baseline by a % of the 
character height or by a fixed pixel amount.

Let me know if you want it.

Sent from my iPhone

> On Nov 28, 2016, at 10:42 AM, 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.
> 
> 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.
> 
> Kind regards,
> 
> Alastair.
> 
> --
> http://alastairs-place.net
> 
> 
> ___
> 
> 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

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.
> 
> a. Are you using an attributed string whose text is “21:37:44”, or two 
> unattributed strings?

One attributed string, where the first 5 chars have NSFontAttributeName = 
boldFont and the last 3 have
NSFontAttributeName = thinFont.

> b. You have a — I don’t know exactly what to call it — “logical” or 
> “consistency” problem inherent in this situation, because it’s not obvious 
> which font the second “:” should be in. I’m not suggesting you’re incapable 
> of making a decision, but that your actual problem is a consequence of this 
> underlying ambiguity. What would you do if the “:” glyphs were radically 
> different in the two fonts?

UIFont *boldFont = [ UIFont systemFontOfSize: pointSize  weight: 
UIFontWeightLight ];
UIFont *thinFont = [ UIFont systemFontOfSize: pointSize  weight: 
UIFontWeightUltraLight ];

I just assume that the glyphs, coming form the same family, are somewhat 
consistent.

> c. Where does the colon character come from in the first place? Specifically, 
> you’re using a formatted time string, which could be expected to come from 
> (say) a DateFormatter. How do you know there are going to be any colons at 
> all, let alone two of them?

They indeed come from an NSDateFormatter:
timeFormatter = [ [ NSDateFormatter alloc ] init];
timeFormatter.dateFormat = @"HH:mm:ss";  

> 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.)
> 
> What I’m suggesting is that perhaps you should treat this as something like a 
> code smell, and re-evaluate whether changing fonts in the middle of the time 
> string is a good idea.

The effect I am after is: hours and minutes should be emphasized, the seconds 
should not.
Maybe I could use the same font with different colours: black versus light gray 
or something like this.

But right now I am still trying to implement Alistairs suggestion.


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: Vertically Centered Colon

[Gerriet M. Denkmann]

> 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;
NSLayoutManager *layoutManager = dummyTextView.layoutManager;
[ layoutManager ensureGlyphsForCharacterRange: range ];
[ layoutManager ensureLayoutForCharacterRange: range ];
NSUInteger glyphIndex = [ layoutManager glyphIndexForCharacterAtIndex: 2 ];
centeredColonGlyph = [ layoutManager CGGlyphAtIndex: glyphIndex ];;


and then:

CFMutableAttributedStringRef aStr = (__bridge 
CFMutableAttributedStringRef)attributedString;
CTFontRef fontRiff = (__bridge CTFontRef)thinFont;
CTGlyphInfoRef glyInfRef = CTGlyphInfoCreateWithGlyph( centeredColonGlyph, 
fontRiff, (CFStringRef)@":" );
CFRange range = { (CFIndex)colonIndex, 1 };
CFAttributedStringSetAttribute( aStr, range, kCTGlyphInfoAttributeName, 
glyInfRef );
CFRelease(glyInfRef);

This seems to be working. Nut sure whether there is a more elegant way.

Thanks a lot for your help!


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: Vertically Centered Colon

[Doug Hill]

A couple of things to note:

1. In the SF font, colons are vertically centered by default.
You can test this by creating a plain UILabel with System Font in IB and type a 
time e.g. 10:20, and notice the colon is vertically centered. So if you use SF 
font, you don't have to do anything to get the centered colon feature.

2. The font for UILabel with an attributed string 'text' property appears NOT 
to be SF font (e.g. System Font) by default.
Again, to test this create a UILabel in IB and change Text to an attributed 
string, notice that the font changes to Helvetica Neue. I also notice that SF 
font doesn't show up in the list of fonts in IB for this label. FWIW, I'm still 
using Xcode 7.x so someone should try Xcode 8 to verify if this is still the 
case.
For the heck of it I installed SF font on my Mac so I can select it in the 
attributed text font list, but notice a bunch of bugs. For example, the font 
size I set in IB for the attributed text is ignored. At runtime it's probably 
12 or 14 pt. Also, in IB, if you edit the text by double-clicking in the label, 
you'll see an input field for large text but nothing shown. Oh well, another 
trip to RADAR.
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. 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'

Which Helvetica Neue DOES NOT support.

Furthermore, I don't see a way to set these  'Alternative Stylistic' attributes 
from UIAttributedText. I do see some settings in CoreText/SFNTLayoutTypes.h 
under kStylisticAlternativesType. But the settings are just numbered so I don't 
know which it might be. A little experimentation might find the right one.

But in summary, if you are using SF font, you don't need to set the Vertically 
Centered Colon attribute as it should be on by default.

Doug Hill



> 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;
> NSLayoutManager *layoutManager = dummyTextView.layoutManager;
> [ layoutManager ensureGlyphsForCharacterRange: range ];
> [ layoutManager ensureLayoutForCharacterRange: range ];
> NSUInteger glyphIndex = [ layoutManager glyphIndexForCharacterAtIndex: 2 ];
> centeredColonGlyph = [ layoutManager CGGlyphAtIndex: glyphIndex ];;
> 
> 
> and then:
> 
> CFMutableAttributedStringRef aStr = (__bridge 
> CFMutableAttributedStringRef)attributedString;
> CTFontRef fontRiff = (__bridge CTFontRef)thinFont;
> CTGlyphInfoRef glyInfRef = CTGlyphInfoCreateWithGlyph( centeredColonGlyph, 
> fontRiff, (CFStringRef)@":" );
> CFRange range = { (CFIndex)colonIndex, 1 };
> CFAttributedStringSetAttribute( aStr, range, kCTGlyphInfoAttributeName, 
> glyInfRef );
> CFRelease(glyInfRef);
> 
> This seems to be working. Nut sure whether there is a more elegant way.
> 
> Thank

Re: Vertically Centered Colon

[Doug Hill]

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.

Doug Hill


> On Nov 28, 2016, at 12:33 PM, Doug Hill  wrote:
> 
> A couple of things to note:
> 
> 1. In the SF font, colons are vertically centered by default.
> You can test this by creating a plain UILabel with System Font in IB and type 
> a time e.g. 10:20, and notice the colon is vertically centered. So if you use 
> SF font, you don't have to do anything to get the centered colon feature.
> 
> 2. The font for UILabel with an attributed string 'text' property appears NOT 
> to be SF font (e.g. System Font) by default.
> Again, to test this create a UILabel in IB and change Text to an attributed 
> string, notice that the font changes to Helvetica Neue. I also notice that SF 
> font doesn't show up in the list of fonts in IB for this label. FWIW, I'm 
> still using Xcode 7.x so someone should try Xcode 8 to verify if this is 
> still the case.
> For the heck of it I installed SF font on my Mac so I can select it in the 
> attributed text font list, but notice a bunch of bugs. For example, the font 
> size I set in IB for the attributed text is ignored. At runtime it's probably 
> 12 or 14 pt. Also, in IB, if you edit the text by double-clicking in the 
> label, you'll see an input field for large text but nothing shown. Oh well, 
> another trip to RADAR.
> 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. 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'
> 
> Which Helvetica Neue DOES NOT support.
> 
> Furthermore, I don't see a way to set these  'Alternative Stylistic' 
> attributes from UIAttributedText. I do see some settings in 
> CoreText/SFNTLayoutTypes.h under kStylisticAlternativesType. But the settings 
> are just numbered so I don't know which it might be. A little experimentation 
> might find the right one.
> 
> But in summary, if you are using SF font, you don't need to set the 
> Vertically Centered Colon attribute as it should be on by default.
> 
> Doug Hill
> 
> 
> 
>> 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;
>> NSLayoutManager *layoutManager = dummyTextView.layoutManager;
>> [ layoutManager ensureGlyphsForCharacterRange: range ];
>> [ layoutManager ensureLa

Preserving knowledge of renamed/moved directory?

[Rick Mann]

Back in the days before URLs, I could have an FSRef to a directory, and no 
matter where I moved that directory what I named it, the FSRef was still valid, 
and I could still read/write to it.

Now that everything is URL based, if a thread changes the name of a directory, 
or moves it, another thread's URL pointing to that directory (or inside it) 
becomes invalid, right?

Is there any way for this to not be the case? That is, for a URL to a directory 
or subdirectory or item within to stay valid even if the path to it changes?

-- 
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: Preserving knowledge of renamed/moved directory?

[Charles Srstka]

> On Nov 28, 2016, at 7:06 PM, Rick Mann  wrote:
> 
> Back in the days before URLs, I could have an FSRef to a directory, and no 
> matter where I moved that directory what I named it, the FSRef was still 
> valid, and I could still read/write to it.
> 
> Now that everything is URL based, if a thread changes the name of a 
> directory, or moves it, another thread's URL pointing to that directory (or 
> inside it) becomes invalid, right?
> 
> Is there any way for this to not be the case? That is, for a URL to a 
> directory or subdirectory or item within to stay valid even if the path to it 
> changes?

I’ve got good news and bad news.

The good news: Yes, there is a way. Just call .fileReferenceURL on an NSURL in 
Objective-C, and you’ll get something that works just like an FSRef.

The bad news: This is currently broken in Swift, as of Swift 3, where all file 
reference URLs will get silently and unceremoniously converted back to 
path-based ones at the bridge. This can be worked around via an Objective-C 
wrapper, though.

Charles


___

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: Preserving knowledge of renamed/moved directory?

[Quincey Morris]

On Nov 28, 2016, at 17:30 , Charles Srstka  wrote:
> 
> This is currently broken in Swift, as of Swift 3, where all file reference 
> URLs will get silently and unceremoniously converted back to path-based ones 
> at the bridge.

NSURL or URL or both?

___

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: Preserving knowledge of renamed/moved directory?

[Rick Mann]

> On Nov 28, 2016, at 17:30 , Charles Srstka  wrote:
> 
>> On Nov 28, 2016, at 7:06 PM, Rick Mann  wrote:
>> 
>> Back in the days before URLs, I could have an FSRef to a directory, and no 
>> matter where I moved that directory what I named it, the FSRef was still 
>> valid, and I could still read/write to it.
>> 
>> Now that everything is URL based, if a thread changes the name of a 
>> directory, or moves it, another thread's URL pointing to that directory (or 
>> inside it) becomes invalid, right?
>> 
>> Is there any way for this to not be the case? That is, for a URL to a 
>> directory or subdirectory or item within to stay valid even if the path to 
>> it changes?
> 
> I’ve got good news and bad news.
> 
> The good news: Yes, there is a way. Just call .fileReferenceURL on an NSURL 
> in Objective-C, and you’ll get something that works just like an FSRef.
> 
> The bad news: This is currently broken in Swift, as of Swift 3, where all 
> file reference URLs will get silently and unceremoniously converted back to 
> path-based ones at the bridge. This can be worked around via an Objective-C 
> wrapper, though.

LOL, naturally. 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: Preserving knowledge of renamed/moved directory?

[Charles Srstka]

> On Nov 28, 2016, at 7:42 PM, Quincey Morris 
>  wrote:
> 
> On Nov 28, 2016, at 17:30 , Charles Srstka  > wrote:
>> 
>> This is currently broken in Swift, as of Swift 3, where all file reference 
>> URLs will get silently and unceremoniously converted back to path-based ones 
>> at the bridge.
> 
> NSURL or URL or both?

.fileReferenceURL doesn’t exist on URL. It does exist on NSURL, but thanks to 
the bridging magic it returns a URL, which the ObjC-Swift bridge turns into a 
normal file path URL.

Unfortunately, the second comment on this thread: 
https://bugs.swift.org/browse/SR-2728  
indicates that this might have been intentional behavior. :-/

Charles

___

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: Preserving knowledge of renamed/moved directory?

[Sean McBride]

On Mon, 28 Nov 2016 17:06:41 -0800, Rick Mann said:

>Back in the days before URLs, I could have an FSRef to a directory, and
>no matter where I moved that directory what I named it, the FSRef was
>still valid, and I could still read/write to it.
>
>Now that everything is URL based, if a thread changes the name of a
>directory, or moves it, another thread's URL pointing to that directory
>(or inside it) becomes invalid, right?
>
>Is there any way for this to not be the case? That is, for a URL to a
>directory or subdirectory or item within to stay valid even if the path
>to it changes?

Stay valid for how long?  If you need to persistent them, use them across 
reboots, etc. see 
bookmarkDataWithOptions:includingResourceValuesForKeys:relativeToURL:error.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: Preserving knowledge of renamed/moved directory?

[Rick Mann]

> On Nov 28, 2016, at 18:14 , Sean McBride  wrote:
> 
> On Mon, 28 Nov 2016 17:06:41 -0800, Rick Mann said:
> 
>> Back in the days before URLs, I could have an FSRef to a directory, and
>> no matter where I moved that directory what I named it, the FSRef was
>> still valid, and I could still read/write to it.
>> 
>> Now that everything is URL based, if a thread changes the name of a
>> directory, or moves it, another thread's URL pointing to that directory
>> (or inside it) becomes invalid, right?
>> 
>> Is there any way for this to not be the case? That is, for a URL to a
>> directory or subdirectory or item within to stay valid even if the path
>> to it changes?
> 
> Stay valid for how long?  If you need to persistent them, use them across 
> reboots, etc. see 
> bookmarkDataWithOptions:includingResourceValuesForKeys:relativeToURL:error.

Just that launch.


-- 
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