Problems with report_options.xml and docgen table

Gramps version 5.1. Linux kihikihi 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux. Python 3.8.10.

I have been writing a new text report using docgen. The report creates a docgen table where the columns are people specified in the persons of interest selector and the rows are years in which events occur for the selected people. It seems to be working pretty well, except when in doesn’t.

It fails utterly if the gidlist option report_options.xml is empty. The docgen table styles, specifically the number and width of columns, are set in the my options class which is created before a new gidlist can be greated by the user. I’ve created a kludge that avoids the problem, but it only kicks the can down the street. The report will then fail utterly attempting to overwrite the output file specified in report_options.xml. The must be a way to avoid issues with report_options.xml, particularly to accommodate cases when the relevant module is not completely described.

Finally, docgen inserts a page break in a table cell without regard to line breaks. I simply looks ugly.

So, I would appreciate a little guidance on how to (1) initialize report options that do not depend so totally on report_options.xml; and (2) constrain page breaks to occur only between rows.

Thanks for helping,

I think that’s your problem. Can you share that part of the code or send it to me?

You cannot set values during menu creation. The report_options.xml values are applied between the end of the option menu creation and the beginning of the report.

Hello SNolraud,
You can find my code on github

So the report_options.xml values are applie, as soon as the “OK” button is clicked? I would be useful to see the code where this occurs.

Thanks for helping,

The first time I tried your plugin, I get:

69300: ERROR: line 173: Unhandled exception
Traceback (most recent call last):
  File "/home/gramps/gramps-5.1.5/gramps/gui/", line 1576, in <lambda>
    return lambda x, y: run_plugin(pdata, dbstate, uistate)
  File "/home/gramps/gramps-5.1.5/gramps/gui/", line 1557, in run_plugin
    report(dbstate, uistate, uistate.get_active('Person'),
  File "/home/gramps/gramps-5.1.5/gramps/gui/plug/report/", line 698, in report
    dialog = dialog_class(dbstate, uistate, options_class, name, trans_name)
  File "/home/gramps/gramps-5.1.5/gramps/gui/plug/report/", line 99, in __init__
    DocReportDialog.__init__(self, dbstate, uistate, options,
  File "/home/gramps/gramps-5.1.5/gramps/gui/plug/report/", line 74, in __init__
    ReportDialog.__init__(self, dbstate, uistate, option_class,
  File "/home/gramps/gramps-5.1.5/gramps/gui/plug/report/", line 104, in __init__
  File "/home/gramps/gramps-5.1.5/gramps/gui/plug/report/", line 89, in init_interface
  File "/home/gramps/gramps-5.1.5/gramps/gui/plug/report/", line 191, in init_interface
  File "/home/gramps/gramps-5.1.5/gramps/gui/plug/report/", line 317, in setup_style_frame
  File "/home/serge/.gramps/gramps51/plugins/TimelineContingency/", line 298, in make_default_style
    w = (100.0-w0)/npid
ZeroDivisionError: float division by zero

Yes, that is the behavior for first time runs. It occurs because the list of people of interest is empty (length 0). It might work if you try to run it a second time.
Meanwhile, I have pushed a new version of the plugin to my git repo that circumvents that particular issue, but there there is a remaining issue with the output file name. It seems to work if you specify a different directory for the file.

Thanks for helping out,

I think I had a simpler solution than yours:

    table.set_column_width(0, w0)
    npid = npid if npid else 1  # only adding this line solves the ZeroDivisionError.
    w = (100.0-w0)/npid

It’s up to you to manage all possible cases: bad argument, argument not known or set.
gramps doesn’t know what you are doing.

You can’t do that.

This is possible in html:

table {
  border-collapse: separate;
  border-spacing: 0 15px;

To do that, you need to modify all docgen modules (html, rtf, odf, latex, …) as this possibility is not implemented.

But don’t forget the user can create an odt document, a pdf, … and I don’t know if this is possible in other format than html.
If you want to have a page break between rows, it will be simpler to create a table per row.

Thanks for your code suggestion. Very pythonic; I’m more at home in C++
I like the idea of making each row a table. It should be fairly simple to implement.

I implemented making each row a table, but page breaks still occur across cells. If there are 4 or 5 people in the table, the text gets long and provokes a page break. Perhaps html is the best option.

Also, overwriting a file sometimes causes a problem.

Thanks for your help,

Can you attach an example or snapshot to see exactly what is your problem.

Not sure if attachment are permitted on this host, or you can download an example from git hub at

(Attachment page_breaak_example.pdf is missing)

OK. I see what is your problem. When you write documents on the fly, you don’t care about the written lines. So it is impossible to make a page break (pdf don’t known where to make it. it is the same for odt, rtf, latex, …)
The only way to do that is to have a line counter and to generate a page break when you have more than N written lines. It will be a manual page break.
This is not related to gramps but to all tool generating documents on the fly.
For now, the only document format that works is html. Any format must work or there will be bug reports.

Yes. I reached the same conclusion. For now, the PDF format doesn’t support page breaks. Even counting lines is a problem because (1) line breaks occur when the algorithm detects that a line exceed the cell width in a table, and (2) I use the ‘\n’ to create line breaks within the Event reporting within a cell. I’ll probably just reserve the report for my personal use (I have found it helpful) and give html a try some time in the future. My code is always available on github for those who might be interested in giving a try.
Thanks a lot for your wisdom and advice,

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.