John Moran

Metadata entered in the Comment, Subject, etc. fields in Windows XP Explorer's internal Photo Editor is embedded in a page prepended to the JPEG, along with EXIF camera data. Metadata entered in similar, but more expansive, data fields in accordance with the IPTC (Professional Photographers) template is similarly prepended to the previouslly prepended Microsoft data in the JPEG file. Note: These data fields go with the JPEG, so images uploaded to the web may contain these embedded fields. This site may be of interest: http://www.controlledvocabulary.com/imaged....html#standards And also this Breezeblower Photo Editor site may be of interest to those with high end (RAW) cameras. http://www.breezesys.com/BreezeBrowser/help/preferences.htm As to finding applications with utilities to properly search these data fields, that seems to be a work in progress, across the board. Use of XP operating system for a general search can bring up unique names or keywords, perhaps, but not abbreviations. If you live in Canada (CAN), but have relatives in California (CA) and use a Canon camera you may find some searches useless. As to Irfanview's implementation of the IPTC template, it is straight forward and seemingly freeform. If you open that JPEG created in Irfanview and then download a trial version of, say, ACDSee, with its fancy interface you may have a different reaction. After an hour you may find yourself rushing to uninstall ACDSee, with its supposedly searchable internal Album database utility. Might as well stick with TMG for your album tagging if you can't embed data fields in the JPEGs themselves. FWIW, John M.

Maybe. It is my understanding that The Master Genealogist makes heavy use of "leading spaces" in the Descendant Indented Chart. Perhaps you could try using U+00A0(0xA0):No-Break Space(s) in your other reports. Good luck, John Editing Note: There was a thread on non-breaking spaces on the TMG-L list a couple of years ago. I believe it concerned HTML web pages. It was both educational and confusing to me because most (USA) users referred to Alt+0160 as the required keystroke, but one user claimed it had to be Alt+416. Drove me nuts trying to figure it out. Turned out the user of Alt+416 as a non-breaking space was using a computer and keyboard set up in English/Hebrew in Israel. (An extra 8 bits worth of characters were added to 160 to make it 416) However, it may be that Win XP will remap Alt+160 as a NBS in languages and keyboard setups used by most TMG users. FWIW. Alt+160

MS Word dominates the Text Editor and Office Suite market. If you currently have a recent version of MS Word and are familiar with *Styles* (see help in MS Word) you may already be using the feature to create and select from different paragraph setups within Word documents. If not, see MS Word Help on the subject of Styles. But if you only have an older version of MS Word, it may be worthwhile to download the free Office Suite software application from the OpenOffice.org web site. (200 mb!!!). OOo Writer, the text editor in this suite handles paragraph styles somewhat differently from MS Word, but the competition has resulted in better paragraph style control in both programs in recent years. The Style feature of either program may help with the margin changes you desire.

Sounds like a good excuse to download the new release of OpenOffice.org writer to read up on "Styles".

Free AVG anti-virus (and probably others) is really getting carried away with e-mail and other script scans these days. (Perhaps it is to let us know how valuable they are before Microsoft cuts them off at the knees with the release of Vista.) Try temporarily disabling the AV software to see if that is the problem.

Can't help with the "keying", but if you meant "source" instead of "spurce" someone will jump in pretty quickly. Good luck, John

It has been my experience that jpg image files wrapped in PDF files typically extract at low "monitor screen" resolution from Adobe 7 Reader. However "low budget" PDF editing utilities, such as PDF995edit may be able to extract the jpgs at full resolution. John

I haven't looked, but is it possible to fully populate an Ancestry Box Chart and then change the font color in certain boxes to white so that names do not print?

In the TMG-L August 2006 archives, there is a short thread on "surprise" or ""hidden" borders in charts sent off for printing by TMG users. In quick experiments I just performed with TMG's Sample Database with PDF995 (but not the Wholly Genes PDF Writer) selected as the printer driver at 36"x108", it is possible to see the cause and effects of this phenomenon - if one does enough mousing around. Files saved and reopened as *.pdf extension from Visual Chartform with Pdf995 driver seem to open as intended, albeit with potentially lower resolution.... Files saved and reopened as *.vcf may give unintended border/margin results if customer and operator of large format printer are not on same wave length. FWIW.

