johnbrobb

I, for one, am disappointed that v7 does not provide an option to produce Journal reports with the initial, vital records, paragraph in the standard journal-format order: birth, death (and burial), then the marriage, or marriages, as separate paragraphs. This has been the style used by virtually all of the major journals (NEHGRegister, NGSQ, TAG, etc.) for decades. TMG persists in outputting the vital records tags in the order Birth(group), Marriage(group), Death(group), Burial(group), all in one paragraph, and my plea for such an option several years ago continues to be ignored. TMG's eccentric version might seem more logical, since it follows the chronological sequence, but it muddies the introduction to the sketch in practice. There is a reason for the standard journal convention. The sketch is about a subject's life, and the reason all the vital stuff is presented up front is to provide a framework or overview of the whole of that life. If chronology were all there were to it, the death- and burial-group tags would come last in the sketch. I think anyone who reflects on this can see that a life laid out that way, in strictly chronological order, would be much harder to grasp as a whole. That is the reason for the standard convention. Starting the subject's sketch with birth and death information alone (and usually in one sentence) provides a concise definition of his lifespan, tells us where he started and where he ended up, and thus provides a uniqure identification of who he is. We begin to think of him as John Smith born in 1710, or John Smith from Kent, or whatever. Next, in progressive chronological tranches, we are presented with the constituents of the subject's life. First, the all-important marriage framework, with multiple marriages in chronological order, and at least one separate paragraph for each, and only then the set of other events of his life, in their chronological order. Finally, we are given the children of the marriage(s), in chronological order of their birth. By placing the death information after the marriage group tags, which often requires a great deal of text, running to multiple paragraphs, it loses its connection to the birth information, and the introductory lifespan framework of the subject is lost. Ironically, the "Concatenating Sentences" section of Help uses the concatenation of successive birth and death Sentences as an example, and this would indeed be the most valuable use of this feature, except that TMG's Journal format precludes any such concatenation because the succession is interrupted by the marriage group tag(s). The result of not having at least a Journal Report option to output vital records in standard journal format, is that I have to hand edit in my wordprocessor the opening paragraphs of each and every Journal sketch I produce. I hope that other users who would like to be able to conventiently produce journal reports which are standard in this important respect will join me in requesting such an option at an early future date.

Thanks, Jim (and Terry). We can only hope. I wouldn't have picked this up if I hadn't taken the precaution of producing the same report in both v7 and v6, and comparing them line for line until the output was discrepant.

This is to alert other users of TMG of a change to the syntax of embedded citations which may truncate their citation detail. According to Bob Velke, one of the "improvements" to v7 was announced thus: o Embedded citations now support inclusion of the citation memo, e.g., [CIT:]124; citation detail; citation memo[:CIT]. What this means is that if your citation detail text happens to include a ";"(SEMICOLON), that semicolon and any text following it will be treated as a citation memo, and will be truncated from your reports. I do not know of any way of fixing this problem except by going through all my embedded citations, scanning for citation detail text which uses includes a semicolon, changing that to some unlikely-to-be-used token (say "$%"), then creating a macro in the wordprocessor program to which I export my reports to change "$%" back to the ";" I originally intended. If anyone has any better idea about how to fix this problem, I would be grateful to know of it.

