Re: UILabel is maiming my Character

2015-10-14 Thread Gerriet M. Denkmann 

> On 15 Oct 2015, at 00:03, David Duncan  wrote:
> 
> 
>> On Oct 14, 2015, at 4:02 AM, Gerriet M. Denkmann  
>> wrote:
>> 
>> I put into some iOS 9 app (Xcode 7.0)  4 UILabels.
>> All have Clip Subviews = off, font size 96 with a coloured background, text 
>> plain = “ฟี้กุฎุมพี”.
>> 
>> The difference is the font:
>> 
>> System: ok (but is too bold for my taste)
>> Thonburi and Thonburi Light: bottom get cut off 
>> System Light: bottom gets cut off rather much
>> 
>> System also uses Thonburi as font substitution.
>> 
>> With Clip Subviews = on the characters get clipped to the coloured 
>> background, which is even worse.
>> Note: some characters go well beyond the descender line (as specified by the 
>> font) and also above the line height.
>> 
>> How can I get a UILabel which does not maim my characters?
>> (Another question would be: how to get a background which covers all of the 
>> characters. But this is not important to me right now)
>> 
>> These UILabels are ultimately meant to go into UITableViewCells (without 
>> coloured background).
> 
> You will probably need to use an attributed string that specifies a taller 
> line height than normal. This happens automatically when the system language 
> is set to languages such as Thai, but not for other languages, as it would 
> apply to all text strings.

Thanks for this hint.
And thanks a lot to Alex for his very helpful code example!

Moving the baseLine up by about 8 % and increasing the LineHeight by 5 %  
finally (after lots of fiddling) gives me an acceptable UILabel with SystemFont 
Light.

CGFloat baseChangePercent = +8; 
CGFloat lineChangePercent = +5; 

CGFloat baselineOffset = fontSize * baseChangePercent / 100 ;
CGFloat lineHeightMultiple = 1 + lineChangePercent / 100;

NSMutableParagraphStyle *paragraph = [ [ NSMutableParagraphStyle alloc ] init ];
paragraph.lineHeightMultiple = lineHeightMultiple;

attributes =@{  NSBaselineOffsetAttributeName:  @(baselineOffset),
NSFontAttributeName:
font,
NSParagraphStyleAttributeName:  
paragraph,
 };
But of course these values are heavily dependent on the font (and maybe even on 
fontSize).

How to compute these numbers directly (as opposed to trial and error)?


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: More Xcode 7 inconsistency?

2015-10-14 Thread Charles Srstka 
> On Oct 14, 2015, at 6:36 PM, Shane Stanley  wrote:
> 
> On 15 Oct 2015, at 4:02 AM, David Duncan  > wrote:
>> 
>> The helpful followup is that it is generally encouraged to use empty 
>> containers (@[] or @{}) over nil when there is no semantic difference, as is 
>> the case for the aforementioned API.
> 
> OK, but the docs still say: "The dictionary contains values from Document 
> Types and must at least contain NSDocumentTypeDocumentAttribute." That 
> suggests to me that an empty dictionary is not allowed.

The docs and headers for NSAttributedString contain a lot of copy/paste stuff, 
which I think is part of the problem. The bit you quoted is copied directly 
from the description for -[NSAttributedString 
dataFromRange:documentAttribute:error:], which notably does *not* contain the 
bit about nil being allowed for the dictionary. This is because this method 
returns data in an unspecified format, so if you don’t provide the dictionary 
and specify a document type attribute, there is no way that it can know what to 
do. For the type-specific variants of this method, like 
docFormatFromRange:bla:bla: and RTFFromRange:bla:bla:, the output document 
format is known, so NSDocumentTypeDocumentAttribute isn’t really necessary, and 
indeed, if you supply it, it seems to be ignored. So, the documentation 
contains a note here that the dictionary can be nil—and if you try it, it works 
fine.

So, to my mind, it makes sense for dataFromRange:bla:bla: to have a 
non-optional attributes parameter, and for the rest of them to have an optional 
one. But even if you don’t agree, the bottom line is that something needs to be 
changed, whether that be the headers or the documentation, since the 
documentation does say that it can be nil.

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: More Xcode 7 inconsistency?

2015-10-14 Thread David Duncan 

> On Oct 14, 2015, at 4:36 PM, Shane Stanley  wrote:
> 
> On 15 Oct 2015, at 4:02 AM, David Duncan  wrote:
>> 
>> The helpful followup is that it is generally encouraged to use empty 
>> containers (@[] or @{}) over nil when there is no semantic difference, as is 
>> the case for the aforementioned API.
> 
> OK, but the docs still say: "The dictionary contains values from Document 
> Types and must at least contain NSDocumentTypeDocumentAttribute." That 
> suggests to me that an empty dictionary is not allowed.

I can’t speak for either the documentation or the implementation in this case, 
but I think the reasonable conclusion to make here is that either nil is 
allowed, or an empty dictionary is allowed, despite the documentation basically 
saying that both are disallowed, otherwise you cannot maintain the same API 
contract as was previously available.

I understand thats not a terribly satisfying answer, but given the direction I 
would suspect an empty dictionary is perfectly fine in this case.

--
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: More Xcode 7 inconsistency?

2015-10-14 Thread Shane Stanley 
On 15 Oct 2015, at 4:02 AM, David Duncan  wrote:
> 
> The helpful followup is that it is generally encouraged to use empty 
> containers (@[] or @{}) over nil when there is no semantic difference, as is 
> the case for the aforementioned API.

OK, but the docs still say: "The dictionary contains values from Document Types 
and must at least contain NSDocumentTypeDocumentAttribute." That suggests to me 
that an empty dictionary is not allowed.

-- 
Shane Stanley 



___

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

2015-10-14 Thread Raglan T. Tiger 

-rags



> On Oct 14, 2015, at 2:37 PM, David Duncan  wrote:
> 
> Ensure that the text matrix is sane 


I have been doing this:

CGAffineTransform t = CGAffineTransformMakeScale (1.0, -1.0);
CGContextSetTextMatrix (ctx, t);


changing the sx and sy just scrunches the text into a blob

what the crusade am I not understanding?


-rags


___

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

2015-10-14 Thread David Duncan 
Ensure that the text matrix is sane (its separate from the current ctm and not 
stored with the graphics state).
> On Oct 14, 2015, at 1:36 PM, Raglan T. Tiger  wrote:
> 
> 
>> On Oct 13, 2015, at 4:42 PM, Wim Lewis  wrote:
>> 
>> 
>> On Oct 13, 2015, at 3:02 PM, Raglan T. Tiger  wrote:
>>> CGContextShowTextAtPoint (ctx, pt.x,pt.y,(const char*)txt, len );
>>> 
>>> This has printed my text UNTIL 10.11.
>>> 
>>> I see that CGContextShowTextAtPoint is deprecated in 10.9 ... is it gone in 
>>> 10.11?
>> 
>> As Quincey Morris says, Core Text 
> 
> I have text printing in the correct orientation now using
> 
> CFAttributedStringRef attrString = 
> CFAttributedStringCreate(kCFAllocatorDefault, cfstr, attributes);
> 
> CTLineRef line = CTLineCreateWithAttributedString(attrString);
> 
>// Set text position and draw the line into the graphics context
>CGContextSetTextPosition(ctx, pt.x, pt.y);
>CTLineDraw(line, ctx);
> 
> Now, I cannot increase the font size.  I set up attributes as:
> 
>CFStringRef keys[] = { kCTFontAttributeName };
>CFTypeRef values[] = { [ NSFont systemFontOfSize:48 ] };
> 
>CFDictionaryRef attributes =
>CFDictionaryCreate(kCFAllocatorDefault, (const void**)&keys,
>   (const void**)&values, sizeof(keys) / 
> sizeof(keys[0]),
>   &kCFTypeDictionaryKeyCallBacks,
>   &kCFTypeDictionaryValueCallBacks);
> 
> 
> and see my attributed string as:
> 
> 667 x, 2.3 y{
>NSFont = "\".HelveticaNeueDeskInterface-Regular 48.00 pt. P [] 
> (0x1128ca30) fobj=0x11d04390, spc=12.93\"";
> }
> 
> but the result is like 8 pt not 48. 
> ___
> 
> 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: CGContextShowTextAtPoint

2015-10-14 Thread Raglan T. Tiger 

> On Oct 13, 2015, at 4:42 PM, Wim Lewis  wrote:
> 
> 
> On Oct 13, 2015, at 3:02 PM, Raglan T. Tiger  wrote:
>> CGContextShowTextAtPoint (ctx, pt.x,pt.y,(const char*)txt, len );
>> 
>> This has printed my text UNTIL 10.11.
>> 
>> I see that CGContextShowTextAtPoint is deprecated in 10.9 ... is it gone in 
>> 10.11?
> 
> As Quincey Morris says, Core Text 

I have text printing in the correct orientation now using

CFAttributedStringRef attrString = 
CFAttributedStringCreate(kCFAllocatorDefault, cfstr, attributes);

CTLineRef line = CTLineCreateWithAttributedString(attrString);

// Set text position and draw the line into the graphics context
CGContextSetTextPosition(ctx, pt.x, pt.y);
CTLineDraw(line, ctx);

