PHPOffice / PHPPresentation / 33611032986

94%

push

github

Both Writers : Point a reference at the part that was written (#948)

* Both Writers : Point a reference at the part that was written

`HashTable` keeps one entry per hash code, so two graphics that compare alike leave a single part
in the archive -- the first of them. Every reference, though, was written from
`getIndexedFilename()`, which counts instances and knows nothing about that collapse. The second
shape therefore named a part nobody had written.

Two identical charts on one slide leave `ppt/charts/chart2.xml` referenced and absent, which is
what PowerPoint offers to repair. The same holds for two identical images, in both formats: in
PPTX the slide's `.rels` names a `ppt/media/` entry that is not there, in ODP `content.xml` names
a `Pictures/` entry missing from the archive. It has to be the same slide -- `AbstractShape`
mixes the container into its hash, so shapes on different slides never collide.

`writtenPart()` reads back the hash index `HashTable::add()` already gives a collapsed shape, and
answers with the graphic whose bytes were written. Where nothing collapsed it answers with the
shape itself, so a deck without duplicates is written exactly as before.

`MetaInfManifest` needed nothing: it walks the hash table already, and so only ever declared the
parts that exist.

* PowerPoint2007 Writer : Give every chart its own part

The hash table deduplicates so that one picture used twice leaves one part in the archive that two
shapes point at. A chart is not that kind of resource. Two charts holding the same numbers are
still two charts: each owns a relationship, a `_rels` of its own and an embedded workbook, and
collapsing them leaves a slide pointing at a part that was never written.

The image index is what already tells one instance from another, so mixing it into the hash code
keeps two charts apart while leaving everything a chart is compared on intact.

* Tests : Cover a reference resolving to the part that was written

Each of the th... (continued)

15 of 16 new or added lines in 5 files covered. (93.75%)

10903 of 11602 relevant lines covered (93.98%)

72.09 hits per line