Investigate ITargetFeature use to redirect target path for EmbeddedPackage and EmbeddedObject (and other) parts.

[tomjebo]

From #1318.

TLDR:
We should investigate using the features (perhaps ITargetFeature) to customize added parts like EmbeddedPackagePart and ImagePart where the target path was specified as a compromise between the apps' specific structures so that we can mimic Excel, Word and PowerPoint's exact targeting behaviors.

MORE:

I was looking at this and I see why EmbeddedPackageParts are saved to a new embeddings folder in the folder of the referencing part. EmbeddedPackagePart is a shared type in ISO 29500-1. That means that it is a target of an explicit relationship of several parts in WordprocessingML, SpreadsheetML and PresentationML documents. However, these documents don't have the same structures wrt where those referencing parts live path-wise. So when the SDK designers were considering how to declaratively specify using XML definitions with a targetPath specification like embeddings or ../embeddings or /embeddings, they couldn't come up with one that would satisfy all three apps. For Excel, it would be ../embeddings but for Word it would be ./embeddings or just embeddings. And PowerPoint is one of those two options. So the alternative was to write front end code or generate more back end code for the front end to mimic the behavior of the three apps. When considering this with all the other behaviors that don't actually impact the consumption of the package by those apps, they opted to just pick one, effectively ./embeddings, and call it a day. I'm sure there are tons of other behaviors like this in the SDK. "Correcting" them all to mimic Office exactly starts to bloat the SDK and approach a large codebase like the apps themselves.

Effectively this is an enhancement to the SDK, vs a bug fix since the produced packages are not broken now. Regarding using features, I see that we generate:

        private sealed class GeneratedFeatures : TypedPartFeatureCollection, ITargetFeature
        {
            public GeneratedFeatures(OpenXmlPart part) : base(part) { }
            string ITargetFeature.Extension => ".bin";
            string ITargetFeature.Name => "image";
            string ITargetFeature.Path => "../media";
        }

So perhaps we can use ITargetFeature to customize this behavior.

[Asbjoedt]

Hi @tomjebo!

I don't know if this is the right place to write this.

EmbeddedObjectParts are saved as ".bin" extension files. Both Excel and Open XML SDK does this. Imitating Excel is the best way to go about this, but the issue is, if you want to extract the embedded objects or convert them to another file format inside of the OOXML package, this is difficult without knowing what file format the embedded object is by targeting the extension and using some conversion routine (ImageMagick, FFmpeg etc.).

Another way to do this is to use magic numbers, but this would require integrating your programs with a file format identification software i.e. DROID or Siegfried. I would prefer to avoid this complexity.

Would it be possible to have all EmbeddedObjectParts saved with original extension to the package?