RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
This is my understanding of the process and I believe the issue is OLE although one of the problem files we couldn't pin down an exact problem. So I think I know what the coarse of action will be - remove all uses of OLE. But its hard to understand why these documents seemed to work under dzBatcher doing exactly the same steps. Its this aspect that may give me trouble in trying to convince people to not do this. Thanks everyone for the insights provided. ..dan *** Dan Vint Engineer Sr. BEA Systems Home: 510-522-4703 (generally working from home) Office: 408-570-8554 IM Yahoo: dvint1_99 [EMAIL PROTECTED] From: Fred Ridder [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 5:41 PM To: Dan Vint; framers@lists.frameusers.com Subject: RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics Dan Vint ([EMAIL PROTECTED]) asked: To support OLE reading the graphic back in, do I need to have the original application? This is the primary difference I could think of. Out build machine might not have Office for something from Word for instance, but that would be common on our personal machines. As far as I know, OLE requires not only that the originating application be installed on every machine that will use the file, but that it's the same version of the tool and is installed in a directory of the same name in the same relation to the FrameMaker installation. It's an unreasonably tall order unless you have a *very* methodical (and dictatorial...) IT department, which is why it is so risky to use OLE embedding rather than simple file linking. Fred Ridder Peek-a-boo FREE Tricks Treats for You! Get 'em! http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
Dan Vint wrote: As these files are saved back to Native (via FrameScript) I'm getting the following error/warning from Frame: SnagIt.jpg This has occurred on 4 different books, not sure if they have been all Frame 6 or not, but this last one is 6. One of the books we couldn't track the problem down and had to rebuild it. The other 3 seem to all be related to embedded OLE graphics. Is there some known problem with OLE embedded graphics or an issue with saving from MIF back to Native? I haven't a clue about your MIF washing process, but why in the world would you use OLE, with all its overhead and potential problems, to import JPEG graphics, for which FM has a filter? Use File Import File, not File Import Object. For that matter, don't use JPEG for screen shots (I'm guessing from the SnagIt reference that that's what you're dealing with) -- it's a lossy format best suited to continuous-tone images like photos and poorly suited to reproducing sharp edges and text. Better choices are PNG, GIF, and TIF. FM can import all three file types -- no OLE, please! :-) HTH! Richard -- Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 -- rgcombs AT gmailDOTcom 303-777-0436 -- ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
Hi Dan, One thing to consider: it may be better to do your string replacements in FrameMaker without going to MIF and back. Since you are using FrameScript, you may be able to do these replacements in the binary file (depending on what exactly you are doing). Rick Quatro Carmen Publishing 585-659-8267 www.frameexpert.com I have a process in which I run both Frame 6 and 7 documents through an automated build. One step in this effort is to save all the files to MIF and do some string replacements on the file, then save that result back to Native form so I can print the documents. Note that is this case no substitutions were made, so it is just a round tripping of the files from MIF to Native As these files are saved back to Native (via FrameScript) I'm getting the following error/warning from Frame: SnagIt.jpg This has occurred on 4 different books, not sure if they have been all Frame 6 or not, but this last one is 6. One of the books we couldn't track the problem down and had to rebuild it. The other 3 seem to all be related to embedded OLE graphics. Is there some known problem with OLE embedded graphics or an issue with saving from MIF back to Native? ..dan *** Dan Vint Engineer Sr. BEA Systems Home: 510-522-4703 (generally working from home) Office: 408-570-8554 IM Yahoo: dvint1_99 [EMAIL PROTECTED] ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
Dan Vint ([EMAIL PROTECTED]) asked: To support OLE reading the graphic back in, do I need to have the original application? This is the primary difference I could think of. Out build machine might not have Office for something from Word for instance, but that would be common on our personal machines. As far as I know, OLE requires not only that the originating application be installed on every machine that will use the file, but that it's the same version of the tool and is installed in a directory of the same name in the same relation to the FrameMaker installation. It's an unreasonably tall order unless you have a *very* methodical (and dictatorial...) IT department, which is why it is so risky to use OLE embedding rather than simple file linking. Fred Ridder _ Peek-a-boo FREE Tricks Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
I'm on the build side of the house and its my writers who pick and choose what they use in terms of formats. I have to react and support what they do or provide workarounds. I'm not sure if OLE is 100% of the problem or not, we have only had a few instances of this problem in the thousands of files that are in our build process. This may have been going on for sometime, but our old build process wasn't displaying these same errors, so that is one curiosity about all of this that bothers me the most. It would be a different story if suddenly I had a new writer that was starting to do things this way, I would be more willing to say DON'T DO THIS. But as this is something that has been going through the previous build with no detectible problems it makes it a little harder to set this rule. Ultimately, if I can't make the build work, we will come back and say don't do this and when we find instances of embedding, we will have the writer rework the files. FYI, I haven't really paid attention to the formats that we use for graphics, I just used the jpeg as it was what the tool (SnagIt) produced I think by default. ..dan *** Dan Vint Engineer Sr. BEA Systems Home: 510-522-4703 (generally working from home) Office: 408-570-8554 IM Yahoo: dvint1_99 [EMAIL PROTECTED] -Original Message- From: Combs, Richard [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 8:08 AM To: Dan Vint; framers@lists.frameusers.com Subject: RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics Dan Vint wrote: As these files are saved back to Native (via FrameScript) I'm getting the following error/warning from Frame: SnagIt.jpg This has occurred on 4 different books, not sure if they have been all Frame 6 or not, but this last one is 6. One of the books we couldn't track the problem down and had to rebuild it. The other 3 seem to all be related to embedded OLE graphics. Is there some known problem with OLE embedded graphics or an issue with saving from MIF back to Native? I haven't a clue about your MIF washing process, but why in the world would you use OLE, with all its overhead and potential problems, to import JPEG graphics, for which FM has a filter? Use File Import File, not File Import Object. For that matter, don't use JPEG for screen shots (I'm guessing from the SnagIt reference that that's what you're dealing with) -- it's a lossy format best suited to continuous-tone images like photos and poorly suited to reproducing sharp edges and text. Better choices are PNG, GIF, and TIF. FM can import all three file types -- no OLE, please! :-) HTH! Richard -- Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 -- rgcombs AT gmailDOTcom 303-777-0436 -- Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
Thanks I'll give that tool a review. Upon further testing, I'm wondering what the requirements are for supporting OLE embedded graphics. I was able to load and process this file on my local desktop both via the FrameScripts and by hand. But when I took this to my build machine it failed with the scripts and it failed by hand. To support OLE reading the graphic back in, do I need to have the original application? This is the primary difference I could think of. Out build machine might not have Office for something from Word for instance, but that would be common on our personal machines. ..dan *** Dan Vint Engineer Sr. BEA Systems Home: 510-522-4703 (generally working from home) Office: 408-570-8554 IM Yahoo: dvint1_99 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy H. Griffith Sent: Tuesday, November 06, 2007 8:19 PM To: framers@lists.frameusers.com Subject: Re: Possible Frame6+SGML Issue only MIF to Native and OLE graphics On Tue, 6 Nov 2007 13:25:09 -0800, Dan Vint [EMAIL PROTECTED] wrote: I have a process in which I run both Frame 6 and 7 documents through an automated build. One step in this effort is to save all the files to MIF and do some string replacements on the file, then save that result back to Native form so I can print the documents. Note that is this case no substitutions were made, so it is just a round tripping of the files from MIF to Native. That has always worked flawlessly for every version of Frame I've used, which goes back to Frame 3 on SunOS... ;-) As these files are saved back to Native (via FrameScript) I'm getting the following error/warning from Frame: SnagIt.jpg This has occurred on 4 different books, not sure if they have been all Frame 6 or not, but this last one is 6. One of the books we couldn't track the problem down and had to rebuild it. The other 3 seem to all be related to embedded OLE graphics. Is there some known problem with OLE embedded graphics or an issue with saving from MIF back to Native? There shouldn't be. OLE objects are preserved in MIF just as any other imported graphics are. However, since they are embedded, and not referenced, they are subject to the same troubles as other embedded graphics, which includ potential loss of data if there's inadequate disk space for the temporary files Frame generates when saving them. Check your Windows system environment variables for the TMP and TEMP directories, and make sure the drive referenced in them is not close to full. Aside from that, one cross-check you could try is to use Wash via MIF, which is a File-menu item added by the Mif2Go plugin. It works fine for both books and individual files in the demo version, which is free: http://www.omsys.com/dcl/download.htm You only need to install the plugin files, m2rbook.dll and m2gframe.dll. Wash works by saving as MIF, then reloading the MIF and saving as Frame binary. If you don't see the same problem there, you may want to check the FrameScript code to see what options you are using for the saves to MIF and to Frame binary. I don't know of a particular one that would have that effect, but it's not impossible... HTH! -- Jeremy H. Griffith, at Omni Systems Inc. [EMAIL PROTECTED] http://www.omsys.com/ ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/dvint%40bea.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
A relative path of ./filename is ok, but a relative path of ../../product/version/filename is not. These are on the same drive. So I guess if I pass some information in about the actual book I might be able to work this out but the two paths are going to be very similar: ./filename will look like c:\edocswork\wlp\admin\admin.fm While ../../ales/docs30/userguide/file1.fm is going to look like: C:\edocswork\ales\docs30\usergudie\file1.fm So I would need to know that I was working on wlp and admin to detect that this was a ./ path. Also depending upon if I was to process this document at the root level or down a couple of directories I'm not sure what ../../ is going to translate to if I'm at the C:\. Anyway, I could probably do this, I was just surprised at the result I was finding for a pathname. It wasn't going to be a direct string compare of ../../ to make my fix, so I put it aside in FrameScript. My other substitution for DOCROOT will probably be easier than this relative path because of the way Frame/FrameScript is presenting the information to me, I was just less sure of the places this could occur. My other error may force me to go back in and reevaluate this option, but for now its working for the task its supposed to do. Thanks for the ideas though. ..dan *** Dan Vint Engineer Sr. BEA Systems Home: 510-522-4703 (generally working from home) Office: 408-570-8554 IM Yahoo: dvint1_99 [EMAIL PROTECTED] -Original Message- From: Rick Quatro [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 10:02 AM To: Dan Vint; framers@lists.frameusers.com Subject: Re: Possible Frame6+SGML Issue only MIF to Native and OLE graphics Hi Dan, FrameScript (and the FDK) always report the absolute paths to imported graphics, text insets, and external cross-references. You have to compare the path of the current document to that of the imported graphic to determine if it is a relative or absolute path. The rule is fairly simple, though; if the document and graphic are on different drives, then the path is absolute, otherwise the path is relative. Again, FrameScript and the FDK will always show the entire absolute path. There are times when it is useful to see a relative path. I have a FrameScript function that takes a source path and a target path and builds a relative path from the source to the target. Rick Quatro Carmen Publishing 585-659-8267 www.frameexpert.com My first attempt was to try and replace the process that was here under dzBatcher so that is what I have ended up with so far and this issue might be enough to try a different direction. Ultimately I hate these sorts of problems that I can't find an explanation for. Why did dzBatcher work with no problem on these files, but my new FrameScript environment is catching the issue. Not knowing what dzBatcher was doing under the covers it might have been somehow ignoring this problem and we just never detected the problem - oh well. I was trying your recommendation for a different set of replacements that occur in HyperText links. Actually the process I was trying this approach on was for some books that didn't follow the guidelines for linking and uses the string replace process that is causing troubles I've reported here. So this one set of books creates hypertext links in a non-standard BEA way and linked directly to books in outside directories. Normally we have the writer insert DOCROOT/product/version/filename and my string replace would insert something for DOCROOT that was appropriate for the HTML or the PDF we generate. These books instead of using DOCROOT, used a relative path, so something like ../../product/version/filename. So I was trying to replace the ../../ with the same info I would replace DOCROOT with. When I looked at these with FrameScript, the path that showed up was expanded based upon the file system (machine and file directory) the file was being processed on. So instead of seeing a relative path, I was getting a resolved path based upon where the file was in its current location. So instead of seeing ../../ I was getting something like c:/edocswork/ales/userguide/docs30/file1. The problem with this is I wanted to just search and replace for paths with ../../ in them. Instead I had full paths. Where this had a problem was that links to files in the current book had full paths that say the book was for wlp would look like c:\edocswork\wlp\admingguide\file1 so there was no easy way to tell when this full path was a relative path or not. But when I go to the MIF, it is very easy to find the relative paths because they aren't expanded in the MIF output. I haven't researched DOCROOT substitutions at this point, mainly because I'm not 100% sure where it might be used in the book. So a file level search and replace in MIF gets all
RE: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
My first attempt was to try and replace the process that was here under dzBatcher so that is what I have ended up with so far and this issue might be enough to try a different direction. Ultimately I hate these sorts of problems that I can't find an explanation for. Why did dzBatcher work with no problem on these files, but my new FrameScript environment is catching the issue. Not knowing what dzBatcher was doing under the covers it might have been somehow ignoring this problem and we just never detected the problem - oh well. I was trying your recommendation for a different set of replacements that occur in HyperText links. Actually the process I was trying this approach on was for some books that didn't follow the guidelines for linking and uses the string replace process that is causing troubles I've reported here. So this one set of books creates hypertext links in a non-standard BEA way and linked directly to books in outside directories. Normally we have the writer insert DOCROOT/product/version/filename and my string replace would insert something for DOCROOT that was appropriate for the HTML or the PDF we generate. These books instead of using DOCROOT, used a relative path, so something like ../../product/version/filename. So I was trying to replace the ../../ with the same info I would replace DOCROOT with. When I looked at these with FrameScript, the path that showed up was expanded based upon the file system (machine and file directory) the file was being processed on. So instead of seeing a relative path, I was getting a resolved path based upon where the file was in its current location. So instead of seeing ../../ I was getting something like c:/edocswork/ales/userguide/docs30/file1. The problem with this is I wanted to just search and replace for paths with ../../ in them. Instead I had full paths. Where this had a problem was that links to files in the current book had full paths that say the book was for wlp would look like c:\edocswork\wlp\admingguide\file1 so there was no easy way to tell when this full path was a relative path or not. But when I go to the MIF, it is very easy to find the relative paths because they aren't expanded in the MIF output. I haven't researched DOCROOT substitutions at this point, mainly because I'm not 100% sure where it might be used in the book. So a file level search and replace in MIF gets all instances. I don't think without processing every type of object in a loop if there is a way to do this in FrameScript. But I haven't spent a lot of time researching this approach yet. I had enough surprises with the one where I knew that this would only appear in markers, I ended up with a couple of different markers I had to look at. ..dan *** Dan Vint Engineer Sr. BEA Systems Home: 510-522-4703 (generally working from home) Office: 408-570-8554 IM Yahoo: dvint1_99 [EMAIL PROTECTED] -Original Message- From: Rick Quatro [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 4:36 AM To: Dan Vint; framers@lists.frameusers.com Subject: Re: Possible Frame6+SGML Issue only MIF to Native and OLE graphics Hi Dan, One thing to consider: it may be better to do your string replacements in FrameMaker without going to MIF and back. Since you are using FrameScript, you may be able to do these replacements in the binary file (depending on what exactly you are doing). Rick Quatro Carmen Publishing 585-659-8267 www.frameexpert.com I have a process in which I run both Frame 6 and 7 documents through an automated build. One step in this effort is to save all the files to MIF and do some string replacements on the file, then save that result back to Native form so I can print the documents. Note that is this case no substitutions were made, so it is just a round tripping of the files from MIF to Native As these files are saved back to Native (via FrameScript) I'm getting the following error/warning from Frame: SnagIt.jpg This has occurred on 4 different books, not sure if they have been all Frame 6 or not, but this last one is 6. One of the books we couldn't track the problem down and had to rebuild it. The other 3 seem to all be related to embedded OLE graphics. Is there some known problem with OLE embedded graphics or an issue with saving from MIF back to Native? ..dan *** Dan Vint Engineer Sr. BEA Systems Home: 510-522-4703 (generally working from home) Office: 408-570-8554 IM Yahoo: dvint1_99 [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please
Re: Possible Frame6+SGML Issue only MIF to Native and OLE graphics
On Tue, 6 Nov 2007 13:25:09 -0800, Dan Vint [EMAIL PROTECTED] wrote: I have a process in which I run both Frame 6 and 7 documents through an automated build. One step in this effort is to save all the files to MIF and do some string replacements on the file, then save that result back to Native form so I can print the documents. Note that is this case no substitutions were made, so it is just a round tripping of the files from MIF to Native. That has always worked flawlessly for every version of Frame I've used, which goes back to Frame 3 on SunOS... ;-) As these files are saved back to Native (via FrameScript) I'm getting the following error/warning from Frame: SnagIt.jpg This has occurred on 4 different books, not sure if they have been all Frame 6 or not, but this last one is 6. One of the books we couldn't track the problem down and had to rebuild it. The other 3 seem to all be related to embedded OLE graphics. Is there some known problem with OLE embedded graphics or an issue with saving from MIF back to Native? There shouldn't be. OLE objects are preserved in MIF just as any other imported graphics are. However, since they are embedded, and not referenced, they are subject to the same troubles as other embedded graphics, which includ potential loss of data if there's inadequate disk space for the temporary files Frame generates when saving them. Check your Windows system environment variables for the TMP and TEMP directories, and make sure the drive referenced in them is not close to full. Aside from that, one cross-check you could try is to use Wash via MIF, which is a File-menu item added by the Mif2Go plugin. It works fine for both books and individual files in the demo version, which is free: http://www.omsys.com/dcl/download.htm You only need to install the plugin files, m2rbook.dll and m2gframe.dll. Wash works by saving as MIF, then reloading the MIF and saving as Frame binary. If you don't see the same problem there, you may want to check the FrameScript code to see what options you are using for the saves to MIF and to Frame binary. I don't know of a particular one that would have that effect, but it's not impossible... HTH! -- Jeremy H. Griffith, at Omni Systems Inc. [EMAIL PROTECTED] http://www.omsys.com/ ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
