Jean-Marc Lasgouttes wrote:
Mael Hilléreau <[EMAIL PROTECTED]> writes:
Of course, but as it is a presentation issue, it can be fixed later.
I would rather advocate to use character properties in current code
and switch to insets-as-character-properties later. Any text longer
than one of two words put in such an inset will be ugly.
JMarc, I still tend to agree with you on this point. However, I think my
aborted patch from last night clearly demonstrates that hijacking Font
is *not* a very good idea. Do you have any other idea of how this could
be done in a character-based way?
What would be nice -- and maybe useful for other situations, too ---
would be to have some generalized mechanism for applying attributes to a
given region of text. I would like an API similar to this:
*) Set/GetAttribute(attribute, pos)
for a pre-determined (but extensible) set of attributes.
The implementation could be through a mechanism similar to the FontSpan,
or some other implementation, if that's not considered acceptable. (I'm
not really familiar with the FontSpan mechanism, I just know it's there.
How do developers feel about it? Is it robust? How is it in terms of
efficiency? Memory consumption? ...)
Mael --- the reason that I think a character-based solution might be
useful, even though spell-checking is word-based and not character-base,
is that at the conceptual level, what I want to do is to mark regions of
text and give them some attribute. Since the "atoms" of the text are
characters, then demarcating the regions text at the character-level
seems to be the most general approach. Certainly in some applications
--- like spell-checking --- this is more fine-grained than necessary,
but I don't see any drawback in that, as long as the behavior is well
defined in the case of a "semantic atom" (in our case, a word) which is
only partly contained in a region.
Dov
