On Sun, Oct 07, 2007 at 02:26:48AM +0200, Dov Feldstern wrote:
> Hi!
>
> As mentioned in a separate thread, I have a suggestion for the charstyles
> situation, but it's important for me to first of all explain another issue
> which bothers me with the current implementation of charstyles. If I am
> correct, then understanding my problem will help to understand some of the
> choices I make for that solution. But I'm doing this in a separate thread,
> to try and keep things manageable (which may or may not succeed).
>
> So first, let me just say that I'm not very familiar with the charstyles
> implementation, so please correct me if I'm wrong.
>
> AFAIU, charstyle insets "work" (i.e., determine the font attributes as they
> would appear in the latex output), in the following manner: when such an
> inset is reached, and say it's a "noun" inset, then the command for starting
> the "noun" command is output, followed by the text of the inset, followed by
> the command for closing "noun".
Yes, \noun{ and } respectively.
> 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.
> 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.
> 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).
> Does this sound reasonable?
>
> Dov
- Martin
