ROOTS-L Archives

Archiver > ROOTS > 1989-07 > 0616191450


From: Marty Hoag <>
Subject: Re: Printing trees with PAF? From soc.roots
Date: Tue, 11 Jul 89 15:17:30 CDT


************** From the soc.roots USENET/Netnews Group ***************
NOTE: From soc.roots. Please be sure to reply to the original sender
and NOT the forwarder. Thanks! mgh (current forwarder)
----------------------------Original message----------------------------

In article <>
(Leonard Kleinow) writes:

[In response to postings wishing for PAF enhancements which would
generate good-looking graphical descendent trees, with user-specified
formatting options]
>
>I've been thinking about this for a bit too, and while I think I could
>handle the programming part, I have a few questions for the group:
>
> Would you prefer it to read a GEDCOM file, or do it the infinitely
> faster, though intensly machine-specific, way of reading the PAF file
> directly?

If I were programming this or any other genealogical charting functionality,
I would write a stand-alone utility (in C) which read in GEDCOM files into
whatever internal data structure was most convenient, and make the part
of the program which did the formatting get that data by way of a callback
mechanism, rather than have the flow-of-control be based on traversing
that data structure, so that it could be more easily ported to any
representation of the data. Then when I got it working to my satisfaction,
I would mail the sources to the PAF implementors, and suggest that they
incorporate the functionality directly into PAF. After all, even more
efficient than reading the PAF *file* directly is to pull data out of
the in-memory PAF data structures. (I don't believe in calling an
algorithm "infinitely faster" unless there is no faster one conceivable.)

In short, as a *user* it is always more convenient to do things directly
from within one's "main program", in this case, the PAF Family Records
Program. But as a *programmer*, trying to satisfy a user-base on a variety
of platforms, it is best to modularize and separate out the platform-
dependent parts of the program so that the people who control the source
code for the various versions of the "main program" can incorporate it
neatly into all of them.

> I've hacked out most of the file structure. Anyone have the
> "real" version?

When you send your $5 to get the official GEDCOM spec, they send you
the PAF file spec along with it. This spec is oriented to acquainting
their own new programmers with the file format they will be working
with, and is pretty good as internal documentation goes. But I haven't
tried to digest it yet.

> What would be on your wish list? I'd prefer a program that just saved an
> arbitrarily large document in macdraw format, then the user
ould use their
> own judgement to spruce it up.

I would prefer, on the input end, that it read in user-designed forms
from a variety of vendors, and through special conventions on field
names or comments, infer how you meant that form to be merged
with the genealogical data. This is always much more flexible than
a design which uses a dialog to specify how the form is going to look
and then draws everything itself. It is, however, harder to program.

Most forms-design packages take graphical data and add field information
to it. In Claris SmartForm, the graphical data is, I believe, in PICT
format. In Adobe TrueForm (not yet available), it can be in PICT, TIFF,
or Encapsulated Postscript format. The file-format for the representation
of field information is usually available from the software publisher,
since they love to expand their market by having someone else do the
work of supplying packages fully compatible with their software.

For output, I would prefer the option of saving it in a variety of
editable formats, or sending it direct to the printer.

The best-of-all-possible-worlds for me personally would be if it could
read in Adobe Illustrator files and interpret object comments as
relating illustrator text and path objects to genealogical data and
links, and then output editable Illustrator files. But I admit that
users like me are a small segment of your target market.

I imagine for most Mac users that MacDraw format would be more useful.
Since Illustrator can convert MacDraw files to its own format, and
since the features of Illustrator files which cannot be effectively
simulated in MacDraw would seldom be useful in simple charts, it
would not be too much of a disadvantage if I had to go through a
conversion step to edit them in Illustrator.

By the way, the vast majority of form-fillout packages will only
send the output directly to the printer. To allow fine-tuning of
the graphics based on what the data turns out to be is a rare feature,
probably because it is a bigger programming chore to generate files
in the formats of popular graphics editing programs. If you can only
send directly to the printer, you will still be providing capability
beyond what is available now for genealogical data.

> Would you be willing to pay for such a utility? How much? Is there a
> market outside this net, say with an ad in Gen. Computing magazine?

I would be willing to pay about what I paid for PAF itself, maybe a
little more. Say up to $50. I imagine there is indeed a market outside
this net, and Genealogical Computing would be the best place to put an
ad. But general computer magazines would also be good. General genealogy
periodicals probably wouldn't. Your target market is computer users
into genealogy, and my wholly subjective impression is that there are
more members of this market who subscribe to general computer magazines
but not Genealogical Computing than there are who subscribe to general
genealogy magazines but not GC.

I personally may someday hack up a utility which can transfer data
between GEDCOM files and family group charts and pedigree charts
created in Adobe TrueForm, but very much doubt I will have the time
to tackle a feature as advanced as general descendent trees. As you
and others have pointed out, the hard thing about descendent trees is
that the fields cannot have a fixed position. And fixed positioning
of data is pretty much the dividing line between "forms" software
(easier) and "presentation" software (harder). (Note that there are
presentation packages which have tackled a very similar problem
for "org charts.")

(By the way, I am a programmer in the Macintosh team of the application
software division at Adobe. Holly Wanless teaches Postscript programming,
among other duties. She would be a good source if you want to have your
program directly generate Postscript output. I would be a good source
if you want to have it read or generate files in Illustrator format.)

Good luck and I hope you really do it!!

Teri Pettit
adobe!

This thread: