Re: NSLayoutManagers and NSTypesetters and NSGlyphGenerators, oh my!
Re: NSLayoutManagers and NSTypesetters and NSGlyphGenerators, oh my!
- Subject: Re: NSLayoutManagers and NSTypesetters and NSGlyphGenerators, oh my!
- From: Douglas Davidson <email@hidden>
- Date: Mon, 5 Jan 2004 15:49:45 -0800
On Jan 5, 2004, at 3:22 PM, Kaelin Colclasure wrote:
One of the first approaches I considered was to build an NSTextStorage
on top of an XML DOM representation, but I pretty quickly convinced
myself that it was going to be a long row to hoe. Then I thought about
trying to keep a DOM tree in sync with a vanilla NSTextStorage, and
eventually arrived at the idea that this would be easier if the nodes
of the tree were attached to the text as attributes. This seems to
work out reasonably well for me, in concept. The text system does the
natty bookkeeping of keeping the attribute ranges up-to-date as text
is typed in. There are nice hooks in place for me to "fix up" the tree
as nodes are restructured by cut-and-paste operations, etc. And it's
trivial to walk the attributes and generate the full XML version of
the document directly to a stream with no in-memory overhead required.
(One goal I have is that this editor should be usable when authoring
largish documents, like entire books.)
That sounds like quite a reasonable approach, but I would say that it
ought to be simple enough to convert e.g. '<' to < while you are
generating your XML stream, rather than having to maintain < in the
text storage. I think that's the sort of approach that most XML
generation takes; the escapes are after all XML artifacts.
Hmmm, but now you have me thinking. I could perhaps extend the
approach I am exploring with tags to also cover entity encodings.
Thus, the NSTextStorage would hold the "expanded" form of the entity
to be displayed, but the relevant range would also have an attribute
that said this was an entity and referenced the relevant entity
definition. Then, the problem would be to somehow tweak the NSTextView
so that, for multi-character entities, the point could not be
positioned within the entity itself, and that the entity was a unit in
terms of deleting or selecting it, etc. If munging glyph generation is
that complicated, perhaps this approach might be simpler?
The simplest way to modify this sort of text view behavior is via
delegate methods. These will let you control user selection, so that
e.g. certain ranges are never partially selected, and will also let you
control user changes, so that e.g. certain ranges are never partially
deleted. AddressBook does this sort of thing for some of its special
effects.
Douglas Davidson
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.