[netcore3] XamlToRtfWriter.WriteShapeImage fails on unseekable streams

[grubioe]

In PresentationFramework (XamlToRtfWriter.cs), the 'WriteShapeImage' function fails to due change in seekability of the zip streams returned in Read mode. The function reads from the same stream twice. This becomes a problem because after the first read, the stream becomes disposed, which causes an exception to be thrown when trying to set the position of the stream back to 0 in order to read the stream again.

Github issue #585 is related to the root cause

Steps to reproduce:

1. Run DigitalDocuments/...../DrtSequence
2. Observe following exception thrown when trying to update the stream position in function 'ConvertToImageHexDataString'

System.ObjectDisposedException: 'A stream from ZipArchiveEntry has been disposed.

Object name: 'System.IO.Compression.SubReadStream'.'

[stevenbrix]

Ok, I don't believe the fundamental issue here is that these streams are unseekable, rather it seems that WPF manually closes this stream in the BitmapDownload.ReadCallback method:

 	System.IO.Compression.dll!System.IO.Compression.SubReadStream.Dispose(bool disposing) Line 262
 	System.Private.CoreLib.dll!System.IO.Stream.Close() Line 225
 	System.Private.CoreLib.dll!System.IO.Stream.Dispose() Line 23
 	System.IO.Packaging.dll!System.IO.Packaging.ZipWrappingStream.Dispose(bool disposing) Line 124	
 	System.Private.CoreLib.dll!System.IO.Stream.Close() Line 225
>	PresentationCore.dll!System.Windows.Media.Imaging.BitmapDownload.ReadCallback(System.IAsyncResult result) Line 374
 	System.Private.CoreLib.dll!System.IO.Stream.ReadWriteTask.InvokeAsyncCallback(object completedTask) Line 649
 	System.Private.CoreLib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) Line 172
 	System.Private.CoreLib.dll!System.IO.Stream.ReadWriteTask.System.Threading.Tasks.ITaskCompletionAction.Invoke(System.Threading.Tasks.Task completingTask) Line 675	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.RunOrQueueCompletionAction(System.Threading.Tasks.ITaskCompletionAction completionAction, bool allowInlining) Line 3438	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.RunContinuations(object continuationObject) Line 3356	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.FinishContinuations() Line 3308	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.FinishStageThree() Line 2193	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.FinishStageTwo() Line 2162	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.FinishSlow(bool userDelegateExecute) Line 2084	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.ExecuteWithThreadLocal(ref System.Threading.Tasks.Task currentTaskSlot, System.Threading.Thread threadPoolThread) Line 2438	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.ExecuteEntryUnsafe(System.Threading.Thread threadPoolThread) Line 2344	
 	System.Private.CoreLib.dll!System.Threading.Tasks.Task.ExecuteFromThreadPool(System.Threading.Thread threadPoolThread) Line 2329
 	System.Private.CoreLib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() Line 671	
 	System.Private.CoreLib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() Line 29	

Then we later try to read from the stream and it is disposed at that point

[stevenbrix]

Ahh considering the remarks in MemoryStream since the stream used to behave like a MemoryStream, that calling Close on the stream used to no-op, allowing for future seeks