diff options
author | Miklos Vajna <vmiklos@collabora.com> | 2020-12-21 21:03:36 +0100 |
---|---|---|
committer | Miklos Vajna <vmiklos@collabora.com> | 2020-12-22 09:07:27 +0100 |
commit | c24d9447b809416575972585a5ad48e14f8d9ad9 (patch) | |
tree | 513939af51445da6058333f907096547c27e2ae3 /dictionaries | |
parent | use string_view in ProcessAttribute (diff) | |
download | core-c24d9447b809416575972585a5ad48e14f8d9ad9.tar.gz core-c24d9447b809416575972585a5ad48e14f8d9ad9.zip |
tdf#138801 vcl: fix lazy-loading of GIF images with logic size
Regression from commit edda1e5fc8113aa4744e32f97c96a3cc311485ca (DOCX
import: lazy-read images without external headers, 2018-04-20), the
immediate problem is that GIF images from docx are now lazy-loaded.
The deeper problem is that GIF images normally only have pixel size and
can have an optional logic size as well (LO-specific extension).
The bugdoc in question is a DOCX file, which contains a .png stream,
which is in fact a GIF image, with that STARDIV extension in it.
Now the initial parsing (that only extracts the metadata) didn't read
the logic size, so the preferred map mode was pixels, but later when the
actual read happened, the preferred map mode changed to mm100.
Thid does not play nicely with writerfilter/ code that sets a different
wrap polygon depending on if the (assumed to be final) map mode is
pixels or not.
Fix the problem by reusing the "is this an animation" GIF parser to also
extract the logic size of the GIF image, if it has one. This way we
still lazy-load the GIF image, but the preferred map mode won't hange
from pixels to mm100 during the real read.
Change-Id: Ia6c66e1c4fa0cb23a1daf537e7179b081ef90def
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108125
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Diffstat (limited to 'dictionaries')
0 files changed, 0 insertions, 0 deletions