Closed ojhad closed 5 years ago
I'm also having an issue with this exception if I call
var document = new XpsDocument(@"repro.xps", FileAccess.Read);
var paginatorSource = (IDocumentPaginatorSource)document.GetFixedDocumentSequence();
on the attached XPS file (which was created with the XPS Document Writer driver). See my comment at #575. Exception details:
System.NotSupportedException
HResult=0x80131515
Message=This operation is not supported.
Source=System.IO.Compression
StackTrace:
at System.IO.Compression.DeflateStream.get_Position()
at System.IO.Packaging.ZipWrappingStream.get_Position()
at MS.Internal.IO.Packaging.SynchronizingStream.get_Position() in /_/src/Microsoft.DotNet.Wpf/src/shared/MS/Internal/IO/SynchronizingStream.cs:line 207
at MS.Internal.IO.Packaging.DeobfuscatingStream.Read(Byte[] buffer, Int32 offset, Int32 count) in /_/src/Microsoft.DotNet.Wpf/src/PresentationCore/MS/Internal/IO/Packaging/DeobfuscatingStream.cs:line 56
at MS.Internal.FontCache.FontSource.StreamToByteArray(Stream fontStream) in /_/src/Microsoft.DotNet.Wpf/src/PresentationCore/MS/Internal/FontCache/FontSource.cs:line 419
at MS.Internal.FontCache.FontSource.GetUnmanagedStream() in /_/src/Microsoft.DotNet.Wpf/src/PresentationCore/MS/Internal/FontCache/FontSource.cs:line 279
at MS.Internal.Text.TextInterface.FontFileStream..ctor(IFontSource fontSource)
at MS.Internal.Text.TextInterface.FontFileLoader.CreateStreamFromKey(Void* fontFileReferenceKey, UInt32 fontFileReferenceKeySize, IntPtr* fontFileStream)
@grubioe - we need to document this issue as a change, and remove this from our queue. likely this is not going to actionable.
@vatsan-madhavan This will break Xps viewing and printing in a wide range of scenarios. IMHO this should be looked at at least for the Core 3.0 release.
@vatsan-madhavan you have at least one more internal caller in WPF which is broken, see stack of @jbartlau, all internal callers need to be fixed
@weltkante @vatsan-madhavan Would be happy to raise a separate issue in order to tackle the internal call there.
@weltkante, @jbartlau, we are still looking into this. @jbartlau's issue (#1063) is helpful.
@vatsan-madhavan the stack trace over in #1063 looks different than what @jbartlau reported, it seems to be a native exception and not directly related to the zip archive issue here and with @jbartlau.
There is a working solution to this in branch, should be PRed later today: https://github.com/dotnet/wpf/tree/dev/roladuca/wrappackagestreams.
In summary, the DeflateStream implementation in System.IO.Compression is a non-seekable stream. This is returned to PackagePart.GetStream when it is opened as read-only. In these scenarios, we need to copy out the stream to a MemoryStream in order to be able to use Seek and Position. This is the essence of the fix that @stevenbrix did, but this attempts to address all such usages.
As a workaround (@jbartlau) you can open the Package as read/write (or XPS document, whatever API you are using). When you do this, the underlying packaging and compression APIs already uncompress to a MemoryStream and return that. So in those instances, we're given a proper seekable stream and things will work.
As a workaround (@jbartlau) you can open the Package as read/write (or XPS document, whatever API you are using).
Thanks @rladuca, can confirm the workaround is viable, will test the fix once it becomes available in one of the next previews then.
Writing streams may need another look, wrapping them in MemoryStream needs special care to ensure the writes actually make it to the original stream and aren't lost when disposing the MemoryStream.
(Related to #1363 which is an example for actually writing and got me thinking about this case!)
.NET Core Version: 3.0.100-preview4
Problem description:
There is a behavior change regarding the seekability of returned ZipArchiveEntry streams.
.NET Framework behavior:
The WindowsBase implementation of Zip had the necessary functionality that operated on the returned deflate streams which provided support for seeking (However, in doing so, it incurred a lot of extra CPU and file system usage)
.NET Core behavior: The current implementation in CoreFX (System.IO.Packaging) no longer provides this functionality, resulting in streams that are being returned to be non-seekable.
Related Issue: https://github.com/dotnet/corefx/issues/34219