#1056: Text/character styles
-------------------------+--------------------------------------------------
Reporter: levon | Owner: nob...@…
Type: enhancement | Status: new
Priority: low | Milestone: 2.0.0
Component: general | Version: unspecified
Severity: minor | Resolution:
Keywords: infoneeded |
-------------------------+--------------------------------------------------
Changes (by uwestoehr):
* cc: lasgout...@…, lar...@…, leem...@…, j.spitzmuel...@…, rgh...@…
(removed)
* cc: lasgouttes, leeming, spitz, rgheck, uwestoehr (added)
* keywords: => infoneeded
Old description:
We really really need text styles.
LyX Styles UI
-------------
First off, I'm really a fan of not allowing the user direct access to
non-semantic mark-up. That means the user must create a style first,
which
implies we need to make basic styles easy to do in the UI. We should
strongly
encourage users to use semantic mark up.
Additionally, I think it is very important that we do not conflate the
idea of
paragraph styles and text (character) styles. They are different things
and
should be treated as such. Most word-processors get this wrong it seems.
A style will basically consist of the current lyxfont parameters. So a
style
will have a user-visible name, and consist of a set of these parameters.
Each
style parameter can be inherited. Some can be On/Off and others are an
enumeration. User will have access to an Edit Styles, something like :
http://movementarian.org/stylemockup.png
Now, obviously, the .lyx and .tex have to be portable. This means that
any
styles used in the .lyx file have to travel along with it, and in
practical
terms, this means in the file.
There's also the question of roundtripping, see below.
In addition to the per-document styles, we want to have "system" styles,
and
those associated with a particular document class. This kind of leaves
open the
question of how to disambiguate between same-named styles here.
So, basically, the user chooses a style from the combo box (though I have
no
idea where the hell we find room for it) and that applies the style to
the
current selection or at the current cursor position. This should work
fine for
e.g. the manuals, where stuff like :
File|>Insert
- -
will have the "Menu Item" (or even "Menu", "Menu Item") style, and the F,
and
I, would have the "Key Accelerator" style, or whatever. The latter style
would
have everything set to Inherited, except "Underlined" which would be set
to On.
In DocBook, there are pre-defined set of semantic markup styles (at
least, we
can model them as that), like<firstname>John</firstname> etc. For
DocBook,
it's not possible to define extra styles. Simple enough, we ship a system
style
file for DocBook classes containing the markup in the spec.
Erm, that's about it from the user's POV, I think.
LyX Styles Implementation
-------------------------
Currently we have a LyXFont class that is either .resolved() or not. An
unresolved font has some parameters set in "inherited" state. When it
comes to
drawing/metrics/output time, the font is resolved fully (for some reason
I
haven't worked out yet, this actually looks at previous paragraphs inside
nested lists etc. I'm sure someone can explain the need for that to me).
There's also "TOGGLE", but I think this is used only for transporting
changes
from the character dialog/font-free button, and so isn't relevant anyway.
We also have two warts : emph() and noun(), half-hearted styles
themselves.
I suggest we remove all non-realized stuff from the LyXFont class. It
will only
ever be used inside the metrics etc. code. Remove emph() noun() etc. too,
and
of course the existing font UI stuff.
Then we replace the paragraph's FontList or whatever it is with a
StyleList.
Styles are *always* unresolved but can be resolved in context in a
similar
fashion to the old lyxfont .realize(). Note I don't see a reason to let a
style
straddle a paragraph boundary.
We can use a similar approach we have already for defining layouts,
something
like :
Style "Function"
TypeWriter On
Italic Inherited
# all is Inherited by default
#Bold Inherited
EndStyle
I guess the layouts themselves would need to use Styles themselves, even
for
the uneditable labels etc. Perhaps a "Hidden" parameter ?
in addition we provide a Preamble, Begin, and End, to allow overriding of
the
default code that generates open/close stuff in the .tex output. The
default
code would make a \newcommand in the preamble, then use that. It would
still
handle "Italic Off" properly, since it would see Italic is not set in the
style
after the current one (that did have italic on), then close that.
This would also make the docbook stuff work I think :
Style "First Name"
Begin<firstname>
End</firstname>
EndStyle
Styles are stored by the Buffer. Now, the .lyx file really needs to store
new style definition, since we sooo do not want the user to have to jump
through hoops just to send his colleague a file. We don't have a
validate()
for .lyx, so I think we'll need that :(.
We can reasonably assume, though, that the remote end has character
styles for
the document class, where appropriate (eg. docbook<firstname> will be in
every docbook layout definition anyway).
The last wrinkle is allowing ~/.lyx/mygeneralstyles, but that's pretty
simple,
if one gets used, then it's added to the list of styles in the Buffer
class,
and exported.
For roundtripping -- dunno. Perhaps there is some robust scheme to re-
detect
the \newcommands and interpret them as styles....
New description:
We really really need text styles.
LyX Styles UI
-------------
First off, I'm really a fan of not allowing the user direct access to
non-semantic mark-up. That means the user must create a style first, which
implies we need to make basic styles easy to do in the UI. We should
strongly
encourage users to use semantic mark up.
Additionally, I think it is very important that we do not conflate the
idea of
paragraph styles and text (character) styles. They are different things
and
should be treated as such. Most word-processors get this wrong it seems.
A style will basically consist of the current lyxfont parameters. So a
style
will have a user-visible name, and consist of a set of these parameters.
Each
style parameter can be inherited. Some can be On/Off and others are an
enumeration. User will have access to an Edit Styles, something like :
http://movementarian.org/stylemockup.png
Now, obviously, the .lyx and .tex have to be portable. This means that any
styles used in the .lyx file have to travel along with it, and in
practical
terms, this means in the file.
There's also the question of roundtripping, see below.
In addition to the per-document styles, we want to have "system" styles,
and
those associated with a particular document class. This kind of leaves
open the
question of how to disambiguate between same-named styles here.
So, basically, the user chooses a style from the combo box (though I have
no
idea where the hell we find room for it) and that applies the style to the
current selection or at the current cursor position. This should work fine
for
e.g. the manuals, where stuff like :
File|>Insert
- -
will have the "Menu Item" (or even "Menu", "Menu Item") style, and the F,
and
I, would have the "Key Accelerator" style, or whatever. The latter style
would
have everything set to Inherited, except "Underlined" which would be set
to On.
In DocBook, there are pre-defined set of semantic markup styles (at least,
we
can model them as that), like<firstname>John</firstname> etc. For
DocBook,
it's not possible to define extra styles. Simple enough, we ship a system
style
file for DocBook classes containing the markup in the spec.
Erm, that's about it from the user's POV, I think.
LyX Styles Implementation
-------------------------
Currently we have a LyXFont class that is either .resolved() or not. An
unresolved font has some parameters set in "inherited" state. When it
comes to
drawing/metrics/output time, the font is resolved fully (for some reason I
haven't worked out yet, this actually looks at previous paragraphs inside
nested lists etc. I'm sure someone can explain the need for that to me).
There's also "TOGGLE", but I think this is used only for transporting
changes
from the character dialog/font-free button, and so isn't relevant anyway.
We also have two warts : emph() and noun(), half-hearted styles
themselves.
I suggest we remove all non-realized stuff from the LyXFont class. It will
only
ever be used inside the metrics etc. code. Remove emph() noun() etc. too,
and
of course the existing font UI stuff.
Then we replace the paragraph's FontList or whatever it is with a
StyleList.
Styles are *always* unresolved but can be resolved in context in a similar
fashion to the old lyxfont .realize(). Note I don't see a reason to let a
style
straddle a paragraph boundary.
We can use a similar approach we have already for defining layouts,
something
like :
Style "Function"
TypeWriter On
Italic Inherited
# all is Inherited by default
#Bold Inherited
EndStyle
I guess the layouts themselves would need to use Styles themselves, even
for
the uneditable labels etc. Perhaps a "Hidden" parameter ?
in addition we provide a Preamble, Begin, and End, to allow overriding of
the
default code that generates open/close stuff in the .tex output. The
default
code would make a \newcommand in the preamble, then use that. It would
still
handle "Italic Off" properly, since it would see Italic is not set in the
style
after the current one (that did have italic on), then close that.
This would also make the docbook stuff work I think :
Style "First Name"
Begin<firstname>
End</firstname>
EndStyle
Styles are stored by the Buffer. Now, the .lyx file really needs to store
new style definition, since we sooo do not want the user to have to jump
through hoops just to send his colleague a file. We don't have a
validate()
for .lyx, so I think we'll need that :(.
We can reasonably assume, though, that the remote end has character styles
for
the document class, where appropriate (eg. docbook<firstname> will be in
every docbook layout definition anyway).
The last wrinkle is allowing ~/.lyx/mygeneralstyles, but that's pretty
simple,
if one gets used, then it's added to the list of styles in the Buffer
class,
and exported.
For roundtripping -- dunno. Perhaps there is some robust scheme to re-
detect
the \newcommands and interpret them as styles....
--
Comment:
Since LyX 1.6.0 character styles can be defined in modules. The
Customization manual uses character styles extensively for example. In my
opinion this bug can be marked fixed.
Do you agree?
