On 26 Sep 2013, at 04:52, Keary Suska cocoa-...@esoteritech.com wrote:
No, you have it right. The docs have it wrong. Please file a bug ;-)
Bug is in:
15086319
Jonathan
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post
According to this knowledge base article, if a paragraph has natural
writing direction, then the writing direction of the paragraph should
change depending on the first character of the paragraph:
http://support.apple.com/kb/PH11211?viewlocale=en_USlocale=en_US
The article gives an example where
I don't know if this is possible, but I was wondering if it's possible to
update a MCPeerID's displayName after MCSession is used for
MCAdvertiserAssistant? I know it's meant as a device identifier (a chosen
string or currentDevice name), but I'd like to use it in a slightly
different way.
What I
I'm having the same issue. When I dive into the view hierarchy in the debugger
I see the page control inside the UIPageViewController's view, but it's frame
is {0,0,0,0}.
Noah Desch
On Sep 25, 2013, at 7:11 PM, Rick Mann rm...@latencyzero.com wrote:
On Sep 25, 2013, at 15:27 , Daniel
On 27/09/2013, at 5:12 AM, Kyle Sluder k...@ksluder.com wrote:
The ruler has flipped to right-aligned, but the text, while running RTL,
is laid out flush-left. Why?
Because paragraph alignment and text direction are orthogonal?
How is this useful?
No automatic rule is going to satisfy all
On Thu, Sep 26, 2013, at 03:57 PM, Shane Stanley wrote:
On 27/09/2013, at 5:12 AM, Kyle Sluder k...@ksluder.com wrote:
The ruler has flipped to right-aligned, but the text, while running RTL,
is laid out flush-left. Why?
Because paragraph alignment and text direction are orthogonal?
But
On 27/09/2013, at 9:00 AM, Kyle Sluder k...@ksluder.com wrote:
ut it means the tabstops on the ruler have no relation to where the
text is laid out on screen.
it's a compromise to a difficult situation.
And it doesn't explain why explicitly setting the paragraph to RTL
causes text to align
The ruler has flipped to right-aligned, but the text, while running RTL,
is laid out flush-left. Why?
Because paragraph alignment and text direction are orthogonal?
But it means the tabstops on the ruler have no relation to where the
text is laid out on screen.
And it doesn't explain
So it turns out that if a view is being animated via the animator, autoresizing
is ignored. (The same goes for using a non-blocking NSViewAnimation.)
Simple project. Click button, and resize window while the view is slowly
resizing.
http://www.sethwillits.com/temp/ViewAnimatorResize.zip
Have
On Thu, Sep 26, 2013, at 04:14 PM, Shane Stanley wrote:
The text and the paragraph are different things.
Allow me to be more specific.
According to my understanding of the docs, NSTextView should lay out
text identically in both of these situations:
- Text in the range (0,
Likely natural is based on either the preferred language priority in system
preferences or the region format settings there in text edit.
Arguably, mixed RTL and LTR layout is non trivial and basically has no catch
all correct state, and is generally going to be the case of the dominant one is
On 27/09/2013, at 11:12 AM, Kyle Sluder k...@ksluder.com wrote:
- Text in the range (0, textStorage.length) has a value of
NSWritingDirectionNatural for the NSWritingDirectionAttributeName attribute
As I read the docs, NSWritingDirectionNatural is a type of NSTextAlignment,
specified by
On Sep 26, 2013, at 7:00 PM, Shane Stanley sstan...@myriad-com.com.au wrote:
On 27/09/2013, at 11:12 AM, Kyle Sluder k...@ksluder.com wrote:
- Text in the range (0, textStorage.length) has a value of
NSWritingDirectionNatural for the NSWritingDirectionAttributeName attribute
As I read
On 2013 Sep 26, at 21:02, dangerwillrobinsondan...@gmail.com wrote:
Good news is LTR languages tend to not have a lot of RTL interspersed.
It's somewhat common for authors in certain fields to have to mix, e.g.
German, Italian, Greek and Hebrew, or Hebrew, ProtoPhoenician, and
Arabic in the
14 matches
Mail list logo
