John Moran

Welcome to the club. Remaining clueless is usually a sign that the application one is using is working. For those who want to enter XMP metadata now, at no cost, become less clueless later, and be compatible with TMG "when/if" my recommendation would be Pixvue (Pixvue.com) For those who wish to become less clueless now, and enter metadata later, regardless of the cost, my recommendation would be download Pixvue just to read the the Help/Instructions. For those who need a quick opening viewer to go with Pixvue, at no cost, there is Irfanview. But Pixvue should be used for entering the Metadata, not Irfanview, because Pixvue uses XMP fields as primary, but is backward compatible with older IPTC fields. Irfanview seems to use older (frozen) IPTC fields as primary, but does seems basically forward compatible with XMP. As to entering data in Microsoft Picture It!, Microsoft Digital Suite, Adobe Album (free?), PhotoImpact, or ACDSee, or any other photo album software more than a couple of years old - that's probably not a good idea unless you are already heavily invested in the process. As to ICC color profile metadata fields, if you get your pictures developed at Wal-Mart or the drug store, you can remain clueless. But there are a lot of professional photographers who understand and use color profiles, but are just now learning to cope with the XMP indexing of their files. And so it goes. John M.

Hmm. Yesterday I found myself in Windows Display>>Appearance trying to adjust my Taskbar size back to default following some monkeying around in another program. This was after playing with the magnifier and before some buttons disappeared in the other "old" program. And before I read of someone fixing another problem in that same program by unchecking Win9x "Compatibility Mode" There is a note in display Properties about the interaction of non "Windows Classic" themes with older programs. You might have a look in Display properties and see if it is some global setting. Then make sure compatibility mode is unchecked, whereever that is located.

Followup: It appears that Pixvue (Pixvue.com) has the current bases covered as well as any freely downloadable Indexing Utility that works within Windows XP Explorer to incorporate and append Adobe XMP metadata fields (and remapped legacy IPTC fields) to image files could at this point in time. Pixvue seeks to be compatible primarily with a subset of the Adobe XMP property fields needed by individuals for entering searchable subjects, keywords, etc. But Pixvue also addresses the issue of remapping content entered in Adobe properties fields to the smaller subset of default Microsoft metadata properties fields supported by Windows XP for all documents. Pixvue, and other image editors, does this for various image files with varying degrees of support. Jim has pointed out that it is preferable for TMG to access only the Microsoft fields if/when TMG is upgraded to support this feature. A reading - and re-reading - of the comprehensive Pixvue instructions after Jim "explains" things to you can be enlightening. Windows Internet Explorer 7 will reportedly incorporate better support for PNG image files. So, perhaps we can just start entiring our data in XMP/IPTC fields in any photo editor software that is not grossly at odds with Adobe CS and Pixvue - or in Pixvue directly - and be able to search and retrieve it at a later date. If TMG decides to support the feature, so much the better. John M.

