WIP: Proof of concept port of interleave feature

[wstaelens]

PR so that hopefully somebody can apply this fix:

PR is code from Kevin:
#51929 (comment)

Main threads:
dotnet/wpf#3546
and
#51929

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

PR so that hopefully somebody can apply this fix:

PR is code from Kevin:
#51929 (comment)

Main threads:
dotnet/wpf#3546
and
#51929

Author:	wstaelens
Assignees:	-
Labels:	area-System.IO
Milestone:	-

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Issue Details

---

PR so that hopefully somebody can apply this fix:

PR is code from Kevin:
#51929 (comment)

Main threads:
dotnet/wpf#3546
and
#51929

Author:	wstaelens
Assignees:	-
Labels:	area-System.IO.Compression, community-contribution
Milestone:	-

[wstaelens]

@vseanreesermsft ? @singhashish-wpf ? @Kuldeep-MS ? @rchauhan18 ?

[jeffhandley]

@krwq @carlossanlop Could you both weigh in on this? Do you agree that we should add this support? Do you have any concerns about this moving forward?

@wstaelens for the time-being, I'm going to mark this as a Draft. The title implies it's a work-in-progress; is that true, or would this be ready for review if we agree in spirit that this can move forward?

Thanks!

[wstaelens]

@jeffhandley first of all: THANK YOU for looking at this after all these years.

The situation:

• .NET Framework supports interleave feature in XPS print jobs (.piece files)
  - Microsoft's own V4 XPS print driver generates interleaved xps print jobs!!! (we, and others are based on this driver!!)
• code from .NET Framework has not been fully ported to .net
• Result: since upgrading from .NET Framework to .net (core) XPS print jobs are broken and cannot be read in .net core/.net.

@KevinCathcart did in his PR a port already of the .NET Framework code. To be honest, I'm not that familiar with the .net sources itself to be able to fix this issue myself. So to answer the question, I don't know how much is missing from Kevin/this PR.
I've just did a copy of Kevin his PR to bring the problem again under attention as nothing is/was happening and it is still broken since the first release of .net core.

Original PR info: #51929 (comment)
f3c67bc

In case there is a new version or a dll we should test, let me know.

[krwq]

My personal opinion is that does seem like important scenario to support. We should ensure testing and quality and this should go through regular feature development process. Ultimately it's up to area owner to decide. IMO we should especially focus on adding tests which use this piece of code same way (or as close as can be predicted) it's going to be used by XPS code. Most likely there should be PRs open on both repos and the XPS code should be tested with private bits from this PR.

[jeffhandley]

I'm going to go ahead and close this. Per @krwq's comments, before we'd be able to bring in new functionality in this space, we have work to do to get the test coverage up to a better position. We know that XPS related scenarios are causing folks frustration though.

Thanks for submitting this @wstaelens, nonetheless.

[wstaelens]

@jeffhandley so this is a polite messsage telling me you closed this and it will not be fixed? @krwq ?

[jeffhandley]

@wstaelens It's not that it won't be fixed, but that we are going to need to plan for adequate time for investments into the test coverage and other planning before we can move product/code changes forward. While that effort isn't currently planned, we recognize that XPS related scenarios have been frustrating for many and we will consider this space as one needing investment. I don't expect we'll be able to make such investments during the .NET 8 release cycle though.

[wstaelens]

• .net core 1.0 (2016)
• .net core 1.1 (2016)
• .net core 2.0 (2017)
• .net core 2.1 (2018)
• .net core 2.2 (2018)
• .net core 3.0 (2019)
• .net core 3.1 (2019)
• .net 5 (2020)
• .net 6 (2021)
• .net 7 (2022)
• .net 8 (2023?)

code of .NET Framework works fine. We were "forced" to move to .net (core). The only problem is that this part of code isn't fully ported and functionality doesn't work anymore compared to .NET Framework. Microsoft's own default drivers produce interleaved piece XPS print jobs but they can't be read anymore.

After ± 7 - 8 years it is again being labeled as "Future". 😞

<frustration>"insert frustrations here"</frustration>

Wonder what the excuse of .net 9 will be 😢