Jim Connolly

How do we programmatically convert the .docx to XPS [Correct Spelling] so that we have exact fidelity between the Word 2007 look and the XPS The constraints are that we have to assume that the client PC is a fresh install of Windows XP and does not have anything but the libraries we install as part of our custom application installation program. In other words, the client computer will not have Office 2007 installed.

Our application.

1. The .docx files are stored locally on a users machine in SQL CE.

2. We use sync services to sync these documents with our corporate office.

3. We provide the client a winform user interface where they can type in values.

4. Those values are inserted into the .docx programatically (OPEN XML XML DOM manipulation) and are saved back into the .docx

5. Now we want to simply display the .docx to the user in an XPS file (streaming to a XPS viewer)




Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lisa Nicholls

First, I'll assume you mean XPS, not XPF...

Second, I am not sure that XPS is the right way to do this. It is techically possible, I guess, but you would probably want to to do something like this:

* -- ensure XPS viewer availability on the client

* -- ensure XPS print driver on the client

* -- ensure DOCX viewer on the client -- which if I remember correctly is the free Word 2003 viewer with a compatibility pack applied

* -- use the DOCX viewer and the XPS printer driver to print to XPS

* -- display XPS

... all those components are free and available for XP, not just the XPS viewer. I will have to assume that you expected to make the XPS viewer available as part of your "custom application installation". I'm just saying that you are going to need to put more than none thing. But, read on.

Without installing a third-party app that does a lot of really fancy work, there is really no better way to "get there from here" between DOCX and XPS without going through the print-rendering process.

This is for good reasons, not some sort of malfeasance or underimplementation on anybody's part, as I see it. The two formats are not really the greatest match in the world, saying that they are both "just XML" isn't going to change that. I can elaborate if anybody is interested, but the main point is doing this well and deeply isn't a slam-dunk.

But the print-rending process implies the availability of the DOCX viewer. That being the case, why not just have them view the DOCX rather than the XPS

My two cents,

>L<






Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Jim Connolly

Hi Lisa: Would you kindly contact me at jconnolly@kettley.com. Thank you.




Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Phil Fearon

Would it be possible to just automate Word 2007 from a .NET application This could open the docx document from the client in Word, and then publish to XPS and then stream it back to the client.

As creating XPS is possible through the Word 2007 user interface (once the XPS and PDF add-in has been downloaded & installed) its reasonable to assume this can be automated through code, using a non-visible instance of Word.

Admittedly, using Word 2007 in this way would probably not be recommended for high volume work.

pgf






Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lisa Nicholls

Yes, it is absolutely possible, Phil. Just not in this context. Read the first post again: this is a distributed vertical market app; there is no guarantee that Word (in any version) is present on the computer hosting the application.

>L<






Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lewis@example.com

So did you ever hear back a useful response on how to do this mapping

I have a similar problem, which is that I have a .docx file which I wish to display in the context of a web page (as in):

<OBJECT
ID='WORDOBJ'
CLASSID='CLSID:000209FF-0000-0000-C000-000000000046'
>
<PARAM NAME="FileName" VALUE="C:\x.docx">
</Object>

Sadly - for reasons that elude me - this doesn't work (even with Word installed on the users computer).

So my next attempt was to manually do the createobject to make a word instance, and map to xps format (which CAN be rendered inside HTML). But I've yet to find a way - even with word installed - under OLE automation - to get an XPS file output from a document.






Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lisa Nicholls

I've lost the plot on this one, in terms of "waiting to get a useful response on how to do this mapping" -- but -- FWIW

The easy way to get XPS output is to install an XPS printer driver and print to the driver. You should be able to do that under OLE automation . On the user side, they have to have an appropriate viewer installed to view the XPS, but you know that, right In any case the XPS driver and viewer are both free.

>L<






Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lewis@example.com

Right. My question (and the original question) were not about how a USER might do this. I agree that this is clear (and that xps print driver and either office 2k7 or earlier office + update for viewer needed).

My question is - suppose you wish to write an application that hosts and MSIE instance, and renders HTML, and that one of those HTML pages wishes to display a .docx as a part of it.

My initial naive approach was:
<OBJECT
ID='WORDOBJ'
CLASSID='CLSID:000209FF-0000-0000-C000-000000000046'
>
<PARAM NAME="FileName" VALUE="C:\x.docx">
</Object>


That failed to do much of anything (even plain .doc files fail to display this way).


My next attempt was was to use word to map the .docx to XPS as follows:
<INPUT id=button1 name=button1 type=button value=Button>

<SCRIPT LANGUAGE="VBScript">
sub button1_onclick()
dim app
set app = createobject("Word.Application")
app.DisplayAlerts = 0
app.Visible = false
dim doc
set doc = app.Documents.Open ("C:\TESTHTMLREPORT.docx")
doc.PrintOut ,,, "fileoutput.xps", , , , , , 1
app.Quit 0
end sub
</SCRIPT>