I have Microsoft PictureIt!10 (and "library"). I don't see the word, EXIF. It may be that the semantics confusion I am experiencing is due to the camera makers' co-opting the name, "EXIF" for the fields they use. One point of interest is that my Minolta D5 DSLR saves RAW + jpg files of the same image. Windows Explorer Properties treats the jpgs property fields as you have pointed out, by making the Category* field read only, but treats the RAW file as a DOC file and permits writing to the Windows Category field. [Edit: I think I see why the category field is greyed out in MS Explorer Summary (exif) fields. The legacy IPTC (professional photographer) Category Field was limited to three (3) characters for working journalists in the days of small hard drives. Pixvue continues to clip the IPTC Category field to three characters, but Irfanview allows more. However, Pixvue will clip the input to the first three characters.] [Edit2: PhotoImpact 6, a very good photo editor in the Win98 days, describes the included camera maker's properties as "Camera Information (Exif)"] And then there is the difference in exposed (read only) fields for Camera exif data between Windows PictureIt!10 Photo Editor, and the companion PictureIt Library module. And so it goes John M.

Jim- Describing the generic metadata properties fields supported and exposed by Win XP Explorer as "EXIF" fields creates a great deal of confusion for "the rest of us", even if technically correct. Although I do not have a version of Photoshop, I have found no other application that categorizes these Microsoft fields as "EXIF". It may be that that not even Microsoft intended to describe their Title, Subject, Keywords, Comments and Author fields for jpgs as EXIF fields. If we get by the semantics, your suggestion that if/when TMG decides to use any attached metadata fields as an aid to cataloging and captioning that it use the Microsoft fields does seem reasonable. However, I am going to start inserting keywords, etc. into my image files ASAP, and I am going to use the fields provided by Adobe as there is now, and probably will be in the future, far more support for that template. But that does not necessarily mean I will purchase Adobe Photoshop (CS2) or Elements, because Adobe XMP template based Irfanview and Pixvue seem to work just fine for the purpose. Side note. Proprietary Album databases in various photo editor apps, may be just that: Proprietary databases, similar to TMG, and not applications that embed into fields in the jpg files for later cataloging and indexing by Windows (Vista) Explorer. just my $.02 John M.

It is my understanding that EXIF data is created by camera makers inside the camera, may be encoded, if not encrypted, and should not be messed with by users. However, MS Vista will apparently remap some fields from some camera makers to a "standard" display format. The MIcrosoft metadata fields for comments, etc., providied in the XP Explorer file editor may be of a somewhat general nature and not specific to image files. And not all image files are supported with prepended metadata, even by Adobe. "Sidecar" files are used for camera raw files, in particular, to avoid possible data corruption of original files. Microsoft's own digital imaging software does not necessarily support (and expose for viewing) the same fields in the same manner in MS XP Explorer, and perhaps MS Vista Explorer. However, some of the more popular freebie image viewers, such as Irfanview and Pixvue attempt to be compatible with Adobe and not necessarily Microsoft's Digital imaging software apps. And then there was the shot over the bow within the last month (summer 2006) of Microsoft wanting everybody to scrap jpegs and use their new licensable image compression format. Perhaps TMG has enough on its plate to ignore this issue and let its users populate the data fields with other programs if they desire. But it has just become apparent to me after purchasing better digital camera with the potential for creating, in camera, multiple bracketed raw files from a single exposure that I need to come up with a little better indexing system that includes metadata search capability. And perhaps I will need to be more careful about throwing away the thumb and sidecar files, if any, in the folders as well. Have a good day.

Hi Jim- From what I have seen, the best thing that TMG can do in regard to embedding metadata in image files is "nothing". There are enough incompatible attempts at that. However, the FreeImage.dll software downloaded into the TMG 6.0x folder apparently has Adobe XMP and IPTC compatible metadata support, if WG should decide to use it. Reading existing keyword fields off of existing metadata might be a reasonable thing for TMG to do, even if writing is not permitted. As to MS Vista, jpg, and metadata, a Google search on that subject can give you a laugh or two. Also search for the subject of MS very recently reneging on plans to inlude PDF support in Office 2007, if you want another slant on metadata and wrapper wars. Perhaps there was some reason other than innate laziness that kept me from following up on Pixvue (pixvue.com), but on the surface it seems like a useful toy. John M.

Earlier today I was deleting pdf and other filesand ran across an Adobe white paper titled, "Adobe XMP for Creative Professionals". (See link). http://www.adobe.com/products/xmp/ Adobe is the biggest elephant in the graphics jungle, not Microsoft, so it is advisable to lean in that direction, as long as you don't use the freebie Album Software that they try to download along with Reader 7. Each user has his/her own decision to make. TMG is already using graphical image software that is capable of embedding IPTC "keywords", etc in XML. It's just a matter of timing and inclination. For those interested in experimenting with the process, don't forget that the whole idea of prepending XML in jpg files, and others, is so that the jpgs can be opened as text in various text editors to see how each application embeds the data in the search fields.

Is this the "Seinfeld" method? Do you have to pay royalties?

Occasionally, the Win XP SP1/2 upgrades deleted certain files required for 16 bit support. Suggest you try the Microsoft site for replacement files.

Install your printer driver twice, once for letter size. . . .

Although TMG may utilize "Unicode" and Wingdings in its user interface, and design its newer proprietary fonts in such a way that it puts characters in fields reserved for several languages, it only stores genealogy data in one, single, 256 character byte - as far as I know. But the Windows Western single byte English/Latin code page (256 characters) serves most TMG users quite well. MSWord and other text editors default to English/Latin, even if they are Unicode capable, so "almost everything" works. Additionally, MSWord shields most users from many other problems, and even remaps its obsolete proprietary specialty font, MS LineDraw, to the line drawing characters in the Unicode font, Courier New. OpenOffice.org Writer does not remap MSLinedraw, so this is a minor problem for Descendant Reports using those funny box-angle characters in that App. But if we think of the changes we must make in Windows XP Regional Settings to work within Unicode capable Text Editors, such as MSWord 2000+ as "Regional Settings>Retarded" instead of "Regional Setting>Advanced", it makes more sense. This forces MSWord and other programs to use only a single byte subset of the selected Unicode Font in the selected language. Disclaimer: Subject to correction by those who really understand such things, and automatic deletion in a few months at the latest. John M.

It is possible to get marginally acceptable results in Hebrew, and presumably Cyrillic, by making changes in XP> Regional Settings>Advanced. Selecting only one of these languages at a time may permit printing reports in English/Hebrew or English/Russian from TMG. Also be aware of the crude single byte font ER Univers 1251 if all else fails in printing a Cyrillic report directly from TMG screen. Also be aware of potential right-to-left problems with Hebrew in TMG memo fields. Presume you are aware of the existence of PAF 5.2.18.

"Ask not whether TMG has been tweaked for MSWord, ask whether MSWord has been tweaked for TMG." ** The OpenOffice.org suite may export files more compatible with the (current) RTF spec than MS Office itself. However, Microsoft's products have an advantage in being able to recognize and filter "legacy" RTF files, whether or not correctly implemented at any point in time. So TMG/Ooo users should export in (converted) MS *.doc format for the foreseeable future and let it go at that. One talking point of the [sun] Open Document format, is to take [MS] proprietary file structures out of the equation. . . .but that does not necessarily mean that files saved in any easily readable open XML format will necessarily be more correctly implemented than easily readable files saved in proprietary [MS] RTF format. **State of Massachusetts vs. . . . . .

There are also some TMG paragraph style errors in the RTF conversion of certain footnoting that display as apparent font errors in OpenOffice.org Writer. However it seems that the "legacy" RTF output from TMG has been deliberately formatted in this way to be compatible with MSWord. This same type of style error in Ooo Writer, due to "legacy" RTF formatting, may also occur with UFT 3.1. John M.

Yes, Virginia, . . . . seems like there was a thread on Wordperfect footnote margins a couple of forum downsizings ago..... Guess everybody might get around this one by just editing the default TMG Journal ini file and changing the margins there?? Or does that present other problems?? Exporting the Journal file as RTF and editing the margins in the RTF file before it gets to Word is another possibility. However, it seemed that everything worked OK in my version of Word 2002, which was part of Works 2005. One surprise was that there is no selection of printers, which could affect Margin Settings, etc. in Word unless on a network. So be sure to check that the default printer you have selected in Control Panel is the one you intend to use with Word 2002. Change Topic to Chart Printing: Oh yes, one more time for those who are using Large Format Printer Plotters for charts: Word can be used to determine unprintable "margins", up to Tabloid size, by setting all margins to 0,0,0,0. Word will then reset margins to minimums, if all goes well. Results are sporadic with some older HP drivers, but with a few re-boots, a typical Left/Right setting in Landscape Mode on an HP 755CM Designjet seems to be 0.68 inches. John M.

It was possible to recover all the text that was clipped in your file by widening the margins. There does seem to be some inconsistency from that point onward. Use of Edit>Select All may help Also, setting margins in Word 2002 File>Page Setup to 0,0,0,0, all around after using Select All may give better results.

Have you tried "File>Page Setup" menu? Have you tried switching between Layouts on the "View" menu?

If you decide to edit (i.e. play with or highlight) the connector lines on a large chart to show bloodlines, you may have better luck starting at the bottom of the chart rather than the top. Starting at the top of a descendant chart affects connectors of all descendants below, but starting at the bottom only affects the connector to the individual above.

Robin- Thank you for the clarification. Apparently this thread does not pertain to Wintel98 math co-processor problems which may also have been described by some as causing lines to go flying off in all directions. As to the two generation chart described above, as displayed on a large format HP printer driver set to 36x96 inches in landscape mode, with the canvas at 90 inches width, it is possible to see how the horizontal element of doglegs to the child row boxes do change with vertical movement of the child boxes. It seems that the position of the horizontal elements are calculated to be half the distance between certain contact points in the parental boxes and in the child boxes. Thus, a standard display might show all horizontal elements of the doglegs to be shown at three units down out of six total. Nudging just about anything in the chart causes the position of these horizontal elements to be recalculated, so that the final up and down nudging may need to be redone. As to the unprintable paper area on the left and right sides of a large format printout, I could find nothing in two different drivers that suggested the appropriate number. It would seem that trial and error in sizing the canvas versus selecting the paper size might be required. It may be that this is part of the problem that Ron was experiencing: Selecting a canvas size that infringed on the physically unprintable area. As to using "Select All" and nudging an entire small chart across more than five feet of paper space, that did not seem to be a problem, although it took a little time. Holding the "Right Arrow" key down for almost a minute at a time caused everything to jump to the right an inch or so. Using "Select All" and "Cut and Paste" seemed to start things over from scratch at the left upper margin. I don't see this thread necessarily as a grouping problem, but possibly a dogleg recalculation problem, compounded by selection of too large a canvas for a given paper size. Disclaimer: As in prior posts of mine, which may have been "maintained" into oblivion this week by the forum administrator, I do this vicariously. I have no large format printers. John M.

FWIW. Today I found a link to a photography forum which has just been shut down to new posts, so I will not reference it. One poster suggests that the Epson 2200 printer will not print borderless with a matte cartridge installed. Another agrees that the option is not available, but suggests that the Epson 2400 will print full bleed borderless in matte. I happen to have installed the Epson 2200 printer driver for experimentation and found the following in Help.-John M. (quote Epson) " Borderless Prints using the entire area of the paper, allowing you to print documents with no margins and to produce “full-bleed” printouts of images. When Sheet Feeder is selected as the Paper Source setting, this feature prints to all four edges of the paper. When Roll Paper is selected as the Paper Source setting, this feature prints to the right and left edges of the paper. The media available for the Borderless feature varies by printer. See the printer’s Reference Guide for details. Note: If your application has margin settings, make sure they are set to zero before printing. When using this feature with roll paper, you need to use your image-editing software to make the image 4 mm wider than the roll paper. Printing with this feature selected takes longer than for normal printing. When Sheet Feeder is selected as the Paper Source setting, or when Roll Paper is selected as the Paper Source setting and Cut Sheet Mode is selected as the Roll Paper Option, this feature enlarges the image to a size slightly larger than the paper size; therefore, the portion of the image that extends beyond the edges of the paper will not be printed. Print quality may decline or ink may smear in the top and bottom areas of the printout when printing on media other than that designated in the printer’s Reference Guide. It is recommended that you print a single sheet to check quality before printing large jobs. All rights reserved." (unqoute Epson)

The non-breaking space character might be affected by the choice of default language setup and/or keyboard. In setups other than "standard" US Windows Western the non-breaking space may be defined as a character other than Alt +0160. (Although the actual number may be a sum of 0160 plus a multiple of 256)

Ron- Even on letter sized narrative reports, TMG's display of printable area on the page may be overly simplistic. For instance, older Epson Photo Inkjet printers, in particular, may be incapable of printing closer to the bottom edge than 0.56 or at best .25 inches on letter sized paper. TMG may take this into account in some instances, but it is not obvious in the printer setup which may show 0.5 inch margins. Chart printing margins may be derived from entirely different parameters, though it would seem that "parts is parts". In some cases, in competing chart printing software and better Word Processing software (i.e.MSWord). Printer Setup may show that these inkjet printers are physically incapable of printing edge to edge and top to bottom on letter or other sized paper. In most cases, with modern inkjet printers on narrative reports, the results are satisfactory in TMG, even if TMG does not correctly display unprintable bands around the edges, and displays .5,.5,.5,.5 or 0,0,0,0 instead. Regards, John

Sounds like wpt.sp1 may be a Wordport (TMG's 3rd party doc format converter) file? Perhaps it is an 8.3, or too many levels of file folders, problem? Perhaps wpt.sp1 is a service pack and needs to be installed? John

*.emf export is still available in TMG 6.08, but may give poor (low res bitmap)results in most viewers, including Irfanview. Perhaps Irfanview, current version, has a setting I missed in quick look. Thought it worked OK with TMG 5.15. PDF995 may require setting the resolution to 300 dpi or less for long charts in Printer Setup in Control panel, even with TMG 32 bit support. May vary with Pdf995 (or other converter) version on long charts. May also require a little tweaking of printer driver and rebooting of TMG after driver changes in control panel to get single full size chart without multiple letter size pages. John Moran