OK. I'll admit I'm winging it here. I seldom actually crank up TMG or any other Genealogy program except to experiment. Having said that, I have at one time or another set my Regional Settings and/or languages to Vietnamese to use it with Family Treemaker, and have also selected Hebrew to see the right to left problems problems in TMG memos. I became interested years ago when some guy wanted to use UFT with Cyrillic. By accident, before I uninstalled the Hebrew support "recently", I found that FTM memo fields seemed to handle the right to left script in Hebrew correctly, although TMG did not - as of a few updates ago. But it looks like the Vietnamese character layout is just a slight modification of the Windows Western layout, so if you have no other persons in the database requiring German or French characters (and perhaps sorting conventions), you might be able to get by with Vietnamese only. That's about all I know about the subject. You get 256 different characters to play with (up to 0xFF in hex) in your TMG database. You can think of each character as being whatever you like, as long as you have a subset of a single byte "font" to print out each of the characters you actually use. As to why you cannot use different languages simultaneously in TMG as you can in M$ Word, I gue$$ it all boil$ down to dollar$ and cent$, and workload, and perceived demographics of the respective customer bases. TMG does not support "unicode" at this time. John

In WinXP, select Start>>Run type in "Charmap" without the quotes Repeat to start two instances of Character Map. Use Mouse in blue at top to separate the two Displays. Set one Charmap to Windows Western. Set the other to Windows Viet Nam. This will let you see what you are up against: Namely two different character sets. Might as well be English vs Cyrillic or Greek. TMG only supports one 8 byte (256 character/font) set at a time. But maybe you can see the location of the characters you need and then fake it in Word by making two different printouts with two different languages selected, and then interleaving the sheets and throwing away the extras.

This is probably unrelated to missing memo problem, but there have been reports in the past of erratic printing of FGS graphics due to printer resolution mismatch. If you are printing direct from TMG, try setting the printer resolution to 600 dpi or less.

I was thinking of the genealogist taking a long walk to a specific location away from the automobile with a portable gps unit capable of maintaining a lat/long vs. time log "in hand." Edited

. Time marches on. If the genealogist in the cemetery remembers to write down the lat/long of each photo s/he takes, yesterday's standalone GPS unit is fine. Otherwise a running breadcrumb trail (waypoint log) referenced to real time can come in mighty handy a week later back home. Taking an occasional closeup picture of the GPS LCD display (if any) and a timepiece is probably a satisfactory method for most of us.

I am going to jump in here on the subject of creating GPS data logs vs. location. At this point in time many, if not most, small point and shoot digital cameras record time of exposure to the second. Assuming that the user has a reasonable clue to the actual time of day and time zone setting, this data can be useful many years later. Taking a picture of a clock or wrist watch (with a scribbled note of the time zone next to the watch) every now and then can go a long way toward establishing meaningful time comparisons at a later date. Software currently exists to compare camera time hacks to GPS tracking logs within a couple of seconds to put time and place together. But when it comes to logging and saving the gps tracks, the state of the art is not so good. This is particularly true for consumer grade handheld units. So anyone considering purchasing a handheld should do their homework first. Sony has just come out with a unit for that purpose, but broke no new ground that anyone on the camera forums seemed to be aware of. Whatever standalone handheld GPS unit is purchased should have the capability of both downloading and uploading from a laptop to be useful. Cell phones will probably lead the way, but it may be a few years before everything comes together. Today's GPS units require much more battery power than either cell phones or digital cameras. Yesterday's hadheld GPS units are obsolete.

Are you using a wired mouse plugged into a port? Do you have a hotel plastic "Do Not Disturb" sign cut to fit over the Thinkpad mouse pad?

On the subject of embedding searchable keywords in various documents, it might not hurt to take a look at the current Wholly Genes PDF Writer. The Amyuni PDF writer in TMG 6.09 appears capable of embedding searchable metadata, including keywords, in both Adobe XMP and Microsoft fields. The metadata in the Adobe fields is exposed in Adobe Reader 7. The metadata in the fields from both Adobe and Microsoft is exposed by right clicking on the pdf file and selecting Properties. The properties metadata is exposed in a manner similar to the one used by Pixvue for digital image files. The entire computer can be searched from Adobe Reader 7 for XMP metadata embedded in pdf files, as well as pdf content data. Only the Pixvue Gallery folder, which must be created by the user, can be searched by Pixvue for XMP/IPTC metadata in image files. Other applications are available to perform similar searches of image metadata.

Try "printing" to the Wholly Genes PDF writer. It appears that this "virtual printer" might generate a pdf file for you with a "virtual" sheet size of up to 36x108 inches @ up to 600 dpi. (might work at 1200 dpi?, but 600dpi is more universal, and 300 dpi will create a smaller file for just emailing and viewing.) Please go into Control Panel>>Printers and faxes to set up the pdf writer before generating the chart from VCF.

