Improving reports.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Improving reports.

Don Allingham-2
Now that 2.0.x is released, it is time to start looking at reports. If
you have a chance, please answer the following questions:

1) What reports does GRAMPS have that are useful?
2) What reports does GRAMPS have that are not useful?
3) What reports does GRAMPS need that it does not have?
4) How can the current reports be improved.

Don

--
Don Allingham
GRAMPS - Open Source Genealogy
http://www.gramps-project.org



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gramps-users] Improving reports.

Michelle Engel
Hi Don,

this is the thread I was waiting for ;-)

Here are my 2 cents:
 
1) What reports does GRAMPS have that are useful?
Text reports:
- Family Group Sheet
- Complete Individual Summary
- Detailed Ancestral Report
- Detailed Descendant Report
- Ahnentafel Report
- Descendant Report

Graphic reports:
- Ancestor Chart
- Wall Chart
- Relationship Graph / Code Generators
- Descendant Graph

And, of course, the webpage.

2) What reports does GRAMPS have that are not useful?
- Individual Summary - it's just a special case of Complete Individual
Summary
- FTM-Style reports - contains the same content like Detailed Text reports
- Comprehensive Ancestors Report - contains the same contents like
Detailed Ancestral Report. I don't like that the children are listed
three times. In the text for the father, for the mother and in a list.
But it has a nicer layout.

3) What reports does GRAMPS need that it does not have?
- Hourglass Chart
- An ancestor chart over a couple of pages, but not as huge as the wall
chart. More compressed than the wall chart.

4) How can the current reports be improved.
Detailed Text Reports:
- I miss some kind of structure for the "embedded children list",
perhaps new lines for birth and death, or commas. It's all in one line
now: name birth death - without comma or something similar. Hard to read.
- In general a more elaborate layout would be nice, like the
Comprehensive Ancestors Report.

Family Group Sheet:
- Very important is the marriage date and place of the main couple -
it's missing in the current version
- I would like to have the options to include sources or notes.
- A filter option like in the Complete Individual Report: print Family
Group Sheets for active person only, descendants, ancestors, 5
generations forward/backward, entire database, etc
- Optional inclusion of more events, like occupation or address.
- A note that tells me, if there are other spouses.
- Intelligent page break: if a couple has a lot of children, the table
with the children breaks at an inappropriate point, for example after a
childs name and before its birth date. That's not nice.

Ancestor Chart:
- Numbers for the people, so that I can find the connections between the
different pages. Best would be Kekule-Numbers.

A general option I'm missing is "private notes": if I had an ancestor,
that died because of suicide or alcohol or he was criminal then I write
it into my notes, but perhaps I don't want this to be printed in every
report. I would like to have the possibility to take down private notes.
Perhaps a new tab? Or a prefix that identifies the following text as
private (like ~ in PAF). As a consequence I could imagine a checkbox for
"Include private notes" as an option in reports.

I hope it's not too much ;-)

Michelle




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gramps-users] Improving reports.

Bruce DeGrasse
In reply to this post by Don Allingham-2
Don,  when I did the original DetAncestralReport I had patched in the
following option list in the code.  This was as much for development as for
final version.  As you and the Gramps community consider the merging the text
reports you might consider starting with this or a similar list.  Of course
the final options should be put it into a GUI display but this is not
particularly difficult if the option list has been stablized.

Since it took just a matter of hours to convert DetAncestralReport to
DetDescendantReport I think it is possible to have one text report with
Ancestor/Descendant option for Gramps.

Photos should difinitely be included in the report.  I had in prototype the
ability to display photos on the (1) left at the start of an individual with
wrap on/off, (2) on the right, and (3) collection of images (mini album)
following the individual (after the children list).  I think these should be
the minimum photo/image set of features.

Adding options such as photos is no trivial task, most of my time back then
was studying and experimenting with the XML for OpenOffice and Kword.  I am
sure much has changed since then, but adding a general photo/image insert
feature could still be a test.  Back then I found HTML much easier to work
with, mainly because it was better documented.  (BTW I have no experience
with Abiword.)