But though this produced a fileoutput.xps file - it was in the 'raw' format of my default printer - not the XPS print driver. If there was an argument i could pass to doc.PrintOut that told it to use the XPS print driver, I might be in better shape (though even so, I'm not thrilled as the above seemed fragile - and to occasionally hang - even while producing the wrong results).


Should displaying a .docx file (embedded in HTML) really be so difficult
Lewis.





Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lisa Nicholls

I know your question was not about how A USER could do it. I am giving you appropriate information. Assuming you want to instantiate Word for automation purposes, which apparently you think is a good idea, you can install an XPS printer driver and you can tell the word object to print to a given driver. You can iterate through the setups available and pick the one you installed (by driver name or setup name).

I have absolutely no idea what you expected from putting an .xps extension on an output file but it's certainly not how you tell Word or any other application to use a particular driver. I also am not sure what version of Word you're addressing (they're all a bit different) but if you are accustomed to using Word then you know you can talk to the dialogs. You can save Word's active printer, if memory servers this would be Application.ActivePrinter, set up a different one, restore the active one when you're done.

Whether you like the idea of requiring an XPS printer driver setup or not, and in many cases you can do this silently from within your app, I am also trying to tell you that NOTHING is going to show in the browser unless the user has an appropriate activex control version or standalone version of an XPS viewer. Which they won't automatically have unless they're in Vista -- I'm pretty sure it's automatic then, but I think it is a little early to be assuming that everybody in the universe has Vista. Since the viewer capabilities typically come in the same redistributable installation as the driver, you ought to do both together.

>L<






Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lewis@example.com

This doesn't tell me anything I didn't already know (I knew about ActivePrinter, but don't know the details of how to iterate over all installed printers and change the MSWord active printer etc).

I was hoping that you would point out I was going down the wrong road.

I didn't mention the version of MSWord I'm using because I want it to work with any version. I realize that my app will have to detect if the XPS drivers or .docx extensions are installed, and offer them the opportunity to download them gracefully.

Assuming I've gracefully assured my users have XPS drivers and updated word docx viewer functionality installed - is there an EASY way to display a read-only copy of the .docx

The example I offered with <object> above would count as 'easy' - if it worked (note - it works for reports in PDF format, so since MSFT invented OLE embedding, I would think they would support it in their flagship wordprocessor as well as Adobe does for PDF)

But - baring that - if they provided an easy way to convert a .docx to .XPS, and then an easy way to render the .XPS in HTML (which I believe does exist) - I'd be all set.

I went down the road of trying to 'automate' word to read a .docx and print it - but that approach is fragile. Adding code to temporarily create and reset the default printer will not make it LESS fragile - I fear.

But - if that is the only way Microsoft supports for viewing .docx files embedded in MSIE - I guess I'll have to live with it...





Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lisa Nicholls

You want the details of code, and you want it to work with any version of Word, then that code is usually going to be bracketed to take care of the differences between versions of Word <shrug>.

Sorry, but there it is. And if I were doing this, I would take my bracketed code and test it all over again with Word 2007...

>>Assuming I've gracefully assured my users have XPS drivers and updated word docx viewer functionality installed - is there an EASY way to display a read-only copy of the .docx

I didn't say anything about a DOCX viewer. I was talking about an XPS viewer. They are two different things and you get them from two different mechanisms. Both are free (the docx viewer is also backwards compatible/an add on to earlier versions of Wordviewer) but your users may not have Word 2007 so I'm not sure you can automate their copy of Word to actually *write* docx.

Writing XPS through a printer driver almost any app can do because the app remains unaware of what the printer driver is going to do with its output.

Assuming you meant "an easy way to display a read-only copy of the XPS", sure. First, it's pretty much readonly by definition from a user's POV, it's not a Word document. Second, there are TWO WAYS as I think I have already said. The free viewer comes in standalone and browser-based version. If it were me I'd probably invoke the standalone, but I have absolutely no idea what environment your actual app is in so it's hard to say. I can't really imagine why you are leaning towards an object tag in a browser, for instance, unless your app is already browser based. If it is, then sure go for it. If the user has the bits installed, IE 7 will understand the XPS document natively.

I can't "point out that you are going down the wrong road", because I don't know much about you or your application, Lewis, but I can tell you my *opinion* is that you have some ways to go <s>. If you explain what your surrounding code looks like (I don't even know what language or environment you work in), maybe I can help. But you've made a lot of assumptions and you need to re-think them. For only one example, I have no idea what you think the production of an XPS, and how that is done, has to do with Microsoft's "support for viewing .docx files embedded in MSIE". The two things -- producing an XPS document and viewing an XPS document -- are not coupled at all.

The control provided for viewing XPS in WPF is not an activeX control, although it can be hosted in one, which is an extra "layer". Depending on what your programming experience and environment is, we can discuss this further, but again controlling and determining this viewing experience has nothing to do with how the document was produced.

You can write XPS yourself, if you like, instead of going through a printer driver. You don't need to use Word to do it, that's for sure. Whether this is a good idea (again) is going to depend on your experience and environment -- and also how complex the document needs to be.

Please don't shoot the messenger.

>L<






Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lewis@example.com

Since you are questioning the high level choices and approach, let me back up a little bit, and provide a little background.

I have a C++-based, ATL-Win32 application that uses an embedded MSIE control (AxHost) to render HTML.

I have a plug-in API for this application (http://www.recordsforliving.com/OpenHealthServices/) which allows reports to be written in any language, and they are transparently included as builtin reports in my application.

A member of our team has used this mechanism, together with .docx and some Java glue to create plugins which automatically populate MS-Word (2007)-based .docx reports with data filled in from an electronic medical record. This allows reports to be authored in Word 2k7 and plug-in almost completely transarently into HealthFrame - to extend the set of electronic health-record based reports it generates.

However - we wish to make viewing the reports as transparent as posssible. With reports which generate HTML, PDF, or various image formats - we can display them directly inside the HTML viewed in the AxHost web-browsers control within the application.

We wish to extend that - so that .docx files ALSO can be so-displayed.

If users DONT have word installed, we can detect this in our applicaiton and point them towards websites to download the Word Viewer (for docx). If they lack XPS drivers, we can detect this, and point them towards a website to download XPS drivers.

But given that - I need to generate HTML which DISPLAYS a read-only copy of the generated report.

My first approach was:
<object>
ID='WORDOBJ'
CLASSID='CLSID:000209FF-0000-0000-C000-000000000046'
>
<PARAM NAME="FileName" VALUE="C:\x.docx">
</Object>

This mirrors what I do for PDF-based reports, and image and HTML-based reports.

From what I understand (I haven't tested this myself yet) - its easy to display .xps files inside MSIE (just like other images - like PNG or WMF files etc). Is that not so

If it IS so - then all I need is to be able to have word (or something else) convert the .docx file to .XPS

Really - my PREFERRED solution would be to have the very simple
<object>
ID='WORDOBJ'
CLASSID='CLSID:000209FF-0000-0000-C000-000000000046'
>
<PARAM NAME="FileName" VALUE="C:\x.docx">
</Object>

BTW - that very simple approach DOES work for EXCEL (also part of Microsoft office) - obviously with differnt CLSID, filename, etc. There is an working OLE embeddable version of Excel spreadsheets. Since it appears that Outlook uses an embedded copy of Word as its editor - I really don't understand why MSFT doesn't support having word hosted inside MSIE (as as HTML <object> - not using iframes).

Anyhow - I hope this has made my situation a little more clear.




Re: XML Paper Specification (XPS) Programmatically convert the .docx to XPF

Lisa Nicholls

Lewis, I'm not questioning your choices, just saying that I can't recommend things without any background...

And I can see now why you would want to embed docx. Am I correct in assuming that you *can* expect Word 2007 to be available on the user's computer, then (I'm a little confused because you said you wanted this to work "for any version of Word". )

But -- see this is the thing -- absolutely none of this has anything to do with XPS or XPS viewers. Which is what this thread was about...

Have you looked into 2007 version of WordViewer, btw

Now, as to your alternative:

XPS files are not images "like PNG or WMF" . They're not images, period. They're packages, just like docx or xlsx. But they're different from docx and xslx because they are, by definition, bound to a fixed page format. They're not "flow documents". That's why a printer setup is a good way to create them ; you need an idea of a fixed page size to really have a layout in to which the contents of the document will be "poured".

I think the co-worker who did the java-poking will understand what I'm saying. S/he can evaluate whether it is a good idea to "pour" the contents of your variables etc into XPS instead of DOCX for your type of documents. It may be a totally fine idea to do this. But s/he won't do it by *converting* DOCX to XPS, it will just be a dev effort very similar to what s/he's already done for DOCX, poking data into a package with parts that have different schema from DOCX. OK

Make that evaluation -- and I wouldn't recommend one way or the other without knowing how complex the documents are, as I think I have already said , but it sounds pretty do-able. If so, then you have what you want: no printer driver dependancy, etc.

If you decide that creating XPS documents is *not* do-able in your scenario, and if you will have Word or WordViewer available on the client, my recommendation would be to shell to that application, not try to host in a browser, okay ShellExecute should do this just fine.

Regards,

>L<