Division By Zero in \SilvaDocument\transform\kupu\silva.py

Bug #101513 reported by Nico Grubert
6
Affects Status Importance Assigned to Milestone
Silva
Fix Released
Medium
Unassigned

Bug Description

SilvaDocument version: SilvaDocument 1.2.2

When creating tables with the forms editor, from time to time one cannot save
the document in kupu. The traceback:

Module Products.SilvaDocument.transform.kupu.silva, line 357, in convert
ZeroDivisionError: integer division or modulo by zero

Module Products.SilvaDocument.transform.kupu.silva, in line 357 it reads:
  units = 100 / reduce(operator.add, relwidths)

If reduce(operator.add, relwidths) is Zero, the exception above is raised.

Solution: check if reduce(operator.add, relwidths) is true (not Zero).

Revision history for this message
Clemens Robbenhaar (crobbenhaar) wrote :

Stupid question: how does one set all the relative columns widths
so the sum up to zero?

I have not been able to trigger the bug via edits from the forms editor
(the sum gets zero only if deleting all columns - a case which is handled correctly
by the current code, I think)

I can set all to zero by editing the xml directly, but in that case the
forms editor and kupu fail either.

Any hints how to reproduce this one would be very welcome.

btw the code in qustion seems to be in line 275 for me

Revision history for this message
Nico Grubert (nicogrubert) wrote :

Dear Clemens,

one of the editors in our company who is working with silva wrote me
that she could not save the document that she has created with the forms
editor if she switches to Kupu.

Below, you'll find the parsed XML code of the document version which
could not be saved in Kupu mode.

<?xml version="1.0" ?>
<doc><heading type="sub">(Stand 23.09.2005)</heading><table
column_info="L:33 L:33 L:33" type="plain"
columns="3"><row><field/><field/><field/></row></table><table
column_info="L:28 L:70" type="list"
columns="2"><row_heading>test</row_heading><row><field><p
type="normal">ab 1.1.2005: 2%<br/><br/><strong>ab 1.7.2005:
1.75%<br/></strong></p></field><field><p
type="normal">test<br/>test.<br/>test<strong/></p></field></row></table><table
column_info="L:33 L:33 L:33" type="plain"
columns="3"><row><field/><field/><field/></row></table><table
column_info="L:0 L:0 L:0" type="list"
columns="3"><row_heading>test</row_heading><row><field><p
type="normal"><strong>31.12.2005</strong><br/>2.25%</p></field><field/><field/></row><row><field><list
type="none"><li>Variable: 2,25%<br/>Fest 02J: 1.95%<br/> 03J:
2.05%<br/> 04J: 2.25%<br/> 05J; 2.40%<br/> 06J:
2.55%<br/> 07J: 2.75%<br/> 08J: 2.90%<br/> 09J:
2.90%<br/> 10J: 3.10%</li></list></field><field><p
type="normal"><strong>ab
01.01.2006</strong><br/>2.20%<br/>2.35%<br/>2.50%<br/>2.65%<br/>2.75%<br/>2.80%<br/>2.95%<br/>3.05%<br/>3.10%</p></field><field><p
type="normal">test.<br/>test</p></field></row></table></doc>

Kind regards,
Nico

Clemens Klein-Robbenhaar wrote:
> Clemens Klein-Robbenhaar <email address hidden> added the comment:
>
> Stupid question: how does one set all the relative columns widths
> so the sum up to zero?
>
> I have not been able to trigger the bug via edits from the forms editor
> (the sum gets zero only if deleting all columns - a case which is handled correctly
> by the current code, I think)
>
> I can set all to zero by editing the xml directly, but in that case the
> forms editor and kupu fail either.
>
> Any hints how to reproduce this one would be very welcome.
>
> btw the code in qustion seems to be in line 275 for me
>
> ----------
> status: unread -> chatting
>
> ____________________________________________
> Silva issue tracker <email address hidden>
> <https://infrae.com/issue/silva/issue1398>
> ____________________________________________
>
>

Revision history for this message
Clemens Robbenhaar (crobbenhaar) wrote :

Dear Nico,

thanks for the example.

  Clearly there is a 'column_info="L:0 L:0 L:0"' which is something
that "should not happen".
I cannot edit that document neither in kupu nor in the forms editor,
and I have no idea how someone could get the document in that state.
The preview does not work either, so the document cannot even be displayed.

So if we are going to fix hat, we would have to fix it for the widgets
system, too. (Same for XSLT and xml export).

Before I add some defensive code to handle a state which should
not be reachable in the first place, I ask the folks at infrae what
they think about it.

Kit: any opinion? Or get any of the technicans to nose in?

Revision history for this message
Nico Grubert (nicogrubert) wrote :

Hi Clemens,

below is the parsed XML content that will work, bot in kupu and forms
editor:

<?xml version="1.0" ?>
<doc><heading type="sub">test</heading><table column_info="L:33 L:33
L:33" type="plain"
columns="3"><row><field/><field/><field/></row></table><table
column_info="L:28 L:70" type="list"
columns="2"><row_heading>test</row_heading><row><field><p
type="normal">1.1.2005: 2%<br/><br/><strong>ab 1.7.2005:
1.75%<br/></strong></p></field><field><p
type="normal">test.<br/>test.<br/>test<strong/></p></field></row></table><table
column_info="L:33 L:33 L:33" type="plain"
columns="3"><row><field/><field/><field/></row></table><table
column_info="L:28 L:28 L:50" type="list"
columns="3"><row_heading>test</row_heading><row><field><p
type="normal"><strong>test</strong><br/>2.25%</p></field><field><p></p></field><field><p></p></field></row><row><field><list
type="none"><li>Variable: 2,25%<br/>Fest 02J: 1.95%<br/> 03J:
2.05%<br/> 04J: 2.25%<br/> 05J; 2.40%<br/> 06J:
2.55%<br/> 07J: 2.75%<br/> 08J: 2.90%<br/> 09J:
2.90%<br/> 10J: 3.10%</li></list></field><field><p
type="normal"><strong>ab
01.01.2006</strong><br/>2.20%<br/>2.35%<br/>2.50%<br/>2.65%<br/>2.75%<br/>2.80%<br/>2.95%<br/>3.05%<br/>3.10%</p></field><field><p
type="normal">test.<br/>test</p></field></row></table></doc>

Kind regards,
Nico

Clemens Klein-Robbenhaar wrote:
> Clemens Klein-Robbenhaar <email address hidden> added the comment:
>
> Dear Nico,
>
> thanks for the example.
>
> Clearly there is a 'column_info="L:0 L:0 L:0"' which is something
> that "should not happen".
> I cannot edit that document neither in kupu nor in the forms editor,
> and I have no idea how someone could get the document in that state.
> The preview does not work either, so the document cannot even be displayed.
>
> So if we are going to fix hat, we would have to fix it for the widgets
> system, too. (Same for XSLT and xml export).
>
> Before I add some defensive code to handle a state which should
> not be reachable in the first place, I ask the folks at infrae what
> they think about it.
>
> Kit: any opinion? Or get any of the technicans to nose in?
>
> ____________________________________________
> Silva issue tracker <email address hidden>
> <https://infrae.com/issue/silva/issue1398>
> ____________________________________________
>
>

Changed in silva:
assignee: nobody → aaltepet
Revision history for this message
Andy Altepeter (aaltepet) wrote :

This is silly. The only way I was able to get all "0"s in for the widths was to explicitly set them in kupu to "0". So, I created a table with four columns, and then set the column widths to "0,0,0,0".

I adjusted the transform to allow all widths to be 0, according to the suggestion belo

Changed in silva:
milestone: none → 2.1
status: Confirmed → Fix Committed
Changed in silva:
assignee: aaltepet → nobody
Changed in silva:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.