Now, I cannot increase the font size.  I set up attributes as:

CFStringRef keys[] = { kCTFontAttributeName };
CFTypeRef values[] = { [ NSFont systemFontOfSize:48 ] };

CFDictionaryRef attributes =
CFDictionaryCreate(kCFAllocatorDefault, (const void**)&keys,
   (const void**)&values, sizeof(keys) / 
sizeof(keys[0]),
   &kCFTypeDictionaryKeyCallBacks,
   &kCFTypeDictionaryValueCallBacks);


and see my attributed string as:

667 x, 2.3 y{
NSFont = "\".HelveticaNeueDeskInterface-Regular 48.00 pt. P [] (0x1128ca30) 
fobj=0x11d04390, spc=12.93\"";
}

but the result is like 8 pt not 48. 
___

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

2015-10-14 Thread Conrad Shultz 

> On Oct 14, 2015, at 11:41 AM, Raglan T. Tiger  wrote:
> 
> 
> 
>> On Oct 14, 2015, at 10:02 AM, Jens Alfke  wrote:
>> 
>> The view is probably using flipped coordinates. Look up flipped coordinates 
>> in the Cocoa view documentation to understand what they are and how to work 
>> around the problem.
>> 
>> As for the size, have you set the size of the NSFont in ‘sysFont’?
>> 
> 
> I am using -graphicsContextWithBitmapImageRep and then adding text 
> annotations.  The reason for using CGContextShowTextAtPoint in the first 
> place was to solve this problem when drawing NSStrings.
> 
> I guess the real question is "How to you draw NSStrings as flipped == YES 
> when the current NSGraphicsContext is graphicsContextWithBitmapImageRep which 
> is flipped = NO.

If I understand your question, I’d expect you could set the graphics context’s 
transform (see the CGContextFooCTM() family of functions), draw your text, then 
reset the transform.

-Conrad
___

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

2015-10-14 Thread Raglan T. Tiger 


> On Oct 14, 2015, at 10:02 AM, Jens Alfke  wrote:
> 
> The view is probably using flipped coordinates. Look up flipped coordinates 
> in the Cocoa view documentation to understand what they are and how to work 
> around the problem.
> 
> As for the size, have you set the size of the NSFont in ‘sysFont’?
> 

I am using -graphicsContextWithBitmapImageRep and then adding text annotations. 
 The reason for using CGContextShowTextAtPoint in the first place was to solve 
this problem when drawing NSStrings.

I guess the real question is "How to you draw NSStrings as flipped == YES when 
the current NSGraphicsContext is graphicsContextWithBitmapImageRep which is 
flipped = NO.


-rags
___

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: More Xcode 7 inconsistency?

2015-10-14 Thread Charles Srstka 
> On Oct 14, 2015, at 12:02 PM, David Duncan  wrote:
> 
> The intended meaning was “the warning (about passing nil) is intended”. The 
> helpful followup is that it is generally encouraged to use empty containers 
> (@[] or @{}) over nil when there is no semantic difference, as is the case 
> for the aforementioned API.

I took it to mean that something was supposed to be logged to the Console if 
you passed nil to it (which doesn’t happen in my testing). While it's certainly 
true that @{} is a perfectly fine way to pass an empty set of data to this 
method, the documentation says that nil is fine, which is an inconsistency. My 
argument was that either the method signature or the documentation needs to be 
changed so that they agree with each other.

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: UILabel is maiming my Character

2015-10-14 Thread Alex Zavatone 
NSAttributedText works really nice with these.

I'll send you some material on that.

On Oct 14, 2015, at 7:02 AM, Gerriet M. Denkmann wrote:

> I put into some iOS 9 app (Xcode 7.0)  4 UILabels.
> All have Clip Subviews = off, font size 96 with a coloured background, text 
> plain = “ฟี้กุฎุมพี”.
> 
> The difference is the font:
> 
> System: ok (but is too bold for my taste)
> Thonburi and Thonburi Light: bottom get cut off 
> System Light: bottom gets cut off rather much
> 
> System also uses Thonburi as font substitution.
> 
> With Clip Subviews = on the characters get clipped to the coloured 
> background, which is even worse.
> Note: some characters go well beyond the descender line (as specified by the 
> font) and also above the line height.
> 
> How can I get a UILabel which does not maim my characters?
> (Another question would be: how to get a background which covers all of the 
> characters. But this is not important to me right now)
> 
> These UILabels are ultimately meant to go into UITableViewCells (without 
> coloured background).
> 
> 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/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: UILabel is maiming my Character

2015-10-14 Thread David Duncan 

> On Oct 14, 2015, at 4:02 AM, Gerriet M. Denkmann  wrote:
> 
> I put into some iOS 9 app (Xcode 7.0)  4 UILabels.
> All have Clip Subviews = off, font size 96 with a coloured background, text 
> plain = “ฟี้กุฎุมพี”.
> 
> The difference is the font:
> 
> System: ok (but is too bold for my taste)
> Thonburi and Thonburi Light: bottom get cut off 
> System Light: bottom gets cut off rather much
> 
> System also uses Thonburi as font substitution.
> 
> With Clip Subviews = on the characters get clipped to the coloured 
> background, which is even worse.
> Note: some characters go well beyond the descender line (as specified by the 
> font) and also above the line height.
> 
> How can I get a UILabel which does not maim my characters?
> (Another question would be: how to get a background which covers all of the 
> characters. But this is not important to me right now)
> 
> These UILabels are ultimately meant to go into UITableViewCells (without 
> coloured background).

You will probably need to use an attributed string that specifies a taller line 
height than normal. This happens automatically when the system language is set 
to languages such as Thai, but not for other languages, as it would apply to 
all text strings.

> 
> 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/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: More Xcode 7 inconsistency?

2015-10-14 Thread David Duncan 

> On Oct 13, 2015, at 10:13 PM, Charles Srstka  wrote:
> 
>> On Oct 13, 2015, at 10:27 PM, Shane Stanley  
>> wrote:
>> 
>> On 14 Oct 2015, at 1:33 PM, Graham Cox  wrote:
>>> 
>>> I’ve been passing nil forever, only now does Xcode 7 complain, presumably 
>>> because only now is the _Nonnull attribute added. But either the 
>>> documentation or the addition of _Nonnull is wrong.
>> 
>> FWIW, I've had an open bug on this since July (#21667200). You might also 
>> notice the docs say "dict can be nil", and there isn't a "dict" to be seen 
>> (presumably it means docAttributes).
> 
> I actually reported this one back in June (rdar://21314130). Mine got closed 
> with this as the rationale:
> 
> "This issue behaves as intended based on the following:
> 
> It’s intended to log warnings.
> 
> We are now closing this bug report.”
> 
> Hopefully that makes sense to someone. (In fairness, it does seem that the 
> Radar was re-opened sometime in the meantime, though, as it’s showing up as 
> “Open” now. Not sure if that's due to the protestations I added to the 
> report, or due to the radar you filed in July.)

The intended meaning was “the warning (about passing nil) is intended”. The 
helpful followup is that it is generally encouraged to use empty containers 
(@[] or @{}) over nil when there is no semantic difference, as is the case for 
the aforementioned API.

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

2015-10-14 Thread Jens Alfke 

> On Oct 14, 2015, at 8:54 AM, Raglan T. Tiger  wrote:
> 
> I did all the above ... now my text prints upside down andI cannot get it to 
> size up regardless of the font size.

The view is probably using flipped coordinates. Look up flipped coordinates in 
the Cocoa view documentation to understand what they are and how to work around 
the problem.

As for the size, have you set the size of the NSFont in ‘sysFont’?

—Jens
___

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: Handling http:// URLs

2015-10-14 Thread Jens Alfke 

> On Oct 14, 2015, at 4:26 AM, Greg Weston  wrote:
> 
> You could contrive a use case for just about any behavior you could imagine. 
> Lacking the aforementioned concrete example, I can't come up with any of my 
> own that aren't handled at least as well by a more "normal" mechanism and it 
> strikes me that this has much more potential for abuse, or at least confusion 
> and annoyance, than for unique utility.

It would allow feature parity for unofficial apps for a web-based service. 

For example, it would be great if http://wikipedia.org URLs opened in a 
Wikipedia app like Articles or Wikipanion. Unfortunately the current system 
requires adding a web page in the wikipedia.org domain, so only the people who 
run Wikipedia can decide which app the URLs should open in, and presumably 
if/when they implement this they’ll choose their own official app. The 
developers of unofficial apps are SOL.

This perpetuates the walled-garden system that was (unintentionally?) made 
possible by the OAuth protocol, where the developers of a Web service get to 
act as gatekeepers controlling what apps can interact with the service. Twitter 
has been pretty abusive about this in the past, choking off 3rd party Twitter 
apps.

That said, having a choosable set of handlers for websites would require adding 
a bunch of UI features (probably in the Settings app) to let users configure 
and maintain and troubleshoot these bindings, which would increase the 
complexity of the OS. I can imagine this is why Apple’s HI design group hasn’t 
gone this route. Or maybe they’re still working out the UI design and it’ll 
show up in iOS 10?

—Jens
___

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

2015-10-14 Thread Raglan T. Tiger 


> On Oct 13, 2015, at 4:56 PM, Graham Cox  wrote:
> 
> Converting this to use string drawing is easy enough:
> 
> NSDictionary* attributes = @{NSFontAttributedName:sysFont};
> NSString* myText = [NSString stringWithUTF8String:txt];   // 
> check encoding if not UTF-8
> 
> [myText drawAtPoint:pt withAttributes:attributes];


I did all the above ... now my text prints upside down andI cannot get it to 
size up regardless of the font size.

Any direction is much appreciated.

-rags
___

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: NSGraphicsContext currentContext() returns nil on OSX 10.11

2015-10-14 Thread Ken Thomases 
On Oct 14, 2015, at 5:44 AM, Lakshmi P Shanmugam  
wrote:

> Thanks for your response.

You're welcome.

> Hover over a cell in a Table. Framework calls NSCell 
> expansionFrameWithFrame:inView. And then calls NSCell cellSize. In our 
> overridden implementation of cellSize, we try to get the graphics context 
> using currentContext. This worked fine in all previous versions upto OSX 
> 10.11 and started failing now.
> Any idea on what could be wrong?

Yes, you're expecting a context to be current when there's no reason to expect 
that.  You were just getting unlucky before.  Yes, "unlucky", precisely because 
you were lulled into thinking what you were doing was OK and started depending 
on it, when it was never guaranteed and was subject to change, as you've now 
discovered.  Lucky would have been to have discovered the problem back when you 
first chose this implementation approach.

You need to change your implementation of -cellSize to not rely on there being 
any particular graphics context set up.  What were you using it for?

Regards,
Ken


___

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: Handling http:// URLs

2015-10-14 Thread Greg Weston 
>>  
> Admittedly, I'm currently struggling to find a concrete example of why this 
> is useful, but I just know it is:

This, I think, is one of those phrases that should give one pause when posting. 

> Any app(s) should be able to register URL patterns they're able to handle. If 
> the user takes an action that results in a URL being requested that one or 
> more of these apps could handle, iOS should present the user with a list of 
> these URLs, and get the user's permission to then handle the URL.

You could contrive a use case for just about any behavior you could imagine. 
Lacking the aforementioned concrete example, I can't come up with any of my own 
that aren't handled at least as well by a more "normal" mechanism and it 
strikes me that this has much more potential for abuse, or at least confusion 
and annoyance, than for unique utility.

Greg
___

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

UILabel is maiming my Character

2015-10-14 Thread Gerriet M. Denkmann 
I put into some iOS 9 app (Xcode 7.0)  4 UILabels.
All have Clip Subviews = off, font size 96 with a coloured background, text 
plain = “ฟี้กุฎุมพี”.

The difference is the font:

System: ok (but is too bold for my taste)
Thonburi and Thonburi Light: bottom get cut off 
System Light: bottom gets cut off rather much

System also uses Thonburi as font substitution.

With Clip Subviews = on the characters get clipped to the coloured background, 
which is even worse.
Note: some characters go well beyond the descender line (as specified by the 
font) and also above the line height.

How can I get a UILabel which does not maim my characters?
(Another question would be: how to get a background which covers all of the 
characters. But this is not important to me right now)

These UILabels are ultimately meant to go into UITableViewCells (without 
coloured background).

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: NSGraphicsContext currentContext() returns nil on OSX 10.11

2015-10-14 Thread Lakshmi P Shanmugam 
Thanks for your response.

Here is the use-case when this happens.

Hover over a cell in a Table. Framework calls NSCell
expansionFrameWithFrame:inView. And then calls NSCell cellSize. In our
overridden implementation of cellSize, we try to get the graphics context
using currentContext. This worked fine in all previous versions upto OSX
10.11 and started failing now.
Any idea on what could be wrong?

Thanks & Regards,
Lakshmi

On Mon, Oct 12, 2015 at 8:36 PM, Ken Thomases  wrote:

> On Oct 12, 2015, at 6:45 AM, Lakshmi P Shanmugam <
> lakshmipriya@gmail.com> wrote:
>
> > I'm running our application on OSX 10.11. NSGraphicsContext
> > currentContext() returns nil in one of the drawing methods.
>
> What drawing method and who called it, you or the framework?
>
> For example, I recently worked with somebody who was calling -drawRect:
> themselves, which is never valid.  The context won't be set up in that case
> because the framework is the one who sets it up prior to calling -drawRect:
> (which is why calling it yourself isn't valid).
>
> Regards,
> Ken
>
>

-- 
*Lakshmi*
___

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