Issue 105431 - Initial preview of croped images is wrong
Summary: Initial preview of croped images is wrong
Status: CONFIRMED
Alias: None
Product: Impress
Classification: Application
Component: viewing (show other issues)
Version: OOo 1.0.0
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-28 16:12 UTC by clippka
Modified: 2013-08-07 15:20 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
bugdoc with broken preview (87.81 KB, application/vnd.oasis.opendocument.presentation)
2009-09-28 16:13 UTC, clippka
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description clippka 2009-09-28 16:12:40 UTC
- Open attached bugdoc. Watch preview of slide two, the preview is broken most
of the time. Gets repaired when switching to slide two.
Comment 1 clippka 2009-09-28 16:13:56 UTC
Created attachment 65021 [details]
bugdoc with broken preview
Comment 2 Armin Le Grand 2009-10-02 14:06:15 UTC
AW: Taking a look. I guess it has nothing to do with cropping, but with the
asynchronious bitmap loading. That mechanism relies on the VOC and the OC of the
graphic still existing to get the lazy-load event and do a refresh; this does
not exist since for the previews to render the VOC/OC hierarchy is only
temporarily created. Thus, there will be no refresh callback.
Checking if this is really the case. If yes, it will be necessary to suppress
lazy-load for preview rendering...
Comment 3 Armin Le Grand 2009-10-02 15:16:10 UTC
AW: It's even more complicated; the used graphic is the preview graphic. That's
PrefMapMode and PrefSize is smaller than the original, but the crop values in
logic sizes are applied to the too-small preview graphic. This leads to the
result, that nothing is left from the cropping.

Two possibilities:
(1) Force full graphic load for rendering previews
(2) Give the preview bitmap the same PrefSize as the original would have

I think (2) is better, but i do not know if it's possible. Adding SJ to the task.

AW->SJ: Is (2) possible?
Comment 4 Armin Le Grand 2009-10-02 16:08:20 UTC
AW: Experimented with svtools. When setting the correct size in maPrefSize of
the bitmap in JPEGReader::Read, all is okay. Problem is that the real pixel size
is only available in ReadJPEG in jpeg.c, but this should be solvable.

AW->SJ: Please extend all image loaders which may create a preview image to set
the correct PrefMapMode and PrefSize.

AW->CL: The even better way would be to have the crop definitions not in
absolute logic values, but relative to the bitmap size; anyways at EACH place
the crop values are used they need to be calculated back (using the image's
size) to that relative definitions to do something useful with them. Relative
definitions would also allow to exchange the bitmap WITHOUT the need to adapt
the cropping values. Just my 2 cent...
Comment 5 Armin Le Grand 2009-10-02 16:08:53 UTC
AW: Added myself to CC.