[xlwt] (PRE-ALPHA) easyxf -- an easy way of creating an XF (aka "style")
John Machin
Example of creating 2 XFs, using the current method:
f = xlwt.Font()
f.bold = True
a = xlwt.Alignment()
a.wrap = True
a.vert = a.VERT_CENTER
a.horz = a.HORZ_CENTER
heading_xf = xlwt.XFStyle()
heading_xf.font = f
heading_xf.alignment = a
f = xlwt.Font()
f.italic = True
p = xlwt.Pattern()
p.pattern = p.SOLID_PATTERN
p.pattern_fore_colour = 0x16
money_xf = xlwt.XFStyle()
money_xf.font = f;
money_xf.pattern = p
money_xf.num_format_str = '$#,##0.00'
Using easyxf method:
ezxf = xlwt.easyxf
heading_xf = ezxf(
'font: bold on; align: wrap yes, vert centre, horiz center')
money_xf = ezxf(
'font: italic true; pattern: pattern solid, fore_colour grey25',
num_format_str='$#,##0.00')
Ease-of-use features:
* case doesn't matter
* colour/color centre/center grey/gray doesn't matter
* other synonyms such as horz/horiz
* boolean 1/yes/on/true 0/no/off/false
* names for colours
* minimal punctuation
* too-big or invalid values are checked and rejected immediately
Current state: Appears to be working. I would appreciate comments and
suggestions, especially from anyone who has existing code with heavy use
of XFs/styles and is willing to try out easyxf.
I have uploaded two files to the file area of this group:
* a demonstration script easyxf_demo.py
* a pre-alpha source file easyxf.py -- this is *not* integrated into
xlwt; to test it, you will use your existing xlwt, import easyxf, and
use easyxf.easyxf(...) to create XFs (see the demo script).
* Docs: nil. Check out the xf_dict structure in easyxf.py and follow
your nose.
Cheers,
John
van
I tested easyxf.py on one of my apps and it worked perfectly.
I was really happy to see this code because I had been annoyed at how
much code it took to create styles and I hadn't come up with any great
ideas on how to simplify.
Your idea of making something like CSS is great, although I confess
while writing the calls to easyxf files I kept trying to write it as
if it was actually CSS :)
There is probably too much of a mis-match to actually change it to
some kind of CSS subset, but maybe we can have one call like "loadxf"
that reads all the styles from a file thus moving all "presentation"
stuff out of the python code? In place of CSS "selectors" would be
the style names that could be passed as strings (instead of python
object name) to the xlwt cell write functions. This would also mean
making "num_format_str" a style attribute instead of parameter.
Thanks for the great work,
Van
John Machin
> Hi John,
>
> I tested easyxf.py on one of my apps and it worked perfectly.
That's good to hear. Thanks for trying it out. Care to publish some
before/after code as examples?
>
> I was really happy to see this code because I had been annoyed at how
> much code it took to create styles and I hadn't come up with any great
> ideas on how to simplify.
>
> Your idea of making something like CSS is great, although I confess
> while writing the calls to easyxf files I kept trying to write it as
> if it was actually CSS :)
I'll meet you part way; allowing "-" where "_" is expected would save
wear and tear on the shift key. For example "top-color",
"centre-across-selection".
>
> There is probably too much of a mis-match to actually change it to
> some kind of CSS subset,
MS have bludgeoned it into CSS; check out the result of "Save as Web
Page ..." in Excel. For example:
.xl352845
{padding-top:1px;
padding-right:1px;
padding-left:1px;
mso-ignore:padding;
color:windowtext;
font-size:10.0pt;
font-weight:400;
font-style:normal;
text-decoration:none;
font-family:"Times New Roman", serif;
mso-font-charset:0;
mso-number-format:"d\/mm\/yyyy\;\@";
text-align:general;
vertical-align:bottom;
mso-background-source:auto;
mso-pattern:auto;
white-space:nowrap;}
I think the most ardent CSS fan would soon get sick of typing "mso-" all
the time :-)
> but maybe we can have one call like "loadxf"
> that reads all the styles from a file thus moving all "presentation"
> stuff out of the python code? In place of CSS "selectors" would be
> the style names that could be passed as strings (instead of python
> object name) to the xlwt cell write functions.
Yes, maybe we could; would you like to have a go at it?
> This would also mean
> making "num_format_str" a style attribute instead of parameter.
num_format_str as a separate paramater is an expedient/kludge/cop-out;
(1) the num_format_str is odd-man-out in that it doesn't fit the
two-level hierarchy of other parts of an XF; I'd need to make a special
case for "num_format_str: #,##0.00; font: etc etc" and (2) the caller
would have to escape the format (similar to
mso-number-format:"d\/mm\/yyyy\;\@"; above) and I'd have to unescape it.
Which of the following do you think the caller would prefer?
(a) ezxf(r"num_format str: dd/mm/yyyy\;@; font: etc")
(b) ezxf(
"num_format_str: %s; font: etc" % easyxf_escape("dd/mm/yyyy;@")
)
(c) ezxf("font: etc", "dd/mm/yyyy;@")
Suggestions welcome.
Cheers,
John