Also (assuming we map to normal Abiword styles), should I apply
properties exactly from Word or just the differences from the style?
If I just did differences (say the font size was different),
but the Abiword style mapped to from the Word style had a
different font, then Abiword would render it with a font
differently than Word.
If I applied exact Word properties, then setting the style in Abiword
is mostly pointless (since they're always overriden), except possibly for
preserving information for export.
2. additional property support (but not necessarily implementations)
It would be nice to have the internals recognize the properties we
plan to add, but haven't yet, so that importer/exporters can go ahead
and implement those so 1) it will be supported immediately when Abiword
can display the property and 2) moving documents through Abiword is less
lossy.
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.
3. Spell checking
I have local modifications to ispell reintegrating its simple word
suggestion code. My plan was to make use of this in the dialog
and possibly in a right-click menu on squiggled words.
That and the dialog ought to hit the tree tomorrow.
Also, I've looked through aspell, and the trick to it's good suggestions
is a combination of ispell's method and metaphones. It doesn't look too
hard to integrate, but the metaphone transformations will be language
dependent. We could probably rig up an external ruleset which would
allow localizers to implement there a new language for spell check.
And, we should have a way to preserve "ignore all" words for at least
a session (possibly store in the file, too?), and the stripped ispell
should be expanded to handle user-defined dictionaries.
As these get done, a generic spelling interface should get built, which
could then be replaced by another spelling checker.
4. Fields
Expand time to time/date, with multiple formats?
ie. time: 12:MM:SS AM/PM, 24:MM:SS (optional seconds, too?)
date: MM/DD/YY(YY); DD/MM/YY(YY); Sep(tember) 19, 1999; 19 Sep 1999
where either time, date, or both are selected for display.
Should the time/date be optionally stored, rather than just the current
time/date. That combined with an option in dialog (and right click menu)
to update to current time/date might be useful (as a simple timestamp).
5. Symbols
Just to clarify-- this dialog lets the user select a font and then
shows them a table of every character in that font, right? Or should it
just be a Unicode character browser (assuming we have an adequate font)?
justin