Richard Heck wrote:
Dov Feldstern wrote:
I agree very much with what JMarc has been saying about this issue:
although I like very much the idea of character styles / logical
markup, I don't think that insets are the right paradigm for
implementing this.
But there's a point JMarc made along the way which isn't accounted here,
and it needs to be, namely: There are two questions here: how charstyles
(say) are implemented in the code, and how they appear to the user. The
issues that have been raised have to do with how charstyles appear to
the user. Whether they exist as insets in LyX isn't critical from that
point of view.
Certainly those are two different issues, I think that my arguments are
relevant to both of them, and I've given examples from both the UI and
the internal structure. Furthermore --- and this is one of the core
issues here --- my claim is that the internal structure should as
closely as possible match the UI / appearance to the user. Of course we
*could* use insets internally, and make them appear to the user as if
they're character ranges --- but why? To me, the fact that we need to
change the UI so much just indicates that we're starting with the wrong
concept, and trying to force the properties of a different concept onto
it. If the real concept that we're trying to achieve is "ranges" (which
I think it is), then we should implement ranges in a general, clean way,
not co-opt insets to allow them to behave also like ranges. That will
hurt both insets and ranges in the long run.
There's also the question how all of this gets written to a LyX file.
Especially once we're doing XML, it'll be essential that everything be
properly nested (unless each character is supposed to be written with
all of its associated formatting information, which is insane). Insets
are a natural correlate to that, because they nest. This does NOT mean
that they have to appear to the user as insets, only that the underlying
data structure nests properly.
Correct. Overlapping ranges are a real problem, which I am especially
aware of being a Bidi user, where questions of "which is the outer range
and which is the inner range" could actually change the order of the
words as they appear on the page.
But solving the problem by saying:from now on you're not *allowed* to
have overlapping ranges is not a good solution (though it *will* solve
our programming problems in this respect). Overlapping ranges are not
"semantically wrong", by any means (TEI, e.g., is aware of this, though
I'm not sure they have a good solution; see
http://www.tei-c.org/P4X/NH.html). What we should be doing is trying to
solve this problem, not hiding it by making it illegal.
I have an idea of how to deal with this, but it is too long for this
message ;) ... I will send it separately.
Let me also add this point. One of my complaints about fonts and the
like as they currently exist is that it can be very hard to tell where
they begin and where they end. (Try emphasizing some text and then
italicizing something in the middle of it.) Even if the boundaries of
the inset are not ordinarily shown, it'd be nice to have them be
showABLE, so that you can answer this kind of question without having to
View>Source.
I fully agree with this. And again, I think this would be very easy to
implement with character attributes. We already have a (very basic)
mechanism for this, in the form of the "infamous blue underline" for
foreign languages. This could be extended to allow additional capabilities:
*) allow the user to toggle the underline on/off on a per-range basis
(e.g., when the cursor is in an inset, allow toggling the ranges of that
specific inset)
*) allow special markers at the beginning/end of ranges, if that's
what we want, instead of / in addition to an underline.
The point is, I think that adding "boundary discovery" capabilities to a
character-attribute range is probably much more straightforward than
making insets behave like character ranges.
Richard
Dov
