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: Kaelin Colclasure <email@hidden>
- Date: Mon, 5 Jan 2004 15:22:53 -0800
Hi Doug,
On Jan 5, 2004, at 2:16 PM, Douglas Davidson wrote:
On Dec 31, 2003, at 9:08 PM, Kaelin Colclasure wrote:
1) I want to embed some special, hidden control characters into the
character stream contained in an NSTextStorage.
a) These characters I designate as special should normally not show
up
as visible glyphs at all. Think tabs, but without any effect on the
position of the next character / glyph position.
b) I do want insertion point positioning in the NSTextView to allow
putting the insertion point between two of these invisible control
characters.
c) It would be nice if I could also have a toggle to "Show
Invisibles"
-- but this is not essential.
It's going to be a bit of a trick for your users to position the
insertion point between these invisible zero-width glyphs, but you
should be able to do this if you really want.
The UI I am playing around with uses a separate view to display
precisely where in the structured hierarchy of the document the point
is positioned. Right now it is a separate NSTextView that displays
something like:
<document> -> <chapter> -> <para> -> text -> point
This is supposed to be telling you that the point is currently in the
middle of some text content in a <para> tag, that the <para> is nested
inside a <chapter>, etc. The idea of having the control characters as
place-holders for the tags is explicitly so that "normal" cursor
motions can position the point in between tags, and yet the tags are
only visible in the "structure" view and not in the "text" view.
This is very similar to how the venerable WordPerfect handled
formatting characters, IIRC. I haven't decided myself if I like it for
XML markup, but it's the simpler of two ideas I want to try out.
2) I want to have certain escape sequences in the character stream
mapped into a single character glyph.
a) For example, "<" should map to the glyph for '<'. (You can see
where this would be useful.)
b) Again, the ability to toggle this off and invalidate / re-render
the NSTextView would be nice, but not essential.
One possibility for both (1) and (2) would be to have two
representations of your text. In your NSTextStorage, you can put a
representation suitable for display using the text system--for
example, your invisible control characters could be represented as
something in Unicode that is zero-width, and your < as <. You can
also have an additional representation, either maintained constantly
or created as needed, that uses your control characters and <.
Maintaining the correspondence between the two can be done in a
variety of ways. There do not necessarily need to be two separate
copies; a custom NSTextStorage, for example, could maintain one
representation in memory but also present the other as needed. The
toggling business then is mainly a matter of altering the
representation presented to the text system.
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.)
In short, now that I've started down the path of one in-memory
representation of the document, I'm loathe to let go of it easily. :-)
If you really need to have a single representation stored in an
NSTextStorage, it is possible to override glyph generation using
NSGlyphGenerator. You may also need to override font fixing in an
NSTextStorage subclass to make sure that font fixing uses the actual
characters you want to represent. If you need to represent multiple
characters by a single glyph, it is advisable to insert sufficient
padding in the form of NSNullGlyphs immediately after the real glyph
to keep a one-to-one correspondence between characters and glyphs.
However, I would recommend investigating the two-representation
approach first; glyph generation is a tricky business.
Yes, that's exactly the impression I formed while trying to make heads
or tails of the relevant APIs. :-) I would love to see a
message-sequence diagram that explained how all of the players interact
to map characters into glyphs...
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?
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.