When the husband and father dies and the wife remarries, the TMG Journal descendancy report format (the one which emulates such publications as NEHGR, TAG etc.) doesn't show her children by her second husband, even though they are half siblings of her previous set of children and usually continue to be part of her second marriage family. This creates a gaping hole in the family history. It might be argued that since Journal descendancy format is nominally a series of linked sketches of individuals (usually, but not necessarily, male), the children of the spouse of such a person don't belong in the sketch, because they are not his descendants. But we modern genealogists have learned (I learned originally from the introductory material to Robert Charles Anderson's Great Migration series) that for analytical purposes, every family should be reconstructed in full, complete with hypothesized birth dates for each child, even where evidence is lacking. As in the manner of scientific theorizing, this creates an extensive hypothetical structure which can the more easily be tested by exposing it to new evidence, refined in the light of that evidence, then exposed again. Karl Popper, the pre-eminent philosopher of science of our era, has shown that the bolder the hypothesis, the better, because it is the more easily falsified, thus accelerating the advance of positive knowledge. Perhaps even more important, nearly all of us would agree, I'm sure, that the enterprise most of us are engaged in is the reconstruction of family history, not the mere tracking of bloodlines. Thus, the subject sketches of the modern journal report, where the subject is the launcher of a family of his/her own blood, also admit adopted children; report any subsequent marriage(s) of his/her spouse; and they also include the children of that spouse by a subsequent marriage. Examples of the latter will be found at NEGHGR 157(Jul2003)205-206, and TAG 81(Jul2006)218-219. But the TMG Journal format does not follow the standard family-oriented implementation of Journal format in this respect, and at present the half-siblings of a family can only be added, laboriously, after the fact, during the wordprocessor editing phase. Moreover, this task has to be performed for each such family (and all the families in one's database with children of a second spousal marriage therefore need to be itemized and tracked), and repeated every time a new version of the report is created. If this is not done, the Journal format, at least for these families (which are admittedly somewhat infrequent) fails of its purpose. I therefore believe that incorporating the children of a subsequent marriage of the non-subject spouse into the sketch of the subject spouse, is a necessary addition to the TMG "to do" list. John Barrett Robb

Just as a followup to my previous post, I would like to share what I have just learned about non-breaking space characters. I learned this by trial and error, and since there is no online Help documentation which covers what I am about to say, perhaps this may help others who are equally at sea about this. I was trying to eliminate the spaces between date parts, i.e. I prefer "12Oct1934" to "12 Oct 1934". I prefer the concatenated format mostly just because it prevents dates parts from being separated by end-of-line breaks. Since TMG itself recommends this practice, and mentions non-breaking space characters, represented by the "[:NB:]" token, but without describing what this means or what its effect is, I have been playing around with it, as a possible solution to my problem (since TMG doesn't offer a custom date template to accomplish this). So anyway, I began by changing the non-breaking space character on the Reports->Options->Miscellaneous screen to something visible, namely "_" (the underscore character). I tried entering "[:NB:]"s in date fields but they just produced irregular dates, which suggested to me that they might not "take" anyway, since the program was unable to recognize these as nugatory tokens. In any case this wouldn't have been a practical solution to my problem - I would have had to change thousands of dates by hand. However I pumped out my journal-style report to my wordprocessor, WordPerfect, and, lo and behold, "_" characters were now interpolated between all my interior date parts, e.g. "12_Oct_1934". Thus, I could simply delete all these underscore characters (as long as I forebore to use them in the regular course of events), but wait - TMG also interpolated these "_"s between the word prefixes to dates, e.g. "say_12_Oct_1934". What's more, it also replaced all my TMG-generated space indents with underscores, so that my paragraphs (in WordPerfect) began, eg. "____Fourscore and seven years ago...". However, since I already have a several hundred line WP macro to tweak and clean up the stuff TMG dumps out as wordprocessor text, it was a simple matter of adding a dozen or so search & replace macros to first convert the specific combos I wanted to interpolated spaces, eg. "say_12_Oct_1934" to "say 12_Oct_1934", then to delete all remaining underscores. So I am once again a happy camper, though not particularly impressed by TMGs low-level design, and still less with its documentation. But these are old complaints, which I have been articulating since v1.0.

Well I am interested in such an "enhancement", except that I would call it "correcting a design flaw". A truly sophisticated program would allow the user to specify his own date format, using, say, Backus-Naur tokenization, e.g. "23 (9) 1643" could be specified as a custom template (available at data-entry time from a right-click pulldown menu) by "<dd>_(<m>)_<yyyy>" where the symbol-strings in angle brackets represent standrd date parts (in this case all numeric date parts) "(" and ")" are literal text characters (they could be any characters except:) "_" which is reserved to represent the standard Space character Then the date could be entered (and if desired, displayed) in its native format, but also processed internally like any other date. As a programmer and software designer of 30+ years experience, I can tell you that it wouldn't be that hard to implement such a feature, and it would, in one fell swoop, address a lot of related problems with custom field formatting, not just with dates. For example, the reason I am here is that I am looking for a way to accomplish TMG's stated desiderata of preventing dates from breaking at line ends. The recommended way to do this is to insert [:NB:]s into dates, which seems impossibly cumbersome, and in any case can't be done in the standard date fields which is where most dates are entered. And I've only resorted to exploring non-breaking spaces as a workaround for what I really want to accomplish: specifying my dates as "<dd><Mmm><yyyy>", i.e. without "_"(space) separators. I have been trying to accomplish the same thing with WordPerfect macros, by eliding space surrounding month parts ("Jan", "Feb" etc.), but this doesn't work for dates in which there is no specified day, or for the few cases where "May", for example, occurs as a regular word. Maybe I can come up with an even more extensive macro which will eliminate spaces only between, say "May" and space-separated numbers, but there is no reason the user should have to deal with this stuff. The whole point of programming is make things easy for the user by doing the programming once, in a general way, which can accomodate all reasonably conceivable user demands.

To be more precise, when I check (enable) the Journal Report /Source option, "Combine consecutive footnotes", the "Disable 'ibid." option is grayed out (and set to checked at the same time). It turns out the interpretation of this ambiguous double negative is that enabling "combine" disables "ibid". How do I do both?