Martin Vermeer wrote:
On Sun, Oct 07, 2007 at 02:26:48AM +0200, Dov Feldstern wrote:
The problem with this is that it's a *new* method for determining the font
attributes, which comes alongside the already existing method
(character-attributes). And as complicated as character-attributes are,
mixing two different methods for control fonts appearance is only going to
make things more complicated. Firstly, just because every time someone now
wants to somehow interact with font attributes, now two different "places"
have to be checked in order to determine the current font attributes at a
given position (1. what are the character attributes at this position? 2. is
this position inside an inset which could affect font attributes? And note
that the answer to (2) is not trivial, even if it's the *only* method being
used). Secondly, this can lead to all kinds of situations of
over-definition: what if the inset determines one thing, but font-attributes
determine another?
What the inset does, is 'very' clear.
Yes, you're right. But nonetheless, it is a *new*, *additional* method.
So we're now going to have two methods for this. However, I'm starting
to appreciate this approach, relative to the character attributes based
one. Of course, ranges could use this approach, too...
Or, what if you have two "emph" insets one inside the
other --- using the current implementation, I believe you'd get something
like "\emph{bla bla \emph{bla bla}}", which is probably *not* what we want.
(To be sure, with the current character attributes implementation, I'm not
sure that we'd get what we want, either: we'd probably get "\emph{bla bla
bla bla}", which is at least better, IMO. What we'd really want might depend
on the specific charstyles being used, but I don't see any good way to even
recognize this situation using insets.
Emph handles this situation on the keyboard input level by
toggling. Which indeed is a good reason to keep it that way
i.e., the range approach.
Using character attributes / ranges I
think it would be easier to recognize this situation). There is no good way
to deal with these kinds of situations using the current mechanism.
And as far as I understand, we all agree that character attributes are not
going to be totally replaced by insets, so they're still going to be around.
Also note that the fact that we ignore font attributes inside these insets
is forcing us to perform additional work which hides this fact from the
user: getDrawFont, draw --- we explicitly set the font used for drawing,
because the "true" font (as would be determined by the character attributes)
may not be what we want it to be.
We use getDrawFont etc. only if we do _not_ want to inherit
the surrounding font, like for ERT, footnote, etc. A self
contained design choice.
If I understand correctly, the current implementation of InsetFlex
*always* calls getDrawFont, doesn't it? So every CharStyle inset is
using an explicitly set font, and not the one that would be derived from
the content's character attributes?
For these reasons, I would prefer to see charstyle-insets work as follows:
the inset should make sure that inside it, the current_font is set to the
font settings required by this charstyle; and maybe also make sure that the
current_font can't be changed. Beyond that, no extra work would be needed:
no special output methods (i.e., no "latex command" necessary in the layout,
no special drawing methods --- all these would be handled by the already
existing character attributes mechanisms. But the UI would still be that of
an inset.
I am not sure I understand you, but we're pretty much already
there. We only need an inset's draw or latex commands if
the inset does something above and beyond drawing / outputting
the text it contains. Otherwise not. Methinks you really haven't
looked much at the inset mechanism (which you readily admit).
I'm looking, for example, at a "noun" charstyle inset: it would be
setting the font to something *explicit* (as defined in the mini-layout
for noun: Smallcaps); the latex output will contain additions relative
to just the contents of the inset, namely a "\noun{" and "}" as you
explained above. So, this is what I'm calling a second mechanism for
charstyles, alongside the already existing character attributes: it
*would* have been possible to not have any of these explicit settings;
and rather, to just make sure that the text inside the inset has the
"noun" character attribute set. That way, you would still have the inset
UI, but the charstyles would be handled using the same mechanism used
for font attributes everywhere else in the text. That's what I was
trying to say.
So, we *are* now going to be having two separate font attributes
mechanisms: the "old" character attributes, and the "new" mini-layouts.
I think that ultimately we should strive to have only one mechanism,
though I'm starting to think that maybe the mini-layouts could be that
one mechanism...
Dov
