Please bear in mind I have spent the last few years using GRAMPS for collecting Family History (the input) without dealing with Reports etc (the output) or the latest version.
All this working and producing the NarratedWeb Report has set me thinking about how it works and what is an issue for me at a personal level.
When creating the report why is there no “Save” option only Cancel and OK so if you are wanting to set up the report and altering settings the only way of retaining them is to run the report (which in my case takes about 8 hours).
If you wanted to print an Individuals page your only choice is to use the print option within your browser which includes all the headers etc when you really need a printer friendly version. So why no Print “button”.
In the layout of the Events for an Individual they basically merge one into the other a separator is needed, either a solid line between individual events or a classic double CR LF (carriage return, line feed to those wondering). This becomes more so when you include “other roles”.
I know the guru’s are all working and thinking about 5.x, y, z and Gramps Web but most Family History people are looking at the simple things.
Not raised feature requests but will if any interest
Phil
A “Save” option might be nice, although I don’t know that it would
do me much good unless there was a way to recover the saved settings. I
usually find that I get in trouble when changing versions of Gramps or
changing databases, or changing the target audience for the report. I
usually generate a report for my public website where I omit all private
data and everything except names of living people. However, I
occasionally generate a report that is distributed to family members
that includes all data, and I sometimes make a mistake in settings when
I switch from one to the other. But maybe a more useful option for me
would be an option to cancel the report generation after it has begun.
It now takes about 24 hours to generate a full report for my database,
and it would be nice if I could cancel it and properly shutdown Gramps
if I realize I’ve made a mistake or if I need to shutdown my computer
for some unrelated reason while the report is running.
I wonder if the narrative-print.css file could be modified to
accomplish what you want here.
I am using version 5.1.6 on Kubuntu (currently at 23.10) and I find
the event type in the first column to be sufficient in most cases for
me, although I don’t use roles very often. If you want something
different, you could probably accomplish it with modifications to
narrative-screen.css.
If I had more experience with CSS I’d consider looking at what could be
done to narrative-print.css and narrative-screen.css, but I don’t think
I have the experience necessary to accomplish what you would like.
I bumped into the same inconvenience and added the function: a Save button to backup all settings for a report (not only Narrative Web) and a Load button to reload all settings. This spares me the pain of reconfiguring my reports with a guarantee that all settings are exactly the same (which I could have forgotten in the mantime).
Unfortunately, my hack is so dirty that I can’t offer it to the community. The difficulty comes from the lack of an easy link from a parameter to its GTK+ widget while the reverse link is already present. My skill in Python is basic and in GTK+ below bad.
Curiosity question: what makes your report generation take 8 hours? Number of persons? Events? Notes?
This won’t work in HTML. These characters are ignored to allow to write HTML code with any layout you like. You create a line break in an HTML page with <br>.
Depending on how you “classify” (give a type) your notes, <br> may be automatically added to display the exact layout of your notes.
Events in a person page are displayed through a relatively complex HTML structure. The most relevant is a <table>. Each event is a row <tr>. Each note is <div> in the ColumnNotes cell.
Since practically all HTML tags have a class= attribute identifying their role, you could play with narrative-screen.css to add more space below each event note.
Have you tried without media? How does generation time compare?
If there is a dramatic difference, it could be worth modifying gramps/plugins/webreport/narrativeweb.py or media.py to use links to your original media directory instead of copying files into the web tree directory. Of course, you’ll need to modify your web server configuration to allow direct access to the original media directory.
I had thought of that and did it have it setup on a server (Raspberry Pi) years ago but for this I am more thinking of being able to hand a USB Stick with a browser accessible product to family and/or friends.
Phil
I don’t think this is contradictory. You can manage to set up your media directory in such a way that its relative position to the web tree directory is the same on your computer and on the USB stick. Then you copy both web tree and media directories on the USB stick and it should work.
Copying from the OS file manager is way faster than the Python-triggered copy of individual files (without parallel processing).
Likewise, nearly all of the report generation time for my reports is
spent generating the media pages, and I strongly suspect that nearly all
of that time is spent generating the References section on each page. I
use the Forms add-on for entering census data and I hope to expand my
use of it someday to other forms. But for media pages in the Narrated
Web site, references are traced back to all individuals associated with
the media object. This means that for a census page, it lists each
citation, the associated event, and all individuals that share the
event, and actually each individual is listed twice. My guess is that
all of that back-tracing requires considerable time with the current
database structure used in Gramps. By contrast, the Dynamic Web Report
only list the Source in the references for media objects that are
associated with a citation, and it only takes about an hour to generate
that report, although it means the references on media pages aren’t very
useful.
My guess is that most people looking at a Narrated Web site really don’t
care about the references section on media pages because they probably
arrive at a media page from a link on an individual’s page rather than
using the Media index page, so an option to generate a simpler
references section might be appropriate. However, when I had a major
computer failure nine years ago and lost my Gramps database and all
recent backups, I found those references very useful in rebuilding my
database from a couple of web sites that I was able to retrieve. I hope
to never go through that again, but I’d hate to lose that capability in
case I needed it.
All the options you choose to create the report are saved when you start the report.
When you create a new report, you could see all your previous options are shown again.
The save is dependant of your database name.
All the options are saved in report_options.xml.
too complex to do.
can you add a snapshot. I don’t see your problem.
Did you test other css files ?
You can modify your css.
I like the idea of saving named report configurations.
The report options code is common to all reports, not just the narrative web report. It is also designed to work with both the command line and GUI. I can understand why you had problems creating a neat solution.
Just remove .gramps extension (site spoofing trick to attach the file) and open it in a text editor. .gro = Gramps Report Options. It is similar to the report_options.xml file, except it lists only the parameters for this specific report.
After looking at my NarratedWeb directory, my suggestion needs a modification in the generator. The images/ and img/ directories are structured like ppl/ (persons), fam/ (families) and others with 2 levels of sub-directories to avoid an overcrowded directory containing all items. The “selection sub-directories” have a name consisting of a single hexadecimal digit taken from the last characters of the “handle” (the internal DB id of every record). This reduces the average number of HTML pages in the leaf directories. The reduction is not tremendous (÷ 256) but this is better than nothing.
To avoid the tricky individual copy operations to the adequate subdirectory and use the original media directory, the NarrativeWeb generator for media must be modified to emit the original filename as href="images/media_filename.jpeg" instead of href="images/level-1/level-2/handle.html". Note this also skips the HTML page generation for the media and relies on the ability of the browser to display a graphical file.
This is worth exploring.
EDIT 2024-01-26
After a good night, I think the suggestion above requires too many modifications. The simplest and easiest way is to keep the hierarchical structure of images/ and img/ and only to suppress the copy operations. These can be replaced with symbolic links to the original files. Linking files is way faster than copying them and this does not require modifications to the web server configuration to access data outside the “document root” (name varies with server engines).
I think you would find it far easier and better to simply remove the
references section from the media pages, or make it optional. It
appears to me that removing it wouldn’t be much more work than disabling
a few lines in the method mediapage in the file media.py (lines 597-605
in the version from gramps 5.1.6). Making it optional would be more
work, but doable. I suspect doing what you are suggesting would require
changes to a number of files in the webreport directory.
Doing this automatically for all reports would be to move the db_options parameter into the MenuOtions reports. never tried.
We will have :
class MenuReportOptions(MenuOptions, ReportOptions):
“”"
The MenuReportOptions class implements the :class:`ReportOptions`
functionality in a generic way so that the user does not need to
be concerned with the actual representation of the options.
The user should inherit the MenuReportOptions class and override the
add_menu_options function. The user can add options to the menu and the
MenuReportOptions class will worry about setting up the UI.
"""
def __init__(self, name, dbase):
name = name + " " + dbase.get_dbname()
ReportOptions.__init__(self, name, dbase)
MenuOptions.__init__(self)
@SNoiraudI’ll dive into my git repo to see how I did it. Done.
I was surprised to see my hack is already 4 years old. I made a git diff on it and the difference file is diff-rpt-opts-save.html (30.3 KB).
Contrary to what the extension says, it is a .txt file. Remove the .html extension and open it in a text editor.
It contains the modifications needed to save and reload options for any report. It also contains a small change to family lines graph report so that hyperlinks to persons and families can be added (not relevant for report options save & reload) but this came with the change set.
Note that the diff is valid against 5.1.2. I have not yet rebased it against current 5.1.x version.
It appears I was very wrong. I decided to try my suggestion and it
doesn’t appear to make much, if any, difference in speed after disabling
the references section. So now I am wondering what the Dynamic Web
Report does that makes it so much faster, as well as what the Narrated
Web Report is truly doing.
As for the differences between the Narrated Web Report and the Dynamic
Web Report, the media pages for the Narrated Web Report gives the type
and date for the object and a very complete references section. From
looking at the code, it also includes at least notes and attributes if
there are any. The media pages for the Dynamic Web Report do not
include the type or date but do include notes and a reference section,
although the reference section is not very useful if the media object is
associated with citations. Otherwise, both reports provide essentially
the same information.
I’ve been watching the directories that make up the web report as the
Narrated Web Report is running after I disabled generation of the
references section, and the images, img, and thumb directories are all
being populated as the media pages are being created, although the
images directory is being populated more quickly. I don’t know enough
about the database structure to make a good guess as to where all of the
time is being spent, but profiling the code might be an interesting
project for someone if there is any desire to improve performance.
I am very much for the idea of speeding up the report creation however I
am not greatly concerned about somebody spending a lot of time looking
at it.
As ever I have a work around in this case an old i3 PC which all it does
is produce the Narrative Web report whenever I choose so time will only
be a concern when that PC dies.
Phil