Calligra/Libs/Image Data

The image data class (KoImageData) stores the pixel data for any embedded image that can be viewed with, for example, the picture shape.

Usecases

1

I load a KWord document it has several images of different sizes. To speed up loading I want to have no images actually parsed until after the loading of the odf is done. To allow loading a document with many many images fast the delayed parsing/loading should be done based on showing. So only load an image when its being painted the first time.

2

I load a KPresenter document with an image being shown many times resulting in many KoShapes with the same image file in the odf store. The image should be shared and only exist in memory a minimum amount of times. Even when the file is added multiple times it should use the save data.

3

A user has two documents open and decides to copy the image in one document to the other document. Since the same process is used we should be able to copy the image while making it exist a minimum amount of times in memory.

4

A KWord or Karbon document is loaded with very high resolution images. say; 4000x4000 the image is only 10cm on the page and effectively only some 400 pixels wide when showing on screen. For speed and memory reasons we should allow the file to be stored on disk and only a small pixmap to stay resident in memory. Ideally we have a good control over the pixel size of the pixmap available on KoImageData so the picture-shape can be smart when the user resizes the shape.

5

A KWord or Karbon document is loaded with very high resolution images. say; 4000x4000 the image is only 10cm on the page and effectively only some 400 pixels wide at default zoom. Per usecase 4 we will not load the full image, which would lead to the problem that if watching the image at 400% zoom it would be very blocky. It would be nice to have the picture shape be able to get access to the higher resolution image to show this when needed.

Suggested (ideal) workflow;

• Loading a KoImageData object will in case of a larger image (say > 250kb) just store it in your temp dir and not do cache anything in memory.
• Loading a smaller image can easilly just parse it as a QImage
• When the picture shape is painted it will first ask if there is a pixmap pre-loaded. If that is not the case the picture shape will start a QTimer::singleShot to load the image. When its loaded the KoImageData emits a signal which causes the picture shape to request an update().
• KPresenter calls a new method KoImageCollection::setPreferredPictureResolution(const QSize &ppi); with the size of its canvas if it were to be in presentation mode.
• When the picture shape gets painted and no pixmap is present it calculates the size of the picture in this preferred pixel size.
• The KoImageData::pixmap(const QSize &size); method is called (note new argument) to prepare the proper image size.
• The picture shape stores a 'quality' internally to allow users in KWord and other apps that don't use the setPreferredPictureResolution call to change the pixmap size dynamically using the tool.
• The picture shape detects when the user zooms in 'too' far and then starts a background loading of the qimage after which it can repaint a more appropriate resolution image for the current zoom level.

Notes

Loading from ODF the xml links to a relative file outside the odf store. Likely something on the local filesystem. We should detect this and store the full url and not load anything. We should set a file watch to detect the file from changing on the filesystem and invalidate the pixmaps if it changes. Causing it to be loaded again when viewed.

Loading from ODF the xml links to a relative file outside the odf store. I'm not sure if ODF supports this, but if it does... For remote urls (http:// etc) we have to consider the network not being there we also have to consider the security implications of silently accessing a remote url (tracking).

The above is not entirely true. Normally the xml links to a file inside the odf store. Additionally ODF as well as SVG support storing images embedded in the xml as bas64 encoded data.