Is there a way (that is eluding me) to have reports and group sheets include somewhere on them the date they were generated?
I frequently come back to group sheets and wonder when it was last current and if it could use a freshening. A date would be helpful there. Reports in TMG and FTM seemed to have this turned on by default.
Thanks Craig. 2013. Wow.
You have got to remember, that true bugs get the most attention from those that know the code to make the fixes. Something like this, if a user can offer up the solution it has a better chance to be implemented.
In the short term, you can print out your report as an OpenText document. Then in your word processor of choice add the date information before actually sending it to the printer or to a PDF.
I think that the 2013 date says a LOT of things. It did not raise enough interest that someone felt it was worth their time to implement. Or, it was investigated and people discovered it was more complex than it seems on the surface.
In this case, both seem to be likely.
Superficially, a footer seems simple. (And some reports have that capability if you want to copy it to a specific report. Giansalvo added a header & footer to the DescendantLines report in 2020.) But it grows complex when you string multiple reports together. Pagination, font selection, placement, orientation all have to be coordinated.
Footers & Headers are arguably useful for keeping track of Drafts. But when you go to final assembly, they are going to need to be stripped so that a uniform style and pagination can be applied. PDFs are often going to need to have insertions & deletions. Add to this is the fact that stripping a variety of embedded headers or footers is a major task. Yet applying a header & footer as a post-process is relatively simple. There are MANY external tools that have that capability.
Personally. I prefer a simple post-process rather than layering-in a very complex inline process.
Most of us come to realize that adding sources and citations to our research is crucial to being able to deal with our collected genealogy data in some rational way. At least minimal metadata on Gramps reports would let the reader know Who produced the report, When, and from Which database. Even just knowing When is critical since there are all too often multiple copies of a given report and only the most subtle indications of what is different between them.
I can appreciate that adding this metadata is no small task. I think it is sufficiently important, however, that a report shouldnât be considered for incorporation into Gramps until this requirement is satisfied.
I think it is a strawman argument that headers and footers are a problem for âfinal assemblyââwhatever that means. If a report can have metadata added (headers, footers, preamble and/or âfinal creditsâ), then I imagine an overall checkbox could control whether that element was included or excluded at report production time.
Craig
Metadata and Header/Footer (or preamble, citations, credits, etc.) are wildly different animals.
Adding metadata is rarely addressed in GUIs except for image files and a few OS elements. And the file creation/modification date metadata is only consistent because it is automatically handled by the OS.
Specifically, metadata is not contained within the visible content of the data.
So letâs put metadata in a different discussion.
Maybe what we could talking about is some sort of âdraftâ watermarking. Something that lets you manage your work-in-progress documents but isnât intended to be included in a final deliverable work.
In the old publishing processes, youâld have a variety of press proofs before doing a full-scale print run.
The rough draft galley proofs would have another set of document management markings. And the 1st drafts had yet another.
In an ideal world, a âbookâ header/footer feature could take a Gramps genealogy deliverable all the way to final publication. Although that is highly unlikely. Gramps is fine for collating a dry, fully-cited reference section. But the creative writing, analysis & commentary that bring a publication to life really arenât possible yet within this tool.
Final assembly in a deliverable includes everything from dust cover & cover design/selection to binding to collation of distinct sections to creation of finding aids (index and/or table of contents) to paper/media selection & duplication to packing & shipping.
A report contains information. In addition, a report should have things like:
-page numbers!
-date and time created
-Gramps version
-Gramps Family Tree name
-Name and contact info from the âGramps Database Ownerâ screen.
This âmetadataâ (information about the information contained in the report) could be displayed via:
You seem to be somewhat fixated on the âBookâ report. In roughly 10 years of using Gramps (on and off), Iâve never seriously looked at using that feature. What I have done is shared pdf reports with various cousins or other researchers. They might share my report with others or refer back to it years later. Thatâs where the lack of report identification becomes a bigger and bigger problem.
When I filed the bug all those years ago, I thought it was self-evident that report identification information was valuable and necessary. Perhaps I should have been much more explicit.
Craig
It isnât a matter of âfixatedâ. It is just the appropriate tool for the task.
Add the Header & Footer that you want to the Book feature would make available in ALL reports universally. Putting it in a particular report leaves all the others having to replicate the feature code in EVERY report. And since the skills (and ambitions) of the Developers vary, that would be⌠not a good situation.
Metadata would probably be another sporadically useful addition to Books. Most people donât ever look at the âPropertiesâ dialog for a file in Windoze or Get Info on macOS. And even fewer beyond the filesizes, date & creator portion of document information.
But thatâs METADATA anyway⌠which has nothing to do with the information you keep using as examples of you want in a header/footer.
I disagree. The term metadata is not specific to files on a computer. An old-school card index at a library is a classic example of metadata: information about other information.
BTW, headers or footers are not the only way to add metadata to a report. As Iâve tried to point out, a block at the beginning or end of a report could also document the information that Iâd like to see added. A program I used in the 1990âs (Gene) could put a report-information block on any of the 4 logical corners of a graph even if the output had to be split over multiple sheets of paper. The key being that there was a mechanism to show Who, When and Which database.
Craig
Letâs just amicably agree to disagree on the definition of metadata as it applies to Gramps.
For a text report, gramps has no concept of header or footer. If you want one, the easiest solution as mentioned is to print to OpenDocument format and use OpenOffice to add custom header/footer as desired. This is pretty easy.
If you want to put a preamble or ending text block, the report needs to be modified. If you have one existing report that you use and want modified, I may be able to modify and send you an updated report file. I suspect that any change would be only for you since these are pretty user-dependent requests. If you know how to code, you can take the changes I provide and modify further. I have already mocked up one of my custom reports to add an ending text block with date, gramps version, and tree name so I can use that as a template.
Personally, I would only go the OpenDocument approach, since a footer with data and page numbers is more interesting than a block of text at the end of the report.
I feel like Iâm out of my depth on this thread, as I donât really feel qualified to add very much to the level of debate on some of the comments here. But Iâd like to add a ânewbieâ thought, which doesnât really solve the question, but it might be a compromise work-round, not a real solution, and doesnât involve significant changes (although that may be my misunderstanding; I donât understand the concept of âblocksâ so maybe Iâm being too simplistic). I often produce reports with ouput to pdf, and the âDocument Properitesâ in the case of âComplete Individual Reportâ, does not have many of its fields populated. Perhaps more information could be written into the pdfâs Document Properties. Itâs not perfect, but it might be a start. I believe there are similar fields in a document (e.g. .rtf).
How I think of it: The Report generation is composed of two parts: Content and Output.
The Content is determined by the report (text, lists, tables, âŚ) template. Report templates can be created by the user or you can use one of the pre-built templates. If you wanted to put a list of characteristics (like date, tree, âŚ) in the body of the report, it would be added here in the report template.
The Output format is determined by the user (PDF, RTF, OpenDocument, LaTex, Plain Text, âŚ) and a corresponding âdevice driverâ then creates that output file. Attributes like margins and footer and header would be specified here. Gramps allows the user to define the margins but has no header or footer support. PDF metadata would also be here (but there is no current support for it). The device drivers are part of gramps core.
It is easy to change the Content (edit the specific report template), it is not easy to change the device driver.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
