PiercysEtc

Hi Jim Don't you ever sleep? I can only admire your amazing energy! Thanks for the RTF suggestion. It's an interesting work-round. PDF format is another option, as may be WordPerfect when it arrives. I had thought that DOC format was the only one at present that links to exhibits, as my default app to read RTF files was Wordpad. However, I've tried opening RTF files with OO and, apart from some minor formatting issues, it seems to import exhibits, indices and footnotes perfectly well. Seems that the problem was with Wordpad, not RTF - I should have tried OO and RTF earlier. Hey-ho, that's one more one hurdle successfully cleared, even if it only a work-round. Thanks Jim!

Outside TMG I have been happily using Open Office for a few years now and am now on OO v3.3. I have now installed TMG8 with its capability of producing reports in Win7 64-bit and started preparing printed reports again. Some DOC reports open OK in OO Writer 3.3, some crash OO. I don't remember having had DOC files crash OO before. If I take the DOC reports that have crashed in OO round to a neighbour and open them in Word 2002 and then save them again they now open OK in OO. I could go through all TMG's possible permutations of report and configurations to find just what combinations work and what don't. Of course it would always be quicker to take them round to my neighbour but there is a limit to how much one can take advantage of a neighbour's kindness <g>. Or I could fork out for MS Office, which means going up the MS Word learning curve all over again when I am now comfortable with OO. OO has been very effective and stable with all files except for some of TMG's DOC reports. Has anyone else had the same problem? Better still, has anyone got a solution?

Hi Lori I had a similar situation - apparently irrelevant data from years back. I'm very glad I didn't weed, though, for at least two reasons. My known ancestors are here in England, and you might have, say, two George BISHOPPs in adjacent villages (or even the same village), both farmers, both about the same age, both married to an Elizabeth. One is an ancestor, one is not. The very fact of having them both in the database warns me that I must be careful in identifying which one is which. In England this situation is not uncommon. The second reason is that old, incorrect, data sometimes surfaces on the internet years later. If you have kept the original incorrect data, with notes about the original source and an explanation of why the data is incorrect, it enables you to explain to others why they have incorrect data. So sometimes it's better to train the plants than to weed them! Whoops! There's a third reason for 'training' rather than 'weeding' your database. You may be using TMG for writing a family history rather than just recording genealogy. TMG is surely, by head and shoulders, the best software for this. Sometimes the old 'inaccurate' stories, as well as having a grain of truth in them, reflect the ideas of the family and the times. They are part of the 'social history' of the family. Don't throw away these stories just because they are not literally 'true'; keep them in the database along with your own views of where they came from and how they throw light on the people and times. Best wishes

Thanks for your reply, Jim. Yes, this is what I have found. Maybe so, Jim. The Help files may be unclear, but: 1 The link in the FAQs that Michael referred to says: and later the clarification 2 The TMG Users Guide, UK Edition, says on p283: So it seems that Wholly Genes intend at least one configuration to index in conventional format. It's simply that I have not managed to find that configuration. I can't see any way to do that. I can't either. I'm sure that the TMG support/help desk will be able to, though. I've not heard from them yet, but I'm sure they will sort out where my configuration is going wrong. What are you referring to specifically? I can't find anything that WG says the indexing will do that it doesn't do. All descriptions of the indexing are minimal at best. The descriptions in Help, yes, I agree. However, the description in the two items I have quoted above suggest that the conventional format for a places index CAN be achieved with some configuration of the automatic indexing available in TMG - if you don't mind my referring to them as 'what it says on the tin'. I also find it nearly impossible to believe that TMG, which has such a reputation for doing things right, would not implement a conventional places index among the options. It's almost like driving your new car back from the forecourt and finding that the steering was 'unconventional' - the car turned left when you turned the wheel right... That doesn't sound at all like a TMG feature! Best wishes

This is a thank-you, Michael, for the support you have given me in trying to resolve this problem. There have been no further responses to my postings either here or on the Rootweb TMG list-serve so I've escalated the call direct to Wholly Genes support. I'll let you know their solution. Best wishes

Thanks, Michael. Sorry about the delay in replying; I got dragged away (don't ask!) Yes, it was because that article said that it was possible to generate a conventionally formatted Places index using the automatic place indexing that I have spent so much time in the last few weeks trying to get it to work. As the article says: and In the example quoted above, subfield 1 is Massachusetts and subfield 2 is Boston; the indexing is 'By City (L4)' and 'Largest Element first' is selected. However, when I apply this configuration, I get the equivalent of 'Places:Massachusetts:USA'. In other words, the index levels for me in TMG7.04 appear to go from small to large, not from large to small as the article claims and as you would expect from conventional indexing. There may be occasions when you would wish to find all the incidences of the USA in Massachusets but I am sure there are more occasions when you would wish to find all the incidences of Boston in Massachusets. So either TMG DOESN'T do what it says on the tin and the writer got it wrong (unlikely, since it is an 'official' TMG post), or a bug has been introduced into TMG since the article was written four years ago (again, unlikely since it surely must have been picked up by now by the vast TMG user base) or TMG DOES do what it says on the tin (much more likely, surely) and I have overlooked something obvious. All very frustrating Thanks again, Michael Best wishes Tom

Thanks, Michael. Funny you should suggest that, since I had tested the same thing with the Marriage tag. I had the sentence variables as: [:CR:]He married [PO] <[PARO]> <[D]> <[L]> <[M1]> <with [WO] present>[iNDEX:]Places:< [L6]:>< [L5]:>< [L4]:>< [L3], >< [L2]>[:INDEX] and it did seem to work perfectly well except for two problems. The first was that I have a lot of custom roles so there would be quite a lot of work. Not nearly as much work as hand-indexing all 6,000 plus places, though! So that problem is relatively trivial. The second is that if you have BOTH Names and Places indexed automatically, and another manual index as above, then the Names and Places and the third index are output separately. However, if you have only one of Names or Places indexed automatically, and another manual index, the two indices merge together. There may be a way of outputting the indices separately, but I've not found it. I hadn't raised this issue in my original post in order to keep things simple. If I can just get TMG to do what it says on the tin then both these issues disappear Hope this helps, Michael, and thanks again for your input! Best wishes Tom

Thanks Michael. I had looked at this and if all else fails then I guess this might be a way to go. I don't fancy the idea of indexing over 6,000 places by hand when TMG can do it automatically, though. The Names index works excellently so I'm sure that the Places index will give equally good results if I can just suss out the right configuration . Best wishes Tom

Thanks, Jim, for your very prompt reply. I was trying to say that this (inappropriate 'fudge', as you rightly note) is the only way I have found to order the index into the conventional format. However, the short place template then does what it was designed to do, and orders the place output in the sentence - not what I want! So, to clarify my query, what is the correct way to order the Places index into the conventional format as below? ..Country ....State, City, etc... Thanks again Tom

I'm running TMG 7.04 under Win XP SP3 and exporting a Journal report into Word 2000 with two of TMG's standard automatic indices, People and Places, in the report. The People index works fine, outputting conventionally: ..Surname ....Forename However, problems with the Places index. I have not found a way to order the Place index into the conventional format: ..Country ....State, City, etc... or even: ..Country ....State ......City, etc... without disordering the sentence place structure. For example, using Short Place Field in both Report Options > Indexes > Places and Report Options > Places > Places, and setting the Short Place Template to: <[L6], ><[L5], ><[L4], ><[L3], ><[L2]> I can get the index to order in the conventional format above. However, the variable [L] in the sentence now resolves to the same order, Country, State, etc; the opposite of what convention expects. I've worked through Lee Hoffman's 'Getting the Most Out of TMG' but he only has a small section on Place Indexing and doesn't seem to cover this issue specifically. I've searched Rootsweb's TMG list and posted there but no luck. I must have missed something - can anyone out there who has successfully implemented an automatic Place Index please tell me what I've missed? Thanks in advance. Tom Piercy

A quick follow-up to my last post. I find that if I edit the DOC file manually to change the Courier New font to ALineTMG, after I have imported it into my PagePlus DTP software, it prints out from PagePlus as a PDF file with all the lines fine and dandy. So I now have a laborious manual work-around. But that still begs the question, why does my installation of TMG6 export the Descendant Indented Chart, in Word for Windows 2000 or later, with Courier New font where presumably there should be ALineTMG font, and when ALineTMG is installed? I've just realised that I must have a look and check if similar things happen with a Compressed Pedigree Chart. But that's for tomorrow; it's getting late over here. Thanks for your help. It certainly has helped to move me along towards a solution. Tom

Thanks for coming back on this one, Virginia. Yes, indeed. They look fine, using TMG's built-in PDF converter (Amyuni?). The PDF file properties, fonts tab, shows fonts used as:ALineTMG (Embedded Subset), Type: TrueType, Encoding: Custom Ariel (Embedded Subset), Type: TrueType, Encoding: Custom Ariel Bold (Embedded Subset), Type: TrueType, Encoding: Custom I am just relinquishing my copy of Word 2000 for Open Office 2.4 and at the moment have both on my PC. I was interested to see that when I export the same report directly to a DOC file and open it in Word, it looks fine. However, the lines are marked as being in Courier New and the text in Arial. In Tools > Options > Font Substitution it says "No substitution is necessary. All fonts used in this document are available". When I open it in Open Office Writer, having made no changes, the lines all appear as As and 3s. The lines are now marked as being in MS LineDraw though the text is still in Arial. In Tools > Options > OpenOffice.org > Fonts, "Apply Replacement Table" is unticked. Open it again in Word, and again it looks fine with the lines in Courier New. Etc, etc. No sign in either case of ALineTMG font being used. How can an unedited file appear to have the same characters in two different fonts at the same time, according to which word processor it is viewed in? Both WPs are on the same machine and on the same drive. I don't know if that is in any way connected to the PDF problem, but it seems to be another anomaly with the same characters. When I import the DOC file, unchanged, into PagePlus DTP software, the lines still appear to be in Courier New and the text in Arial. Again, no sign of the ALineTMG font. I'm now more puzzled that ever Tom

When I output a Compressed Pedigree report from TMG to the screen it shows fine with all the lines showing correctly. When I output it to Word it also shows correctly. When I import the Word DOC file into the DTP package it still shows correctly. BUT when I export from the DTP package to PDF the lines are replaced by - (minus), + (plus - at the corners) and | (separator) characters. Checking the PDF file properties shows CourierNewPSMT (EmbeddedSubset), Type Truetype, Encoding: Ansi among the fonts used in the document. The same thing occurs whether Preferences in Acrobat are set to Rendering: Use Local Fonts, or not. Context: - TMG v6.12 under WinXP SP2 - Word 2000 - DTP package - Serif PagePlus 10 I have output from Serif PP10 to PDF both by using the built-in Publish to PDF facility, which appears to handle everything else perfectly well, and printing to PDFactory Pro. Both PP10 and PDFactory Pro have served me well in the past; this is the first problem of this sort I have had with either. I appreciate that the problem may lie somewhere between PagePlus and Acrobat, rather than TMG, but perhaps someone else on the list has had the problem and come up with a solution. Better still, if they have NOT had the problem but still have a solution... <g> Thanks in advance Tom