Exhibit Properties>>Info __Ctrl C (copy last exhibit folder path) Right Click>>Insert New Image>>Select Existing File __Ctrl V or Right Click>>Paste (paste in last exhibit folder path) >>Open Repeat as required. Close enough?

Marion- I don't know how far to carry this thread that you bumped two weeks ago, but I have just discovered a new twist in discontinued MS Picture It! 10 Library. This may also apply to MS Digital Image Suite. PictureIt! Library, the gallery/album searchable viewer will sort and display certain image files, including jpgs, by various schemes, including date and keywords it enters into the MS properties fields. No big deal, except that it will also remap and search by keywords entered in IPTC/XMP fields via Irfanview or Pixvue. But once you add one keyword in a jpg file from inside Picture It!, it will no longer expose nor use keywords in IPTC/XMP fields. No big deal. It doesn't erase the IPTC/XMP keywords and it seems to be fail safe, but it just adds to the confusion. [Edit: Can be reversed, and might be a useful method of pasting keywords into MS metadata keyword field.] John M.

As I interpret the Googled tea leaves re: Vista digital image management (DAM), "Vista Gallery" will provide a user experience roughly equivalent to XP with the latest version of MS Digital Image Suite. In Vista, native support for embedding XMP/IPTC fields will not be provided! Keyword search in Gallery will be, what was the word? "overutilized?", as in existing MS Picture It! and Digital Image Suite, for XP. In short, Pixvue and IMatch will not be put out of business. The Vista Gallery will be maintained by copying full folders of image files to the top "gallery" folder. Selection of just a few files from the master folder for gallery indexing will not be permitted to protect the user from him/herself. This will mean that Vista Gallery users will be required to maintain at least three sets (hierarchies) of image data if they wish to cull out the bad shots before placing them in the gallery. In short, business as usual with a "free" copy of MS Digital Image Suite included in Vista. But also with a Vista file system limitation of only one 64k block of data for Adobe and others to play with for XMP/XML purposes (as of January). (NTFS apparently allowed use of more than one 64k block. Dunno about that. Above my pay grade.)

"PixVue is an image management application for Windows. PixVue provides a series of extensions to the Windows Explorer, enhancing its functionality as it relates to digital images." (As quoted from Pixvue Help) What I found after getting past the basic positve Explorer experience with Pixvue, is that it includes a user friendly, boolean searchable, "Gallery" consisting of those folders and files you choose to put in said "Gallery". You will have to do a limited amount of preparation work in Windows Indexing Service to set this up, but it is clearly explained and optional. Caveat: Just don't go a little too far while in Windows Indexing and try to remap the XMP property fields into the "Windows metadata" fields to be compatible with the "new" TMG just yet, unless you know what you are doing.

Ah so. Reminds me of a long ago experimention with another widely distributed genealogy program. What was the name? I forget now. Similar Lead Tools "third party" functionality. No matter what format the image files were in upon import, they seemed to be opened as a bitmap and then resaved. So it's better to start with original images in bitmap or a "lossless" compression file format for best quality internal file. But when printed to paper, it doesn't seem to matter.

What happens if you wrap your OCR image files in a PDF file and then you want to unwrap them? Hmm? Copy/Paste from Adobe Reader 7 will only take it to the Clipboard at screen resolution of 72/96/120 ppi at best! You will need a PDF editor capable of working with the embedded image file type. Pdf995edit can extract jpg images at original compressed quality, but may not be capable of handling PNG files. FWIW John M.

This PNG discussion brings to mind some reading and experimenting another genealogy program user and I did a few years ago. All implementations of PNG were not the same! Adobe Photoshop at the time was reported to be using an inferior compression method that coincidentally created PNG files that compared unfavorably in size with Adobe proprietary files at the time. http://en.wikipedia.org/wiki/PNG#Comparison_with_TIFF Photo Editors other than Adobe produced different varieties of PNG that were not necessarily of the same quality. A little searching on the subjuect of PNG file sizes and alpha channel might be in order. As to putting a PDF wrapper on OCR files, those who use professional quality Adobe PDF generating programs may have options that users of Ghostscript based "pdf creators" do not have. Many of the free or inexpensive pdf creators will provide only jpg image compression, and there may be little control of even that. From what I have read, Ghostscript developers were headed toward incorporating PNG a few years ago, so there might be a few inexpensive PDF creators that actually use a PNG version of Ghostscript. But the Tiff format was apparently also upgraded in the last few years. When combined with limited PNG support in Microsoft browsers, widespread acceptance of PNG (at higher bit levels?) was set back for a while. Doesn't seem to matter much for b/w OCR, though. FWIW John M.