Proposal: Rows to Repeat and Columns to Repeat functionality
John Harrison
xlwt.
Rows to Repeat defines rows on a sheet that will be printed at the top
of each printed page of that sheet.
Columns to Repeat defines columns on a sheet that will be printed at
the left of each printed page of that sheet.
As requested by John Machin, here's some addtional information
(1) new APIs and changes to existing APIs
In worksheet.py the following methods would be added to the worksheet
object:
def set_rows_to_repeat_at_top(self, rstart, rend):
def set_columns_to_repeat_at_side(self, cstart, cend):
These are the new methods that users would call.
Additionally this work would require adding the following classes to
BiffRecords.py:
NameRecord
SupBookRecord
InternalReferenceSupBookRecord
In WorkBook.py a __names_rec(self) method would be added to access
NameRecords an the following methods would be modified to support
NameRecords:
__all_links_rec(self)
__sst_rec(self)
(2) a statement of benefits (new functionality / faster / uses less
memory / etc) and trade-offs
This provides some nice functionality for end-users that print
spreadsheets generated with xlwt.
There are no major trade-offs that I'm aware of.
(3) a statement of the impact on users who don't use the new
features.
There will be minimal impact on those who don't use these features.
The primary negative impact is that xlwt will become a little bit
bigger and therefore more complex.
John Machin, I hope this is roughly what you wanted to see. I'll hold
off on proposing anything else that might benefit xlwt until I've seen
the outcome of the process with this proposal.
best regards,
John Harrison
John Machin
> I propose adding Rows to Repeat and Columns to Repeat functionality to
> xlwt.
>
> Rows to Repeat defines rows on a sheet that will be printed at the top
> of each printed page of that sheet.
>
> Columns to Repeat defines columns on a sheet that will be printed at
> the left of each printed page of that sheet.
What happened to setting a print area, which uses the same name-record
mechanism, is also useful & user-desired, and which was in the
tri-partite patch?
>
> As requested by John Machin, here's some addtional information
>
> (1) new APIs and changes to existing APIs
>
> In worksheet.py the following methods would be added to the worksheet
> object:
> def set_rows_to_repeat_at_top(self, rstart, rend):
> def set_columns_to_repeat_at_side(self, cstart, cend):
Given that the previous patch didn't allow the use of both
simultaneously (which is legal, but involves extra work (thank you,
MS)), it would be a good idea to state whether this is still the case.
>
> These are the new methods that users would call.
>
> Additionally this work would require adding the following classes to
> BiffRecords.py:
> NameRecord
> SupBookRecord
> InternalReferenceSupBookRecord
I don't understand. Those classes already exist; they were added as part
of the implementation of the "intra-workbook sheet references in
formulas" functionality released in version 0.7.1 and have been in svn
since 13 Feb.
>
> In WorkBook.py a __names_rec(self) method would be added to access
> NameRecords an the following methods would be modified to support
> NameRecords:
> __all_links_rec(self)
> __sst_rec(self)
>
> (2) a statement of benefits (new functionality / faster / uses less
> memory / etc) and trade-offs
>
> This provides some nice functionality for end-users that print
> spreadsheets generated with xlwt.
>
> There are no major trade-offs that I'm aware of.
>
> (3) a statement of the impact on users who don't use the new
> features.
>
> There will be minimal impact on those who don't use these features.
> The primary negative impact is that xlwt will become a little bit
> bigger and therefore more complex.
>
>
> John Machin, I hope this is roughly what you wanted to see.
It's a good start. I'm looking forward to the next edition.
Cheers,
John
John Harrison
On Apr 7, 8:09 am, John Machin <sjmac...@lexicon.net> wrote:
> On 7/04/2009 2:51 AM, John Harrison wrote:
>
> > I propose adding Rows to Repeat and Columns to Repeat functionality to
> > xlwt.
>
> > Rows to Repeat defines rows on a sheet that will be printed at the top
> > of each printed page of that sheet.
>
> > Columns to Repeat defines columns on a sheet that will be printed at
> > the left of each printed page of that sheet.
>
> What happened to setting a print area, which uses the same name-record
> mechanism, is also useful & user-desired, and which was in the
> tri-partite patch?
>
I have no problem including that.
>
> > As requested by John Machin, here's some addtional information
>
> > (1) new APIs and changes to existing APIs
>
> > In worksheet.py the following methods would be added to the worksheet
> > object:
> > def set_rows_to_repeat_at_top(self, rstart, rend):
> > def set_columns_to_repeat_at_side(self, cstart, cend):
>
> Given that the previous patch didn't allow the use of both
> simultaneously (which is legal, but involves extra work (thank you,
> MS)), it would be a good idea to state whether this is still the case.
sheet. If there is interest in being able to set both, or if this
patch is only acceptable if it can do that, then I would be happy to
do that work as well.
> > These are the new methods that users would call.
>
> > Additionally this work would require adding the following classes to
> > BiffRecords.py:
> > NameRecord
> > SupBookRecord
> > InternalReferenceSupBookRecord
>
> I don't understand. Those classes already exist; they were added as part
> of the implementation of the "intra-workbook sheet references in
> formulas" functionality released in version 0.7.1 and have been in svn
> since 13 Feb.
>
it hasn't been clear if anyone wants it, so I hadn't discovered that.
>
> > In WorkBook.py a __names_rec(self) method would be added to access
> > NameRecords an the following methods would be modified to support
> > NameRecords:
> > __all_links_rec(self)
> > __sst_rec(self)
>
> > (2) a statement of benefits (new functionality / faster / uses less
> > memory / etc) and trade-offs
>
> > This provides some nice functionality for end-users that print
> > spreadsheets generated with xlwt.
>
> > There are no major trade-offs that I'm aware of.
>
> > (3) a statement of the impact on users who don't use the new
> > features.
>
> > There will be minimal impact on those who don't use these features.
> > The primary negative impact is that xlwt will become a little bit
> > bigger and therefore more complex.
>
> > John Machin, I hope this is roughly what you wanted to see.
>
> It's a good start. I'm looking forward to the next edition.
>
> Cheers,
> John
John Machin
>
>
> On Apr 7, 8:09 am, John Machin <sjmac...@lexicon.net> wrote:
>> What happened to setting a print area, which uses the same name-record
>> mechanism, is also useful & user-desired, and which was in the
>> tri-partite patch?
> I was trying to keep it small in hopes of a kinder response from you.
> I have no problem including that.
Neither do I.
>>> As requested by John Machin, here's some addtional information
>>> (1) new APIs and changes to existing APIs
>>> In worksheet.py the following methods would be added to the worksheet
>>> object:
>>> def set_rows_to_repeat_at_top(self, rstart, rend):
>>> def set_columns_to_repeat_at_side(self, cstart, cend):
>> Given that the previous patch didn't allow the use of both
>> simultaneously (which is legal, but involves extra work (thank you,
>> MS)), it would be a good idea to state whether this is still the case.
>
> You are correct that the previous patch didn't allow setting both on a
> sheet. If there is interest in being able to set both, or if this
> patch is only acceptable if it can do that, then I would be happy to
> do that work as well.
Given the per-patch overhead, it makes sense to me to knock off all of
these closely related items at the same time. The amount of extra work
involved in doing both columns and rows is trivial.
>>> These are the new methods that users would call.
>>> Additionally this work would require adding the following classes to
>>> BiffRecords.py:
>>> NameRecord
>>> SupBookRecord
>>> InternalReferenceSupBookRecord
>> I don't understand. Those classes already exist; they were added as part
>> of the implementation of the "intra-workbook sheet references in
>> formulas" functionality released in version 0.7.1 and have been in svn
>> since 13 Feb.
>>
>
> Excellent. I haven't yet ported the patch to the newest version since
> it hasn't been clear if anyone wants it, so I hadn't discovered that.
>
>
>>> In WorkBook.py a __names_rec(self) method would be added to access
>>> NameRecords an the following methods would be modified to support
>>> NameRecords:
>>> __all_links_rec(self)
>>> __sst_rec(self)
Umm ... I didn't spot this at the previous reading: What's the SST
(shared string table) record got to do with support for NAME records?
John Harrison
On Apr 8, 9:56 am, John Machin <sjmac...@lexicon.net> wrote:
> On 8/04/2009 3:01 AM, John Harrison wrote:
>
>
>
> > On Apr 7, 8:09 am, John Machin <sjmac...@lexicon.net> wrote:
> >> What happened to setting a print area, which uses the same name-record
> >> mechanism, is also useful & user-desired, and which was in the
> >> tri-partite patch?
> > I was trying to keep it small in hopes of a kinder response from you.
> > I have no problem including that.
>
> Neither do I.
def add_print_area(self, rstart, rend, cstart, cend):
as a method that will be implemented in worksheet.
>
> >>> As requested by John Machin, here's some addtional information
> >>> (1) new APIs and changes to existing APIs
> >>> In worksheet.py the following methods would be added to the worksheet
> >>> object:
> >>> def set_rows_to_repeat_at_top(self, rstart, rend):
> >>> def set_columns_to_repeat_at_side(self, cstart, cend):
> >> Given that the previous patch didn't allow the use of both
> >> simultaneously (which is legal, but involves extra work (thank you,
> >> MS)), it would be a good idea to state whether this is still the case.
>
> > You are correct that the previous patch didn't allow setting both on a
> > sheet. If there is interest in being able to set both, or if this
> > patch is only acceptable if it can do that, then I would be happy to
> > do that work as well.
>
> Given the per-patch overhead, it makes sense to me to knock off all of
> these closely related items at the same time. The amount of extra work
> involved in doing both columns and rows is trivial.
>
will allow rows and columns to repeat to be defined at the same time.
>
>
> >>> These are the new methods that users would call.
> >>> Additionally this work would require adding the following classes to
> >>> BiffRecords.py:
> >>> NameRecord
> >>> SupBookRecord
> >>> InternalReferenceSupBookRecord
> >> I don't understand. Those classes already exist; they were added as part
> >> of the implementation of the "intra-workbook sheet references in
> >> formulas" functionality released in version 0.7.1 and have been in svn
> >> since 13 Feb.
>
> > Excellent. I haven't yet ported the patch to the newest version since
> > it hasn't been clear if anyone wants it, so I hadn't discovered that.
>
> >>> In WorkBook.py a __names_rec(self) method would be added to access
> >>> NameRecords an the following methods would be modified to support
> >>> NameRecords:
> >>> __all_links_rec(self)
> >>> __sst_rec(self)
>
> Umm ... I didn't spot this at the previous reading: What's the SST
> (shared string table) record got to do with support for NAME records?
Trac system. There is no change to __sst_rec. Instead there is one
line added and two lines changed in get_biff_data(self):
John Yeung
It would be a shame if it were dead, as it seemed there were at least
a couple of mostly working quasi-patches floating around (one from
each of the other Johns on this thread).
John Y
John Machin
I've heard nothing since the last message (from John H) in that thread.