Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Printing fails in WPF #597

Closed
miguep opened this issue Apr 16, 2019 · 0 comments · Fixed by #995
Closed

Printing fails in WPF #597

miguep opened this issue Apr 16, 2019 · 0 comments · Fixed by #995
Assignees
Labels
Bug Product bug (most likely) regression status: This issue is a regression from a previous build or release
Milestone

Comments

@miguep
Copy link
Contributor

miguep commented Apr 16, 2019

  • .NET Core Version: 3.0.0-preview4-27613-07
  • Windows version: Win7, Win8.1, Win10
  • Does the bug reproduce also in WPF for .NET Framework 4.8?: No

Problem description:

attempt to print using the following code snippet

PrintQueue.CreateXpsDocumentWriter(LocalPrintServer.GetDefaultPrintQueue()).Write(visual);

Actual behavior:
Exception Info: System.IO.IOException: Cannot retrieve parts of writeonly container
at System.IO.Packaging.Package.ThrowIfWriteOnly()
at System.IO.Packaging.Package.GetRelationshipsByType(String relationshipType)
at System.Windows.Xps.Packaging.XpsManager.GetXpsDocumentStartingPart(Package package)
at System.Windows.Xps.Packaging.XpsDocument.AddFixedDocumentSequence()
at System.Windows.Xps.Serialization.XpsPackagingPolicy.AcquireXmlWriterForFixedDocumentSequence()
at System.Windows.Xps.Serialization.XpsSerializationManager.AcquireXmlWriter(Type writerType)
at System.Windows.Xps.Serialization.ReachHierarchySimulator.SimulateBeginFixedDocumentSequence()
at System.Windows.Xps.Serialization.ReachHierarchySimulator.BeginConfirmToXPSStructure(Boolean mode)
at System.Windows.Xps.Serialization.XpsSerializationManager.SaveAsXaml(Object serializedObject)
at System.Windows.Xps.XpsDocumentWriter.SaveAsXaml(Object serializedObject, Boolean isSync)

Expected behavior:
Printing succeeds

In Win7 this may or may not be an issue depending on the printer capabilities (Xps capable printer). In RS2+ this is also not an issue

Adding additional detail from VSO 847076

Print using the below line of code:

        PrintQueue.CreateXpsDocumentWriter(LocalPrintServer.GetDefaultPrintQueue()).Write(visual);

Observe a System.IO.IOException in System.IO.Packaging.

In general it seems like corefx's version of System.IO.Packaging does not provide the support needed by WPF's XPS APIs to produce a correct XPS package to either send to an XPS compatible printer or save to disk.

This was found through failures in DrtInterleavedPackage which essentially simulates the way our XPS APIs work by directly calling into the System.IO.Packaging APIs.

System.IO.Packaging in Core dropped streaming creation support, which in the original implementation was the only way to create a Write-only package that would allow interleaving. Seems like there have been some changes to enable Write-only package creation without streaming, but there is no interleaving support, and some of the actions that the XPS code is trying to perform are no longer allowed under the new Write-only scenario.

We should investigate whether our XPS code needs to change to accommodate for the support available in System.IO.Packaging, or if we need to re-introduced some of the dropped support.

The reason this is broken only in the mentioned OS is because of the new XPS Object Model API support we added in 4.6, essentially the old method of printing required us to write an XPS document package directly to a stream given to us by the printer. the XPS Object Model APIs instead expose the entire XPS protocol through interfaces, so we just call methods on said interfaces and the XPS document that is sent to the printer is created for us.

Also Win7 will still print if the printer is GDI.

@ryalanms ryalanms added the Bug Product bug (most likely) label Apr 17, 2019
@stevenbrix stevenbrix added this to the 3.0 milestone Apr 18, 2019
@rladuca rladuca added the regression status: This issue is a regression from a previous build or release label May 20, 2019
@grubioe grubioe modified the milestones: 3.0, Preview May 24, 2019
@ghost ghost locked as resolved and limited conversation to collaborators Apr 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug Product bug (most likely) regression status: This issue is a regression from a previous build or release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants