Bug in row.height ?
ShadowHywind
using worksheet.row(0).height = 600
and the row stays the same. However if i try changing any other row it
works. Any thoughts?
John Machin
1. If you doing EXACTLY the same to row 0 and "any other row", and one
works and the the other doesn't, that's a bug. Please post a minimal
script that demonstrates this problem.
2. Have you read the tutorial available from http://www.python-excel.org/ ?
3. Here are the results of some experiments I did earlier this year:
"""
xlwt just sets attributes in the Row objects and hopes for the best.
There is no if/but/maybe/default/override behaviour at all.
Relevant attributes are:
height -- default is 255 twips [Remember: 20 twips per point, 72 points
per inch, 25.4 mm per inch]
has_default_height -- boolean
height_mismatch -- boolean
has_default_height is probably only useful if a row is hidden and/or
collapsed [which I haven't explored]. I think it means this: when the
row is unhidden/uncollapsed, restore its visible height to
(row.height if row.has_default_height else "some calculated or
global-default value")
has_default_height is definitely NOT A GOOD IDEA otherwise. If
has_default_height and height_mismatch are both true, Excel goes off the
planet (row height in excess of window height, need magn=25% to see
what's happening!!).
Assuming hidden=0, collapsed=0, has_default_height=0, as far as I can
tell the following rules are applied:
A. If height_mismatch is true, Excel will use the requested height. In
other words, font doesn't match requested height, so go with the
requested height. If the font is small, you get space. If the font is
large, you get chopped characters.
B. Else: (1) Excel will calculate a row height high enough to accomodate
the tallest font used in the row. (2) If any cell in the row is styled
with "alignment: wrap on" and the text is too long to fit in the column
width, Excel will calculate a row height sufficient to accomodate
wrapping all such cells within their column width.
If you save the file with Excel, it will set the Row.height to the value
that it actually used (requested for rule A, calculated for rule B).
"""
I have uploaded a script (row_height_options.py) to the group's file
section. It demonstrates most of the above.
Cheers,
John
John Yeung
have saved myself hours of painful BIFF-documentation-reading and
bit-by-bit (byte-reversed!) file inspection. (More comments below.)
On Mon, Dec 28, 2009 at 6:18 PM, John Machin <sjma...@lexicon.net> wrote:
> Assuming hidden=0, collapsed=0, has_default_height=0, as far as I can
> tell the following rules are applied:
>
> A. If height_mismatch is true, Excel will use the requested height. In
> other words, font doesn't match requested height, so go with the
> requested height. If the font is small, you get space. If the font is
> large, you get chopped characters.
>
> B. Else: (1) Excel will calculate a row height high enough to accomodate
> the tallest font used in the row. (2) If any cell in the row is styled
> with "alignment: wrap on" and the text is too long to fit in the column
> width, Excel will calculate a row height sufficient to accomodate
> wrapping all such cells within their column width.
Given behavior A (which I independently discovered through much effort
earlier today), I suggest the "tutorial" (de facto manual, available
at python-excel.org as python-excel.pdf) be updated, because it
currently says
"Do not be fooled by the height attribute of the Row class, it does
nothing. Specify a style on the row and set its font height attribute
instead."
The height attribute certainly does more than nothing when combined
with height_mismatch. The font-based solution has its merits, but
isn't a perfect substitute for being able to pick a specific row
height.
As a vague idea (weaker than a suggestion), it might be easier, or at
least less cryptic, to add a Row.set_height method and point people to
it in the tutorial, than to explain in the tutorial that they have to
set both height and height_mismatch.
Oh, it might be useful to mention that the reason I was investigating
setting the row height in the first place was because I couldn't coax
Excel into doing automatic height adjustment to accommodate wrapped
text in merged cells. (As far as I can tell, this is a bug in Excel
2000 and doesn't imply any deficiency in xlwt.)
John Y.
John Machin
> If only I had read this more carefully when I first opened it, I could
> have saved myself hours of painful BIFF-documentation-reading and
> bit-by-bit (byte-reversed!) file inspection. (More comments below.)
A wise person once said: You can lead a horse to water, tie a brick to
its nose, and kick it in the fundament with a size 12 Doc but you can't
make it drink :-)
>
> On Mon, Dec 28, 2009 at 6:18 PM, John Machin <sjma...@lexicon.net> wrote:
>> Assuming hidden=0, collapsed=0, has_default_height=0, as far as I can
>> tell the following rules are applied:
>>
>> A. If height_mismatch is true, Excel will use the requested height. In
>> other words, font doesn't match requested height, so go with the
>> requested height. If the font is small, you get space. If the font is
>> large, you get chopped characters.
>>
>> B. Else: (1) Excel will calculate a row height high enough to accomodate
>> the tallest font used in the row. (2) If any cell in the row is styled
>> with "alignment: wrap on" and the text is too long to fit in the column
>> width, Excel will calculate a row height sufficient to accomodate
>> wrapping all such cells within their column width.
>
> Given behavior A (which I independently discovered through much effort
> earlier today), I suggest the "tutorial" (de facto manual, available
> at python-excel.org as python-excel.pdf) be updated, because it
> currently says
>
> "Do not be fooled by the height attribute of the Row class, it does
> nothing. Specify a style on the row and set its font height attribute
> instead."
That's a very sound suggestion.
> The height attribute certainly does more than nothing when combined
> with height_mismatch. The font-based solution has its merits, but
> isn't a perfect substitute for being able to pick a specific row
> height.
>
> As a vague idea (weaker than a suggestion), it might be easier, or at
> least less cryptic, to add a Row.set_height method and point people to
> it in the tutorial, than to explain in the tutorial that they have to
> set both height and height_mismatch.
Your vague idea covers behaviour A, leaving the tutorial to explain that
if behaviour B is required, they must not set height_mismatch to True
etc etc. Your proposed method would do nothing else but set the height
attribute to the arg value and setting height_mismatch to 1. Do you plan
on not documenting why height_mismatch is set to 1? Perhaps you'd like
to explain what you mean by "easier" and "less cryptic".
> Oh, it might be useful to mention that the reason I was investigating
> setting the row height in the first place was because I couldn't coax
> Excel into doing automatic height adjustment to accommodate wrapped
> text in merged cells.
I presume you didn't read far enough into that cryptic message to get to
the mention of the demo script :-(
> (As far as I can tell, this is a bug in Excel
> 2000 and doesn't imply any deficiency in xlwt.)
Can you produce the required behaviour using the Excel UI?
Cheers,
John
John Yeung
>> As a vague idea (weaker than a suggestion), it might be easier, or at
>> least less cryptic, to add a Row.set_height method and point people to
>> it in the tutorial, than to explain in the tutorial that they have to
>> set both height and height_mismatch.
>
> Your vague idea covers behaviour A, leaving the tutorial to explain that
> if behaviour B is required, they must not set height_mismatch to True
> etc etc.
Yeah, pretty much. (I suppose an admonition not to expect behavior B
if you use the set_height method is part of the etc.)
> Your proposed method would do nothing else but set the height
> attribute to the arg value and setting height_mismatch to 1. Do
> you plan on not documenting why height_mismatch is set to 1?
> Perhaps you'd like to explain what you mean by "easier" and
> "less cryptic".
I was thinking (and keep in mind I've not proven myself smarter than a
bricked and kicked horse) that it would take less verbiage (easier)
and be more readily understandable (less cryptic) to the uninitiated
reader for the tutorial to say "set the row height to a fixed number
of twips using Row.set_height" than to even mention height_mismatch at
all. I'll admit I haven't given much thought to cases where it would
be nice to have easy access to height_mismatch other than to set a
fixed row height. I doubt I would miss it if this property were not
exposed in the API at all, but then I'm sure that would break someone
else's code.
I would document the height setter method, including why it's setting
height_mismatch, in the source code (presumably in Row.py); that would
be plenty clear enough for spelunkers but out of the way for less
curious get-the-job-done types.
It probably also goes without saying that it's both easier and less
cryptic for the xlwt user to write
ws.row(r).set_height(h)
than
ws.row(r).height = h
ws.row(r).height_mismatch = True # needed to force height setting
or to bundle away the latter in his own function or module. Or to
futz with his xlwt installation so that he doesn't need to
(thereafter) include his own function or module.
>> Oh, it might be useful to mention that the reason I was investigating
>> setting the row height in the first place was because I couldn't coax
>> Excel into doing automatic height adjustment to accommodate wrapped
>> text in merged cells.
>
> I presume you didn't read far enough into that cryptic message
> to get to the mention of the demo script :-(
I actually didn't find your message cryptic at all, once I was in the
proper frame of mind to pay attention to it. I wasn't in the proper
frame of mind initially because I was thinking to myself that I wasn't
having the problem that the OP was having, so it wouldn't do me much
good to read on. (I guess at the time I was being a less-curious,
get-the-job-done type.)
Once I did read on, I did see the mention of the demo script, and I
even read it, but it is not easy for me to try it out on this
computer. I will give it a go tomorrow.
Also, I'm sure you're referring to the write_merge toward the end of
the script, but I have come to not use write_merge, because I haven't
had success with it and borders. Instead, I've got my own
Frankenmerge that better serves my needs (but for all I know is crap
for anyone else):
def merge(sheet, r1, c1, r2, c2, label, style):
sheet.merge(r1, r2, c1, c2)
for row in range(r1, r2 + 1):
for col in range(c1, c2 + 1):
if row in (r1, r2) or col in (c1, c2):
if (row, col) == (r1, c1):
value = label
else:
value = None
sheet.write(row, col, value, style)
>> (As far as I can tell, this is a bug in Excel
>> 2000 and doesn't imply any deficiency in xlwt.)
>
> Can you produce the required behaviour using the Excel UI?
I can't get the Excel UI to automatically accommodate wrapped text in
merged cells, which is why I figured it was an Excel bug, and not a
problem with xlwt. However, it is also entirely possible that my
Excel-fu is simply insufficient.
John Y.
John Yeung
> Once I did read on, I did see the mention of the demo script, and I
> even read it, but it is not easy for me to try it out on this
> computer. I will give it a go tomorrow.
I did run the script and opened the resulting file in Excel, and it
turned out as expected. Rows did not automatically increase in height
to accommodate wrapped text within merged cells. As far as I had the
patience to examine, row height otherwise behaved as described earlier
in this thread.
John Y.
Avi Kapoor
John Yeung
> Has this issue been re-solved - I'm still noticing the same error ?
John Machin and I hashed out the behavior of the various settings, and
from what I have experienced, it is all Working As Designed. I have
not noticed any *bugs* and ShadowHywind never provided any conclusive
evidence of any bug.
If you believe you are experiencing a bug, show us some *complete*
code which we can use to reproduce the bug.
John Y.