The following is copied from DetAncestralReport.py
        ### Initialize report options###

        #Use first name in place of he or she in text
        self.firstName= reportOptions.Yes

        #Use year only, not full date/month
        self.fullDate= reportOptions.Yes

        #Do not list children
        self.listChildren= reportOptions.Yes

        #Add stepchildren to the list of children
        #self.addStepChildren= reportOptions.Yes

        #Print notes
        self.includeNotes= reportOptions.Yes

        #Selectively print notes (omit private information)
        #self.omitPrivInfo= reportOptions.No

        #generate header for each page, specify text
        #self.noHeader= reportOptions.Yes

        #Inculde reference notes
        #self.noRefNotes= reportOptions.Yes

        #Include source notes
        #self.noSourceNotes= reportOptions.Yes

        #Replace missing Place with ___________
        self.blankPlace= reportOptions.No

        #Replace missing dates with __________
        self.blankDate= reportOptions.No

        #Omit country code
        #self.noCountryInfo= reportOptions.No

        #Put title before or after name (Dr., Lt., etc.)
        #self.titleAfter= reportOptions.Yes

        #Add "Died at the age of NN" in text
        self.calcAgeFlag= reportOptions.Yes

        #Add Photos and Images to report
        self.addImages= reportOptions.Yes
        #self.imageAttrTag= "DetAncestralReport-H"
        #self.imageAttrTag= "DetAncestralReport-L"

        #Omit sensitive information such as birth, christening, marriage
        #   for living after XXXXX date.

        #Omit duplicate persons, occurs when distant cousins marry
        self.dupPersons= reportOptions.Yes

        #Add descendant reference in child list
        self.childRef= reportOptions.Yes

Bruce


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Improving reports.

Richard Taylor-2
In reply to this post by Don Allingham-2

A few of issues that would improve the report experience:

1 - would it be possible to use the gnome-mime magic to open a viewer for a
report as soon as the report is generated?

2 - is there some way of getting the font metrics information available to the
reports? When I wrote my TraditionalDescendant report the biggest problem I
had was getting a good looking layout went I new little of how big the text
was going to be. This should be possible for PDF reports at least.

3. It would be "nice" to combine the options for those reports that
essentially report the same thing but differ only in presentation. So a
single options page for all 'Acendants Reports", one for "Decendants Reports"
etc. With a selection for the format that the report should take e.g. Wall
chart, Traditional Tree, Text Report etc. The options for which people to
include and what information to include should be common between these
categories of report.

4. An option to preview/print a report directly. I have no idea what
capabilities gnome/gtk offers to achieve this.

Richard


On Thursday 26 May 2005 21:04, Don Allingham wrote:
> Now that 2.0.x is released, it is time to start looking at reports. If
> you have a chance, please answer the following questions:
>
> 1) What reports does GRAMPS have that are useful?
> 2) What reports does GRAMPS have that are not useful?
> 3) What reports does GRAMPS need that it does not have?
> 4) How can the current reports be improved.



--
Jabber: [hidden email]
PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7DA9FD9
Key fingerprint = D051 A121 E7C3 485F 3C0E  1593 ED9E D868 A7DA 9FD9


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Improving reports.

Don Allingham
Richard Taylor wrote:
> A few of issues that would improve the report experience:
>
> 1 - would it be possible to use the gnome-mime magic to open a viewer for a
> report as soon as the report is generated?

This should be an option in the current version. We should be checking
the mime-type to see if there is an associated viewer. If there is,
there should be a checkbox beneath the format saying something like
"Open with OpenOffice" (or whatever the mime-type is assocated with).

> 2 - is there some way of getting the font metrics information available to the
> reports? When I wrote my TraditionalDescendant report the biggest problem I
> had was getting a good looking layout went I new little of how big the text
> was going to be. This should be possible for PDF reports at least.

This has been a problem. Fonts in general are not known up front - we've
had to go with a generic "Roman" or "Swiss". Some formats support Arial,
others Helvetica, some both. And once you branch beyond the basic latin
fonts, it gets even more difficult.

Postscript and PDF have the advantage in that you can programattically
take the size of a string. Traditional formats don't allow you to do this.

As a lame workaround, I calculated some font metrics from the standard
postscript fonts to estimate the string size for roman and swiss font.
This can be done using FontScale.string_width(). However, this is really
only an approximation, since it was taken from a single font.

If anyone has any better ideas, I would love to hear them. I don't think
that linux/un*x/etc. has a standard way of accessing font information -
at least not a way that is nicely accessible to python.

> 3. It would be "nice" to combine the options for those reports that
> essentially report the same thing but differ only in presentation. So a
> single options page for all 'Acendants Reports", one for "Decendants Reports"
> etc. With a selection for the format that the report should take e.g. Wall
> chart, Traditional Tree, Text Report etc. The options for which people to
> include and what information to include should be common between these
> categories of report.

Very good idea.

> 4. An option to preview/print a report directly. I have no idea what
> capabilities gnome/gtk offers to achieve this.

We already support this. If you install the gnome-python2-gnomeprint or
gnome-python-extras package, you can have direct printing with print
preview.

This is an optional module.

Don



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gramps-users] Improving reports.

