On 19 May 2015, at 21:00, Konstantin Ritt <[email protected]> wrote:
> IIUC, this already covered by the idea: since we can not (currently?) support
> animated "pages", we treat both a multi-page tiff and an animated gif as a
> document with N "frames”.
I thought so.
>
> What you described sounds more like mipmap support. We can not say "this is a
> thumbnail for page N" by looking at the image size only.
Some PDF viewers are rendering their own thumbnails anyway, and ignoring the
built-in ones, because built-in thumbnails are often missing, and if they exist
they have a fixed smallish size. So in practice it works well enough to
translate a requested image size into a decision: to use the built-in thumbnail
which is close enough in size (saving some CPU time), or to just render the
actual size as requested. (PDF is a complex case compared to other image
formats, because it can contain vector graphics, text etc. But there are other
vector graphic formats which can contain raster thumbnails.) Some formats
(like ico and icns) provide several sizes in the same file, so it’s again a
matter of choosing the closest one to what was requested. And some formats can
efficiently provide a smaller image using a subset of the data rather than
having to take the maximum resolution and scale it down, so again, choose the
closest available size. Whether or not the application chooses to treat one
particular size as the “thumbnail” resolution is just an application detail.
The thumbnails might be expected to be scalable anyway in some particular UI
(as in Finder on OS X), but then there is some lag while the re-rendering is
done after each change in scale. So if you ask for 72px and a PDF happens to
be using that size for page thumbnails, great, let’s use it; but if you ask for
120px, then the page needs to be rendered at that resolution, although 72px
would be OK temporarily (scaled up to 120px) while the re-rendering takes place.
So maybe it would be useful to have a flag specifying whether it’s OK to use
close-enough sizes, or to require that the image be returned at exactly the
requested size.
Of course if everyone wants an additional API to specifically limit the output
to whatever is identified as a thumbnail in image formats which provide them,
that’s probably a good idea too. But then you would often fail to get an image
at all, and need to follow up by requesting a non-thumbnail anyway.
> property int page: 0
> readonly property int pagesCount: pdf.framesCount
> ImageDocument {
> id: pdf
> source: "path/to/file.pdf"
> }
> Image {
> id: pageViewer
> source: pdf
> frame: page
> }
> Image {
> id: pagePreview
> source: pdf
> frame: page
> mipLevel: -1
> }
ImageDocument has its uses, but I don’t think it should be required for all use
cases. A full-featured PDF viewer needs such an object to access the text
objects on each page (with bounding boxes), document metadata etc. A less
full-featured one would not. And anyway the backend for it is outside the
scope of the imageformats API, isn’t it? PDF has a very extensive feature set,
beyond what most image formats provide. So more like import package.pdf and
then have a PdfDocument, which links to whatever PDF library on its own.
Whereas simple all-format image viewers wouldn’t need those features, so they
could get by with Image.
So I’d add both frame and frameCount to Image, which would be enough in this
example, and then you don’t need the ImageDocument for such a simple use case.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
