Issue 105431

Created attachment 65021 [details]
bugdoc with broken preview

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...

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?

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...

AW: Added myself to CC.