Adam Stein
In reply to this post by Don Allingham-2
On Thu, 2005-05-26 at 16:04, Don Allingham wrote:
> Now that 2.0.x is released, it is time to start looking at reports. If
> you have a chance, please answer the following questions:
>
> 1) What reports does GRAMPS have that are useful?

I currently use the Relationship Graph to get a graphical family tree.
I use Detailed Descendant because it uses the images I have.

> 2) What reports does GRAMPS have that are not useful?
> 3) What reports does GRAMPS need that it does not have?
> 4) How can the current reports be improved.

Actually, the answers to each are the same, kinda.  The Relationship
Graph is good.  What Gramps needs in the way of text reports is one that
can print most (if not all) of the information that Gramps can hold.
You can argue that it would be hard to print the stuff that a particular
user adds (like a new event), but the text report should be able to
write up the information stored in the basic fields that Gramps comes
with.

What I would like are things like:

1) Ability to print out information stored in all the Gramps basic
fields.

2) Pictures (with the ability to select 'use all pictures' or 'use first
picture' -- which implementation wise could just be an 'use only first
picture' checkbox which, if not checked uses all pictures).

3) Being able to add the pictures with captions which would be the title
associated with each image in the database.

4) Ability to save options.  I always have to repick the same stuff.  It
would be nice if I could save and reload my settings or have Gramps just
remember the last settings used.  Even going back without quitting, all
the options are reset back to defaults.

For anybody that rememberd the proof-of-concept 'All-In-One' report
plugin a while ago, I tried to solve the problems I saw.  Since then, I
started again on a report plugin that I called 'Extensive Report' (I
didn't like All-In-One but I couldn't think of a better name at the
time).  Both had the same type of architecture (with Extensive being a
better design of it).  Features included:

1) Plugin support (yes, a plugin can have it's own plugins!)  This
allowed multiple people to help develop independently (as long as they
weren't changing the core part).   The report plugin would only offer
options for those plugins that it could find (a plugin to write
Birth/Death information, a plugin to write Marriage information, etc.).
This would also allow the report plugin to write out more information as
the subplugins got created.

2) Abililty to load and save options.  No more having to remember what
you set.

There is probably more, but I haven't been able to work on it for a
while and I don't remember all the particulars anymore.  It was written
and works with Gramps v1.0.11.  'Extensive' right now can write out
Birth/Death & Marriage information crudely (so it's not as fully
featured as I would like -- no infrastructure to do pictures yet).

Now that 2.x is out, I don't know if the plugin part changed.  I now run
Red Hat 9 at work (still run Solaris at home), and I couldn't find any
RPMs of the newer GNOME version needed for Gramps v2.x for RH9.  I can't
even figure out how to see what version is installed (I run the KDE
desktop and I can see a version for that, but don't know what to do
about GNOME).  Given that, it might be a long time before I start up on
'Extensive' again.  I'm guessing that better report plugins might come
out in the meantime.  If anybody is interested in seeing it, I can make
it available online.

--
Adam Stein @ Xerox Corporation       Email: [hidden email]

Disclaimer: Any/All views expressed
here have been proved to be my own.  [http://www.csh.rit.edu/~adam/]



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Improving reports.

Eero Tamminen
In reply to this post by Don Allingham
Hi,

On Tuesday 31 May 2005 18:27, Don Allingham wrote:

> > 2 - is there some way of getting the font metrics information available
> > to the reports? When I wrote my TraditionalDescendant report the
> > biggest problem I had was getting a good looking layout went I new
> > little of how big the text was going to be. This should be possible for
> > PDF reports at least.
>
> This has been a problem. Fonts in general are not known up front - we've
> had to go with a generic "Roman" or "Swiss". Some formats support Arial,
> others Helvetica, some both. And once you branch beyond the basic latin
> fonts, it gets even more difficult.
>
> Postscript and PDF have the advantage in that you can programattically
> take the size of a string. Traditional formats don't allow you to do
> this.
>
> As a lame workaround, I calculated some font metrics from the standard
> postscript fonts to estimate the string size for roman and swiss font.
> This can be done using FontScale.string_width(). However, this is really
> only an approximation, since it was taken from a single font.
>
> If anyone has any better ideas, I would love to hear them. I don't think
> that linux/un*x/etc. has a standard way of accessing font information -
> at least not a way that is nicely accessible to python.

Hm.  I googled a bit.

Pango seems to offer an API for accessing the font metrics:
http://www.pygtk.org/pygtk2reference/class-pangofontmetrics.html

And as Pango works on top of Xft/fontconfig/freetype, and freetype should be
able to access almost any standard font formats (including both TrueType and
PostScript fonts), I would assume that you can load any about any font and
ask about it's metrics, as long as the font is installed on the system.


        - Eero


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel