Sounds like a great idea for exactly the reasons you describe.
Please feel free to drive this from the import side. As you identify Word
properties which map directly onto a specific CSS equivalent, by all means
start recognizing and importing them that way.
I believe that Jeff's current properties mechanism will silently pass them
through unchanged so that they're available for lossless roundtrip
import/export.
Or, better yet, we can add a minimal level of recognition for those
properties inside AbiWord by adding them to the existing enumerations at the
following four spots:
1. abi/src/text/ptbl/xp/pp_Property.cpp
----------------------------------------
This table is the last-resort spot for hardwired defaults so property
lookups never fail.
2. abi/src/text/ptbl/xp/pt_PT_Styles.cpp
-----------------------------------------
Most property lookups terminate in the Normal style definition instead,
which is loaded as a string in pt_PieceTable::_loadBuiltinStyles().
3. abi/src/text/fmt/xp/fv_View.cpp
-----------------------------------
The UI code makes calls into the following set of functions,
FV_View::getCharFormat(),
FV_View::getBlockFormat(), and
FV_View::getSectionFormat(),
to access the current set of properties which are consistent across the
*entire* selection. For the pruning algorithm to work properly, each
newly-defined property needs to be added to the enumeration in the
appropriate function. (See the code for details.)
4. abi/docs/AbiWord_DocumentFormat.abw
---------------------------------------
For completeness' sake, of course, the newly-defined property should also
get added here, with a big red TODO note which makes clear that it's not
implemented in the formatter yet. :-)
> from the CSS2 spec, here are some potential ones:
> font-style: oblique
> font-variant: small-caps (same as drop caps, right?)
> font-weight: 100, 200, 300, 400, 500, 600, 700, 800, 900
> word-spacing:
> letter-spacing:
> text-decoration: double line-through (not CSS, but Word has this)
> overline
> more underlines (double, dotted, dashed,
> invisible [for Word], etc)
> blink?
> vertical-align: sub, super (subscript, superscript)
> top, bottom, middle, baseline, etc?
>
> padding-{top,bottom,right,left}: padding from border
> border-{top,bottom,right,left}-width:
> border-{tblr}-color:
> border-{tblr}-style: none, dotted, dashed, solid, double, groove,
> ridge, inset, outset
> or: border-{top,bottom,left,right}: width style color
>
> for text flow around objects, probably need more values
> float: left, right, none
> clear: left, right, both, none
>
> list-style-position: inside, outside
> list-style-type: disc, circle, square, decimal, lower-roman,
> upper-roman, lower-alpha, upper-alpha, none
>
> text-animation: vegas lights, marching ants, marching red ants, etc ;)
>
> Probably some others I can't remember at the moment.
>
> Anyway, I thought I'd bring this up so we can decide what the attributes
> will be for various unimplemented features.
You've clearly looked at this more carefully than any of us has recently, so
I'm willing to trust your judgement on what's what here.
The thing to watch out for are properties which *don't* directly map between
CSS and Word's implemented behavior. For example, lists and tables in HTML
have never really worked the way Word does, so the formatting models may be
different enough for some properties that using the same names may be more
confusing than helpful.
As you'll note from our existing property set, we've tried to be clear on
when we've deliberately diverged from the existing CSS formatting model.
Blurring the line here would be a Bad Idea.
Having made that general warning, don't worry about it much. Once we get
down to the details of specific properties, it's usually not hard to figure
out what to do.
Paul