Recently, I ran into to an issue that the embedded OLE ojbects are printed differently from what you see in a Word document exported from DOORS.
IBM is also aware of this issue. Please see the Technote: http://www-01.ibm.com/support/docview.wss?uid=swg21416263.
If the OLE objects were embedded in the original Word document, then got imported into DOORS. Then you update the OLE objects in the DOORS. When you export the DOORS module back to Word document again. The OLE objects looks fine in Word app but printed differently. In fact the image got printed is the one in the original Word document before got imported.
In short...
The OLE in DOORS module looks correct.
Directly print from DOORS is correct too.
The exported Word looks correct.
However, the only problem is when you print (including print to PDF).
Please note that if we directly insert OLE objects into DOORS module, no such problem. This problem only happens when the OLE objects already exists in the imported Word document.
To me, this is a show stoppper even though I agree this is a Microsoft bug related between RTF and Word. In my company, we use DOORS as our main repository for requirement documents, which we spent quite a while to import them (from Word document format) into DOORS. Now, we regularly generate/export updated requirement documents from DOORS into Word format and sent to circulation. If what we see/review in the Word application is not what got printed, it is like have you ever doubt that the copies you made from a copy machine could be different from your originals?
The Technote suggests that we need to double-click on every OLE objects in the exported Word document, which will refresh the static image used for print. I have tested BMP, Excel, and Visio OLE objects, BMP always got printed correctly, double-click will refresh Excel print image, however, it doesn't work for Visio. I have to actually modify the Visio OLE object in the exported Word document to enforce the refresh of the image used for print.
I am just wondering that how other DOORS users handle this issue. Does anyone encounter the same issue and can advise me some feasible solution? I don't want to propose my company to hire a army of reviewers to check the printouts for every Word document.
Thanks
SystemAdmin - Tue Aug 10 20:04:56 EDT 2010 |
|
Re: OLE printed differently from a Word document exported from DOORS
kbmurphy - Wed Aug 11 03:17:52 EDT 2010
I understand your frustration. Truly I do. But I don't get why either you or IBM can't devise a workaround.
I haven't ran into this problem yet, but if I did, I could just write a macro that activated every OLE object. If it was a Visio object, I'd try to make the macro modify the first shape by nudging it right or left.
Interesting bug. Have you found out if RPE is affected by this as well? If not, they'll probably try to sell you RPE as a solution.
|
|
Re: OLE printed differently from a Word document exported from DOORS
SystemAdmin - Wed Aug 11 14:24:08 EDT 2010 kbmurphy - Wed Aug 11 03:17:52 EDT 2010
I understand your frustration. Truly I do. But I don't get why either you or IBM can't devise a workaround.
I haven't ran into this problem yet, but if I did, I could just write a macro that activated every OLE object. If it was a Visio object, I'd try to make the macro modify the first shape by nudging it right or left.
Interesting bug. Have you found out if RPE is affected by this as well? If not, they'll probably try to sell you RPE as a solution.
Thanks for your advise.
1. Based on all info I can find from IBM, it seems to me that they will not do anything about it because they believe that this is a bug by Microsoft not in DOORS.
2. Yes, I already start writing a macro doing similar things you suggested. However, the difficult part is to make sure every engineer aware of the issue and run the macro before sending out the exported Word documents.
3. We do already have RPE license. However, we are currently still on DOORS 8.2. Once I got chance I for sure will test RPE with 9.x. However, the workaround/solution for Word export is still needed because I can't prevnet our DOORS users to export to Word without using RPE.
|
|
Re: OLE printed differently from a Word document exported from DOORS
rmoskwa - Wed Aug 11 19:24:08 EDT 2010
This happened to me once, and I never knew why.
I now believe that I exported Word-to-DOORS with an Excel OLE embedded in the Word document.
I usually export from Word-to-DOORS.
I strip out the OLEs in Word before I export.
I add the OLEs (one-by-one) into DOORS after I do the Word-to-DOORS export.
Except for the one instance, I have not seen this problem again.
My documents are short, so it is easy for me to add the OLEs one-by-one.
You can probably email your Word macro to the DOORS users that export directly to Word so thay can add it to their Normal.dot template. Or they can add the macro via an add-in template. You can overload the File->Print, File->Save, File->SaveAs, and File-PrintPrivew Word commands in your macro to run your "OLE Touch" macro so the users are forced to run it. The macro can then detach itself. It would be nice if you have a IT team that can "reach out" configure these PCs for you.
|
|
Re: OLE printed differently from a Word document exported from DOORS
SystemAdmin - Tue Oct 05 12:39:19 EDT 2010 rmoskwa - Wed Aug 11 19:24:08 EDT 2010
This happened to me once, and I never knew why.
I now believe that I exported Word-to-DOORS with an Excel OLE embedded in the Word document.
I usually export from Word-to-DOORS.
I strip out the OLEs in Word before I export.
I add the OLEs (one-by-one) into DOORS after I do the Word-to-DOORS export.
Except for the one instance, I have not seen this problem again.
My documents are short, so it is easy for me to add the OLEs one-by-one.
You can probably email your Word macro to the DOORS users that export directly to Word so thay can add it to their Normal.dot template. Or they can add the macro via an add-in template. You can overload the File->Print, File->Save, File->SaveAs, and File-PrintPrivew Word commands in your macro to run your "OLE Touch" macro so the users are forced to run it. The macro can then detach itself. It would be nice if you have a IT team that can "reach out" configure these PCs for you.
But if you run an export on a .dsx specification, which has "Ole as static images = false", and an option to use a specific Word template, then you will have editable ole objects, but also same Word printing problem will be there too.
Solution for us has been to add a print macro to word startup folder (in Citrix), so all users can print with that one as needed. Our macro changes all ole's to pictures, and then opens print dialogue for user. Of course if one still wants to save the word document after printing, he should undo the updating action to keep the ole's still editable.
|
|
Re: OLE printed differently from a Word document exported from DOORS
Merillee.Klugh - Fri Oct 22 01:39:16 EDT 2010
Hi, kbmurphy:
Thanks for your advise.
1. Based on all info I can find from IBM, it seems to me that they will not do anything about it because they believe that this is a bug by Microsoft not in DOORS.
2. Yes, I already start writing a macro doing similar things you suggested. However, the difficult part is to make sure every engineer aware of the issue and run the macro before sending out the exported Word documents.
3. We do already have RPE license. However, we are currently still on DOORS 8.2. Once I got chance I for sure will test RPE with 9.x. However, the workaround/solution for Word export is still needed because I can't prevnet our DOORS users to export to Word without using RPE.
Thanks for your explanation! It's very valuable.
|
|
Re: OLE printed differently from a Word document exported from DOORS
BillTidy - Thu Jan 12 09:01:31 EST 2012 Merillee.Klugh - Fri Oct 22 01:39:16 EDT 2010
Hi, kbmurphy:
Thanks for your advise.
1. Based on all info I can find from IBM, it seems to me that they will not do anything about it because they believe that this is a bug by Microsoft not in DOORS.
2. Yes, I already start writing a macro doing similar things you suggested. However, the difficult part is to make sure every engineer aware of the issue and run the macro before sending out the exported Word documents.
3. We do already have RPE license. However, we are currently still on DOORS 8.2. Once I got chance I for sure will test RPE with 9.x. However, the workaround/solution for Word export is still needed because I can't prevnet our DOORS users to export to Word without using RPE.
Thanks for your explanation! It's very valuable.
Q3 last year we migrated to 9.3 and RPE 1.1.1 with Word 2007 from 8.3 and WEXP with Word 2003 - at the time everything looked fine but recently we started to reprint from some older modules, containing lots of embedded Visio files with detailed plans.
The problem is the quality (resolution) of the exported images is much worse via RPE/Word 2007 than it was in WEXP/Word 2003. They are now unreadable.
Does anyone know the cause or solution?
|
|
Re: OLE printed differently from a Word document exported from DOORS
BillTidy - Thu Jan 12 09:06:16 EST 2012 BillTidy - Thu Jan 12 09:01:31 EST 2012
Opening this can of worms again.
Q3 last year we migrated to 9.3 and RPE 1.1.1 with Word 2007 from 8.3 and WEXP with Word 2003 - at the time everything looked fine but recently we started to reprint from some older modules, containing lots of embedded Visio files with detailed plans.
The problem is the quality (resolution) of the exported images is much worse via RPE/Word 2007 than it was in WEXP/Word 2003. They are now unreadable.
Does anyone know the cause or solution?
|
|
Re: OLE printed differently from a Word document exported from DOORS
BillTidy - Thu Jan 12 11:56:42 EST 2012 BillTidy - Thu Jan 12 09:06:16 EST 2012
PS: A direct export to Word 2007 displays the Visio images in full detail (File -> Export -> Microsoft Office -> Word)
To get OLEs printed in all their full-resolution glory you MUST use a document spec and in the doc spec definition choose to not export OLEs as static images. In addition, you MUST include the macros supplied with RPE in your Word stylesheet (dot file) and set the macro 'rpe' in the doc spec to run after the export is complete.
I don't like this solution, since it means we now have to create at least one doc spec for each and every module we want to export (one for every output template per module type you have) as this can only be done via the RPE developer studio, which end-users do not have access to. The doc specs then need to be made available on a share to everyone that needs access to run an RPE export. Given we have hundreds of modules, this will be a real pain to set up and roll out and make it difficult for the end-user as they will have to plough through lots of dsx files to find the right one for their export.
Not doing this (default export of OLEs as static images) leads to severe and unacceptable loss of image resolution.
|
|
Re: OLE printed differently from a Word document exported from DOORS
JWiseman - Mon Mar 12 17:56:43 EDT 2012 BillTidy - Thu Jan 12 11:56:42 EST 2012
OK, now I solved it (sort of), thanks to earlier posters here pointing me in the right direction.
To get OLEs printed in all their full-resolution glory you MUST use a document spec and in the doc spec definition choose to not export OLEs as static images. In addition, you MUST include the macros supplied with RPE in your Word stylesheet (dot file) and set the macro 'rpe' in the doc spec to run after the export is complete.
I don't like this solution, since it means we now have to create at least one doc spec for each and every module we want to export (one for every output template per module type you have) as this can only be done via the RPE developer studio, which end-users do not have access to. The doc specs then need to be made available on a share to everyone that needs access to run an RPE export. Given we have hundreds of modules, this will be a real pain to set up and roll out and make it difficult for the end-user as they will have to plough through lots of dsx files to find the right one for their export.
Not doing this (default export of OLEs as static images) leads to severe and unacceptable loss of image resolution.
Anyway, when we moved to Word 2007, we continued to use only Word 2003 docs with DOORS. E.g., export templates and style sheets were kept in Word 2003 format. It seemed to have reduced those issues.
Are your style sheets in Word 2003 format? This may help.
|
|
Re: OLE printed differently from a Word document exported from DOORS
JWiseman - Mon Mar 12 18:05:27 EDT 2012 JWiseman - Mon Mar 12 17:56:43 EDT 2012
I no longer have access to these tools so I cannot get details on the following, but a ways back, I learned that the new Word 2007 stores pictures differently to guarantee compatibility with Word 2003. In fact, a single OLE figure in Word 2007 can actually contain multiple images so that it can be compatible with the 2003 equivalent (which makes your documents much bigger too).
Anyway, when we moved to Word 2007, we continued to use only Word 2003 docs with DOORS. E.g., export templates and style sheets were kept in Word 2003 format. It seemed to have reduced those issues.
Are your style sheets in Word 2003 format? This may help.
We were forced to get around this nonsense by keeping copies of old Word 2003 documents with those kind of OLEs in them. We would then copy and paste the OLE into DOORS and then modify its content there.
No idea how long they will last since it appears Microsoft doesn't want to support the useful ones anymore :-(
|
|