Simon Hausmann schreef op 11-5-2015 om 09:21: > On Saturday, May 09, 2015 09:59:18 PM Andre Somers wrote: >> On 8-5-2015 18:47, Hausmann Simon wrote: >>> Hi, >>> >>> If the public API would allow you to implement what the folks at KDAB did >>> at http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ , would >>> that help your use case? >> What they basicaly did was reimplement the Quick elements they were >> using, if I understood it right from an earlier time I read that blog, >> and then solve all kinds of issues with rendering that were already >> solved inside Qt itself... So, it comes down to implementing the >> elements of Quick 1 on your own again for the elements you need, or >> something close to it. It is what I called "major work" in my first >> reply. And indeed: I guess doing this requires heavy use of private API. >> So far, QML and Quick are not all that friendly for C++-side extensions... > This doesn't match my understanding of what they have done at all. I > understand their article as having basically "visited" all items in the scene > and having had to use private API to access the data so that they can > implement printing outside of Qt Quick, but still using standard Qt Quick > elements. > > But perhaps I misread it. What is your understanding after re-reading it?
Ok, indeed, you're right. They didn't re-implement the actual items, they "just" reimplemented everything needed in those items to render them. Indeed: visiting each item and then figuring out how to render it completely from scratch. But they only did that for a handfull of items, and not taking into account all possibly relevant properties because they didn't use them as much. > >> I read about an effort of a different rendering backend for Quick a >> while ago done by Digia at that time that sounded like it could work to >> solve the issue, but that was not freely available to take a look at so >> I don't know for sure it would fit the use case. > In theory it would be a fit - at least in terms of being able to get all the > right data passed down to the print engine to do high quality text printing. > > > Anyway, could you elaborate a bit on your printing needs? > > Do you need pagination? Yes, we do that, but in our case we don't need dynamic pages. We know for each report how pages there are, and we created a Page object to represent it. Each page object gets placed below the previous page in the scene with a small spacing, so a preview looks natural. In an actual printing run, we simply do a render of the rect for each page we need to appear in the print output. > > How about text flow - do you need to change the line breaking in order for > your text to appear? Not sure what you mean here. We do use text layout with line breaking and the likes, and I have had to duplicate some features from Quick2's Text item too (automatic adaptation of font size to make contents fit, for instance). > With regards to images: Do you have high-res versions of images available for > print and lower res images for screen display? We have some custom content (rendered graphs) that indeed are target-resolution-aware. Plain images are not; the few simple images we have are simply scaled. > What about the level of detail: Does your print-out contain _exactly_ the same > content as on the screen or are there more or less details? (I'm thinking > about borders, transparency, etc.) See above: yes, we do. We have measures to make sure that for instance a line can be quite thin on a high-resolution device, but it doesn't disapear when rendered on a low resolution one (like the screen). André _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development