I think the new API should have multi-page support. It would be useful for pdf, djvu, multi-page tiff, and for looking at individual frames of animated gif, png, etc., to the extent that we write plugins for those.
I wrote a QQuickImageProvider for PDF (using poppler), but requestImage takes only an “id” string to identify the image. So I had to make up a composite id containing both the filename and the page number. (much like a URL format would be, if you had to request multiple pages from a web server) So that’s the next API that needs to have some support for paging. Can “frame” be considered the same as “page”? But I see that you also have a subimage concept in mind. Sometimes (as in icon files, or in any kind of file that also includes a smaller preview image) the sub images would be the same thing at different resolution, right? That is orthogonal to the idea of paging: a PDF file can have multiple pages, and also embedded thumbnails for each page. In order for an image format plugin to be enough to write a PDF reader application, it would need to support paging, and also getting the thumbnails for the pages. In QQuickImageProvider::requestImage, requestedSize can also be given. So that’s one way to specify a thumbnail: if the available thumbnail is near enough to requestedSize, return that instead. The API anyway does not guarantee that you get exactly the size that you ask for. Eventually we could get to the point that a plain Image in QML could be used as a PDF viewer, all by itself. It would also need a paging API. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
