https://bugs.documentfoundation.org/show_bug.cgi?id=112538
tryag...@navit-project.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tryag...@navit-project.org
--- Comment #8 from tryag...@navit-project.org ---
I think the problem is not related to Operating system used.
It's most probably related to screen resolution of the system where the
document was created and the one where it's being viewed.
I hit a similar problem on a single computer running linux.
To reproduce the problem, run Impress inside Xephyr nested X server with -dpi
option value different to display resolution used at document creation time,
and see all cropped images being broken. Restart Xephyr with the same -dpi as
your desktop, and see the document is fine again.
Same problem seems to exist in openoffice (and is reported to be present in
staroffice too), see
https://forum.openoffice.org/en/forum/viewtopic.php?f=10&t=73858 .
Cropped images in my file have fo:clip attributes inside content.xml file.
These attributes define cropped area by offsets expressed in centimetres.
I guess, current display resolution at document creation time is used to
convert pixels of actual image to centimetres. Then, at document display time,
we probably have no information (or do not use it) about resolution used at
document creation time, using instead current display resolution. So we get
wrong part of image with a wrong scale.
I think storing cropped area size in pixel units would be a fix.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
