Re: SOLVED Re: NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
Re: SOLVED Re: NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
- Subject: Re: SOLVED Re: NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
- From: Aki Inoue <email@hidden>
- Date: Wed, 19 Nov 2008 15:32:36 -0800
Or, you could create an NSView subclass instance with -isFlipped
overridden shared among non-flipped views.
You can add the flipped view to your view inside -drawRect: and -
lockFocus to it temporarily.
Depending on your rendering needs, this approach is preferable
performance-wise than allocating graphics context.
Aki
On 2008/11/19, at 14:22, Ken Ferry wrote:
On Tue, Nov 18, 2008 at 1:57 PM, Rua Haszard Morris
<email@hidden> wrote:
What are the different options for flipping the coordinates of the
destination view? I've tried doing it by scaling and translating the
CGContext, but this results in problems with underlining or the
character
orientation (depending on whether i flip the view back before or
after
drawing the text).
At the moment the only method which results in correct text is to
have a
custom view and override isFlipped - is this the only recommended
method?
Doug answered the overall question, but maybe I'll chime on this bit
specifically.
As you're finding, -isFlipped and the CTM are entirely orthogonal
pieces of data. If you're using NSLayoutManager, you need the current
context to return YES to -[NSGraphicsContext isFlipped], and you also
want the CTM set up so that the text goes where you want.
There is no setter for -[NSGraphicsContext isFlipped], but you don't
need to use a custom view. [NSGraphicsContext
graphicsContextWithGraphicsPort:[originalContext graphicsPort]
flipped:YES] would give you a graphics context object that is flipped
without otherwise modifying the CTM or anything.
-Ken
I ask because I have to use these strings within custom views
(which may for
example have rotated contexts), as well as in standard controls,
and simpler
custom views purely for drawing these attributed strings. If the
only method
to have the attributes (particularly underline) interpreted
correctly is to
perform the drawing in a isFlipped NSView subclass, then I need to
rejig
things so the complex custom views embed an NSView rather than draw
the
attributed string manually.
thanks
Rua HM.
On Nov 19, 2008, at 9:40 am, 11(November)/19/08, Rua Haszard Morris
wrote:
Thanks for the link, you are right, I had not seen that document!
On Nov 19, 2008, at 9:33 am, 11(November)/19/08, Douglas Davidson
wrote:
On Nov 18, 2008, at 12:18 PM, Rua Haszard Morris wrote:
To follow up.. below I have pasted the code that draws the text
(for my
test app, as opposed to the more complex ways of reproducing the
bug
elsewhere in my code). (the full test app is attached to the
radar bug)
I have been consulting the Text System Overview documentation,
which I
don't believe mentions this fact.
http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/TextArchitecture.html
I can understand that drawing text top to bottom makes sense,
but I am
surprised that the coordinate system of the destination context
has such
far-reaching side effects.
You're looking at the Text Systems Overview, which is very general
conceptual documentation, the sort you would consult to decide
which class
to use. What you want is the Text Layout Programming Guide for
Cocoa, which
gives more detailed direction as to how to use these classes.
The first
section,
http://developer.apple.com/documentation/Cocoa/Conceptual/TextLayout/Concepts/LayoutManager.html
under
the heading "Glyph Drawing" says, "The text system expects view
coordinates
to be flipped, like those of NSTextView." If you are going to be
drawing
using the layout manager directly, this is a hard-and-fast rule.
Douglas Davidson
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden