Forum Discussion

Copper Contributor

Nov 23, 2020

Document conversion

Hello! We have been testing the Universal Print feature in combination with pull-print scenario. It worked, basically, all things considered. But we also wanted to test the document conversion and t...

AndrewCardy

Copper Contributor

Mar 09, 2021

abitor I seem to get the same results as you. There appears to be documentation to suggest this should work:

https://docs.microsoft.com/en-us/universal-print/fundamentals/universal-print-document-conversion

I note this also seems to happen when I use the xps mime type application/vnd.ms-xpsdocument.

The only content-type setting it seems to work with is application/oxps.

Probably worth mentioning that when the printer's content type is set to anything other than application/oxps, the print on the client fails with 'Error - printing'.

Saurabh_Bansal

Microsoft

Mar 14, 2021

abitor / AndrewCardy First lets confirm a few things:

The virtual printer you created supports PDF only as content-type.
The virtual printer does contain OXPS as one of the supported content types
Are you trying to implement task trigger? If yes, then are you accessing the document after completing the task trigger?

Here is how it should work (if you have PDF only as the content type):

For Windows versions 2004 onwards (2004 and 20H2), Windows itself will upload PDF and you can access the payload in PDF format.
For Windows versions 1903 and 1909, Windows uploads OXPS. If you have task trigger, Universal Print will create a task and then wait for your application to complete the task. During all this time payload will continue to be in OXPS (unless you convert to another format and replace the payload). Once you have mark the task as complete, then Universal Print will process the job further and convert to PDF (if not already converted and document conversion is enabled). After conversion to PDF job will move to JobFetchable status.

Hope this clarifies.

Thanks,

Saurabh

AndrewCardy
Copper Contributor
Mar 15, 2021
Saurabh_Bansal

Thanks for the clarifications. I think I might be miss-understanding the flow for virtual printers where payload modification is needed.

Currently my flow looks like:

1) Poll taskDefinition for tasks
2) Find a task in 'processing state', with a job that is 'paused'
3) Modify payload
4) Upload modified payload
5) Either redirect or mark as complete

Redirection in step 5 seems to work fine, and the job ends up with a completed status.

However, if I want to send the job to OneDrive, for example, I attempt to mark the task as complete, but the job remains in a 'pending' state. Am I miss-understanding what a 'processing' and 'pending' task means? As a task, should I wait to modify a payload until it's 'fetchable' or is that just for the downstream printer to know when it can be fetched?

Hope this makes sense. 🙂

Thanks!
- Saurabh_Bansal
  Microsoft
  Mar 15, 2021
  AndrewCardy Thats more or less correct. A few clarifications/suggestions though:
  
  Setup Graph change notifications to be notified for a new print job in the queue (instead of Polling)
  
  When notified about a task that is created for a new job (in paused state), get job details and download the payload
  
  Modify payload - please note that if your printer is PDF, then
  
  Job will be in PDF format already if coming from Windows versions 2004 or 20H2
  
  Jobs will be in OXPS format if coming from Windows versions 1903 or 1909. Universal Print converts OXPS to PDF after the task is marked complete and if doc conversion is enabled.
  
  Upload modified payload (has to be compatible with the printer including supported format)
  
  Either redirect or mark as complete
  
  Hope this clarifies.
  
  THanks
  
  Saurabh
  - AndrewCardy
    Copper Contributor
    Mar 16, 2021
    That does help, thanks! So in a full implementation, it'd likely be a cloud or server deployment where the using notifications make a lot of sense. I'll be sure to mention that in onward conversations.
    
    Thanks!