View with cropped margins

[Siep Kroonenberg]

Add option to automatically zoom to the printed part of the page. A user-defined document-wide cropbox might in practice work just as well.

[Adam Reichold (adamreichold)]

Hello again,

I started working on this on pushed a correspoding branch (linked to this bug report). It is still incomplete insofar the crop rects are not cached and hence are missing if a pixmap was taken from the cache instead of just rendered. I'll work on this some more, but the branch could already benefit from testing IMHO.

Best regards, Adam.

[Adam Reichold (adamreichold)]

Hhhmmm, the caching should now work correctly, but there are at least one critical issue: The fit-to-something scale modes can lead to continuous adjustments because the crop box updates the apparent size of the pages which then can change the crop box...

Not sure how to prevent this, for one thing one could make the crop box independent of the current transformation and calculate it only once. But the necessary adjustments when changing the transformations together with tiling seem quite complicated to me...

[Adam Reichold (adamreichold)]

Seems like not updating the crop box on refresh which can lead to temporarily incorrect crop rects (being updated after rendering) but breaks the feedback cycle might be a suitable solution. I also limited the cropping to one-third on each side.

[Siep Kroonenberg (siepo)]

On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold wrote:
> Hhhmmm, the caching should now work correctly, but there are at least
> one critical issue: The fit-to-something scale modes can lead to
> continuous adjustments because the crop box updates the apparent size of
> the pages which then can change the crop box...
>
> Not sure how to prevent this, for one thing one could make the crop box
> independent of the current transformation and calculate it only once.
> But the necessary adjustments when changing the transformations together
> with tiling seem quite complicated to me...

One example where qpdfview got busy recalculating (page 10):

http://mirror.ctan.org/info/latexcourse-rug/latexcourse-rug.pdf

This document uses the LaTeX microtype package, which implements
optical alignment of margins.

As I already mentioned in the bug report: manual cropping would be
an option for me. It would take care of situations where there are
meaningless page decorations or printers marks.

--
Siep Kroonenberg

[Adam Reichold (adamreichold)]

Hello again,

Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold wrote:
>> Hhhmmm, the caching should now work correctly, but there are at least
>> one critical issue: The fit-to-something scale modes can lead to
>> continuous adjustments because the crop box updates the apparent size of
>> the pages which then can change the crop box...
>>
>> Not sure how to prevent this, for one thing one could make the crop box
>> independent of the current transformation and calculate it only once.
>> But the necessary adjustments when changing the transformations together
>> with tiling seem quite complicated to me...
>
> One example where qpdfview got busy recalculating (page 10):
>
> http://mirror.ctan.org/info/latexcourse-rug/latexcourse-rug.pdf
>
> This document uses the LaTeX microtype package, which implements
> optical alignment of margins.

Can you confirm that this happens only when tiling is enabled? I think
there is one more optimization that I can make here: Discarding tiles
only after all visible tiles have been painted (they are taken from the
cache otherwise).

> As I already mentioned in the bug report: manual cropping would be
> an option for me. It would take care of situations where there are
> meaningless page decorations or printers marks.

I think manual cropping is much too tedious for paginated documents to
merit the associated development work.

Best regards, Adam.

[Adam Reichold (adamreichold)]

Hello again,

Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold wrote:
>> Hhhmmm, the caching should now work correctly, but there are at least
>> one critical issue: The fit-to-something scale modes can lead to
>> continuous adjustments because the crop box updates the apparent size of
>> the pages which then can change the crop box...
>>
>> Not sure how to prevent this, for one thing one could make the crop box
>> independent of the current transformation and calculate it only once.
>> But the necessary adjustments when changing the transformations together
>> with tiling seem quite complicated to me...
>
> One example where qpdfview got busy recalculating (page 10):
>
> http://mirror.ctan.org/info/latexcourse-rug/latexcourse-rug.pdf
>
> This document uses the LaTeX microtype package, which implements
> optical alignment of margins.

I think it was simply missing rounding (after recombining crop rects
from several tiles which are already rounded) which I now added. Could
you try out branch revision 1655? Thanks.

> As I already mentioned in the bug report: manual cropping would be
> an option for me. It would take care of situations where there are
> meaningless page decorations or printers marks.
>

Best regards, Adam.

[Siep Kroonenberg (siepo)]

On Mon, Aug 18, 2014 at 05:28:38PM -0000, Adam Reichold wrote:
> Hello again,
>
> Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
> > On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold wrote:
> >> Hhhmmm, the caching should now work correctly, but there are at least
> >> one critical issue: The fit-to-something scale modes can lead to
> >> continuous adjustments because the crop box updates the apparent size of
> >> the pages which then can change the crop box...
> >>
> >> Not sure how to prevent this, for one thing one could make the crop box
> >> independent of the current transformation and calculate it only once.
> >> But the necessary adjustments when changing the transformations together
> >> with tiling seem quite complicated to me...
> >
> > One example where qpdfview got busy recalculating (page 10):
> >
> > http://mirror.ctan.org/info/latexcourse-rug/latexcourse-rug.pdf
> >
> > This document uses the LaTeX microtype package, which implements
> > optical alignment of margins.
>
> Can you confirm that this happens only when tiling is enabled? I think
> there is one more optimization that I can make here: Discarding tiles
> only after all visible tiles have been painted (they are taken from the
> cache otherwise).

It happens with or without tiling, but, unsurprisingly, not at all
magnifications. This is with revision 1655.

> > As I already mentioned in the bug report: manual cropping would be
> > an option for me. It would take care of situations where there are
> > meaningless page decorations or printers marks.
>
> I think manual cropping is much too tedious for paginated documents to
> merit the associated development work.

Ok.

--
Siep Kroonenberg

[Adam Reichold (adamreichold)]

Hello again,

Am 18.08.2014 um 21:37 schrieb Siep Kroonenberg:
> On Mon, Aug 18, 2014 at 05:28:38PM -0000, Adam Reichold wrote:
>> Hello again,
>>
>> Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
>>> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold wrote:
>>>> Hhhmmm, the caching should now work correctly, but there are at least
>>>> one critical issue: The fit-to-something scale modes can lead to
>>>> continuous adjustments because the crop box updates the apparent size of
>>>> the pages which then can change the crop box...
>>>>
>>>> Not sure how to prevent this, for one thing one could make the crop box
>>>> independent of the current transformation and calculate it only once.
>>>> But the necessary adjustments when changing the transformations together
>>>> with tiling seem quite complicated to me...
>>>
>>> One example where qpdfview got busy recalculating (page 10):
>>>
>>> http://mirror.ctan.org/info/latexcourse-rug/latexcourse-rug.pdf
>>>
>>> This document uses the LaTeX microtype package, which implements
>>> optical alignment of margins.
>>
>> Can you confirm that this happens only when tiling is enabled? I think
>> there is one more optimization that I can make here: Discarding tiles
>> only after all visible tiles have been painted (they are taken from the
>> cache otherwise).
>
> It happens with or without tiling, but, unsurprisingly, not at all
> magnifications. This is with revision 1655.

Sorry that this seem to be a bit complicated. I coupled the crop
rectangle life cycle to obsolete pixmaps and made it more explicit when
a valid crop rectangle is available. Continuous rerender because of
scale changes should not be possible anymore using branch revision 1660.
Could you please try that again?

>>> As I already mentioned in the bug report: manual cropping would be
>>> an option for me. It would take care of situations where there are
>>> meaningless page decorations or printers marks.
>>
>> I think manual cropping is much too tedious for paginated documents to
>> merit the associated development work.
>
> Ok.
>

Unrelated question. The document seems strange insofar the cropping is
minimal as the background seems to be only almost white instead of
white. Is that correct and does stem from the usage of microtype?

Beste regards, Adam.

[Siep Kroonenberg (siepo)]

On Tue, Aug 19, 2014 at 06:25:58PM -0000, Adam Reichold wrote:
> Hello again,
>
> Am 18.08.2014 um 21:37 schrieb Siep Kroonenberg:
> > On Mon, Aug 18, 2014 at 05:28:38PM -0000, Adam Reichold wrote:
> >> Hello again,
> >>
> >> Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
> >>> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold wrote:
> >>>
> >>> One example where qpdfview got busy recalculating (page 10):
> >>>
> >>> http://mirror.ctan.org/info/latexcourse-rug/latexcourse-rug.pdf
>
> Sorry that this seem to be a bit complicated. I coupled the crop
> rectangle life cycle to obsolete pixmaps and made it more explicit when
> a valid crop rectangle is available. Continuous rerender because of
> scale changes should not be possible anymore using branch revision 1660.
> Could you please try that again?

The above document now appears fine, but another document does not
(page 8):

ftp://ftp.dell.com/Manuals/all-products/esuprt_desktop/esuprt_optiplex_desktop/optiplex-3010_Owner%27s%20Manual3_en-us.pdf

> Unrelated question. The document seems strange insofar the cropping is
> minimal as the background seems to be only almost white instead of
> white. Is that correct and does stem from the usage of microtype?

I think the `almost white' must be an optical illusion.

The margins are narrow for online use. So for this particular
document, the trim feature would not be needed. The complete package
contains complete sources and instructions to compile a print
version with normal margins.

Regards, and thanks so far.

--
Siep Kroonenberg

[Adam Reichold (adamreichold)]

Hello again,

Am 20.08.2014 um 11:02 schrieb Siep Kroonenberg:
> On Tue, Aug 19, 2014 at 06:25:58PM -0000, Adam Reichold wrote:
>> Hello again,
>>
>> Am 18.08.2014 um 21:37 schrieb Siep Kroonenberg:
>>> On Mon, Aug 18, 2014 at 05:28:38PM -0000, Adam Reichold wrote:
>>>> Hello again,
>>>>
>>>> Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
>>>>> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold wrote:
>>>>>
>>>>> One example where qpdfview got busy recalculating (page 10):
>>>>>
>>>>> http://mirror.ctan.org/info/latexcourse-rug/latexcourse-rug.pdf
>>
>> Sorry that this seem to be a bit complicated. I coupled the crop
>> rectangle life cycle to obsolete pixmaps and made it more explicit when
>> a valid crop rectangle is available. Continuous rerender because of
>> scale changes should not be possible anymore using branch revision 1660.
>> Could you please try that again?
>
> The above document now appears fine, but another document does not
> (page 8):
>
> ftp://ftp.dell.com/Manuals/all-
> products/esuprt_desktop/esuprt_optiplex_desktop/optiplex-3010_Owner%27s
> %20Manual3_en-us.pdf

Can you be specific on the view and graphics settings which trigger the
continuous rendering? (scale mode, tiling, obsolete pixmaps, etc.) I
tried but could not reproduce it...

>> Unrelated question. The document seems strange insofar the cropping is
>> minimal as the background seems to be only almost white instead of
>> white. Is that correct and does stem from the usage of microtype?
>
> I think the `almost white' must be an optical illusion.

It looks white, but the pixel values are not. That's what was irritating
me, but it doesn't matter too much as long as the function does what it
is supposed to.

> The margins are narrow for online use. So for this particular
> document, the trim feature would not be needed. The complete package
> contains complete sources and instructions to compile a print
> version with normal margins.
>
> Regards, and thanks so far.
>

[Siep Kroonenberg (siepo)]

On Wed, Aug 20, 2014 at 07:42:26PM -0000, Adam Reichold wrote:
> Hello again,
>
> Am 20.08.2014 um 11:02 schrieb Siep Kroonenberg:
> > On Tue, Aug 19, 2014 at 06:25:58PM -0000, Adam Reichold wrote:
> >> Hello again,
> >>
> >> Am 18.08.2014 um 21:37 schrieb Siep Kroonenberg:
> >>> On Mon, Aug 18, 2014 at 05:28:38PM -0000, Adam Reichold wrote:
> >>>> Hello again,
> >>>>
> >>>> Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
> >>>>> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold wrote:
> >>>>>
> >
> > ftp://ftp.dell.com/Manuals/all-
> > products/esuprt_desktop/esuprt_optiplex_desktop/optiplex-3010_Owner%27s
> > %20Manual3_en-us.pdf
>
> Can you be specific on the view and graphics settings which trigger the
> continuous rendering? (scale mode, tiling, obsolete pixmaps, etc.) I
> tried but could not reproduce it...

Continuous view. Screenshots of Behaviour-and Graphics settings
tabs:

Screenshot of graphics settings at
https://www.dropbox.com/s/3b36vs2e01bz9me/qpdfview_settings.tgz

With the settings from the screenshot, page 14 gave trouble. I have
experimented with options 'Keep obsolete pixmaps', cache size and
widening and narrowing the document window. The upshot is simply
that different pages give trouble when I vary these.

> >> Unrelated question. The document seems strange insofar the cropping is
> >> minimal as the background seems to be only almost white instead of
> >> white. Is that correct and does stem from the usage of microtype?
> >
> > I think the `almost white' must be an optical illusion.
>
> It looks white, but the pixel values are not. That's what was irritating
> me, but it doesn't matter too much as long as the function does what it
> is supposed to.

If I take a screenshot with the Gimp from a blank area of the
document window and examine the pixel values, they are pure white.

--
Siep Kroonenberg

[Adam Reichold (adamreichold)]

Am 21.08.2014 um 22:05 schrieb Siep Kroonenberg:
> On Wed, Aug 20, 2014 at 07:42:26PM -0000, Adam Reichold wrote:
>> Hello again,
>>
>> Am 20.08.2014 um 11:02 schrieb Siep Kroonenberg:
>>> On Tue, Aug 19, 2014 at 06:25:58PM -0000, Adam Reichold wrote:
>>>> Hello again,
>>>>
>>>> Am 18.08.2014 um 21:37 schrieb Siep Kroonenberg:
>>>>> On Mon, Aug 18, 2014 at 05:28:38PM -0000, Adam Reichold
>>>>> wrote:
>>>>>> Hello again,
>>>>>>
>>>>>> Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
>>>>>>> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold
>>>>>>> wrote:
>>>>>>>
>>>
>>> ftp://ftp.dell.com/Manuals/all-
>>> products/esuprt_desktop/esuprt_optiplex_desktop/optiplex-3010_Owner%27s
>>>
>>>
%20Manual3_en-us.pdf
>>
>> Can you be specific on the view and graphics settings which
>> trigger the continuous rendering? (scale mode, tiling, obsolete
>> pixmaps, etc.) I tried but could not reproduce it...
>
> Continuous view. Screenshots of Behaviour-and Graphics settings
> tabs:
>
> Screenshot of graphics settings at
> https://www.dropbox.com/s/3b36vs2e01bz9me/qpdfview_settings.tgz
>
> With the settings from the screenshot, page 14 gave trouble. I
> have experimented with options 'Keep obsolete pixmaps', cache size
> and widening and narrowing the document window. The upshot is
> simply that different pages give trouble when I vary these.

Hhhmmm, this bad. I used your graphics settings (and tried lower cache
sizes and various view mode) and the worst I could get using revision
1660 was rendering the page twice using fit-to-width (which is
expected since rendering once is need to trim the margins and the
second time is to render fitted after trimmed).

I am sorry that this is so much more tricky than anticipated. Can you
describe what you see, is it rendering on and on or does is flicker
twice? Have you tried rebuilding the branch from scratch? (Sorry, I am
just out of ideas on how to reproduce this...) (I also tried Qt4
versus Qt5 without a difference.)

(Btw. revision 1661 should fix the page border decoration.)

>>>> Unrelated question. The document seems strange insofar the
>>>> cropping is minimal as the background seems to be only almost
>>>> white instead of white. Is that correct and does stem from
>>>> the usage of microtype?
>>>
>>> I think the `almost white' must be an optical illusion.
>>
>> It looks white, but the pixel values are not. That's what was
>> irritating me, but it doesn't matter too much as long as the
>> function does what it is supposed to.
>
> If I take a screenshot with the Gimp from a blank area of the
> document window and examine the pixel values, they are pure white.
>

[Siep Kroonenberg (siepo)]

On Fri, Aug 22, 2014 at 04:52:01PM -0000, Adam Reichold wrote:
> Am 21.08.2014 um 22:05 schrieb Siep Kroonenberg:
> > On Wed, Aug 20, 2014 at 07:42:26PM -0000, Adam Reichold wrote:
> >> Hello again,
> >>
> >> Am 20.08.2014 um 11:02 schrieb Siep Kroonenberg:
> >>> On Tue, Aug 19, 2014 at 06:25:58PM -0000, Adam Reichold wrote:
> >>>> Hello again,
> >>>>
> >>>> Am 18.08.2014 um 21:37 schrieb Siep Kroonenberg:
> >>>>> On Mon, Aug 18, 2014 at 05:28:38PM -0000, Adam Reichold
> >>>>> wrote:
> >>>>>> Hello again,
> >>>>>>
> >>>>>> Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
> >>>>>>> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold
> >>>>>>> wrote:
> >>>>>>>
> >>>
> >>> ftp://ftp.dell.com/Manuals/all-
> >>> products/esuprt_desktop/esuprt_optiplex_desktop/optiplex-3010_Owner%27s
> >>>
> >>>
> %20Manual3_en-us.pdf
> >>
> >> Can you be specific on the view and graphics settings which
> >> trigger the continuous rendering? (scale mode, tiling, obsolete
> >> pixmaps, etc.) I tried but could not reproduce it...
> >
> > Continuous view. Screenshots of Behaviour-and Graphics settings
> > tabs:
> >
> > Screenshot of graphics settings at
> > https://www.dropbox.com/s/3b36vs2e01bz9me/qpdfview_settings.tgz
> >
> > With the settings from the screenshot, page 14 gave trouble. I
> > have experimented with options 'Keep obsolete pixmaps', cache size
> > and widening and narrowing the document window. The upshot is
> > simply that different pages give trouble when I vary these.
>
> Hhhmmm, this bad. I used your graphics settings (and tried lower cache
> sizes and various view mode) and the worst I could get using revision
> 1660 was rendering the page twice using fit-to-width (which is
> expected since rendering once is need to trim the margins and the
> second time is to render fitted after trimmed).
>
> I am sorry that this is so much more tricky than anticipated. Can you
> describe what you see, is it rendering on and on or does is flicker
> twice? Have you tried rebuilding the branch from scratch? (Sorry, I am
> just out of ideas on how to reproduce this...) (I also tried Qt4
> versus Qt5 without a difference.)

As to what I saw:

The problem page is entirely blank, even without a wait symbol, and
the page separator oscillates up and down.

However,I just did a fresh checkout and build and now I cannot
reproduce the problem either with this document.

--
Siep Kroonenberg

[Adam Reichold (adamreichold)]

Am 23.08.2014 um 10:22 schrieb Siep Kroonenberg:
> On Fri, Aug 22, 2014 at 04:52:01PM -0000, Adam Reichold wrote:
>> Am 21.08.2014 um 22:05 schrieb Siep Kroonenberg:
>>> On Wed, Aug 20, 2014 at 07:42:26PM -0000, Adam Reichold wrote:
>>>> Hello again,
>>>>
>>>> Am 20.08.2014 um 11:02 schrieb Siep Kroonenberg:
>>>>> On Tue, Aug 19, 2014 at 06:25:58PM -0000, Adam Reichold wrote:
>>>>>> Hello again,
>>>>>>
>>>>>> Am 18.08.2014 um 21:37 schrieb Siep Kroonenberg:
>>>>>>> On Mon, Aug 18, 2014 at 05:28:38PM -0000, Adam Reichold
>>>>>>> wrote:
>>>>>>>> Hello again,
>>>>>>>>
>>>>>>>> Am 18.08.2014 um 11:56 schrieb Siep Kroonenberg:
>>>>>>>>> On Sun, Aug 17, 2014 at 03:44:52PM -0000, Adam Reichold
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>
>>>>> ftp://ftp.dell.com/Manuals/all-
>>>>> products/esuprt_desktop/esuprt_optiplex_desktop/optiplex-3010_Owner%27s
>>>>>
>>>>>
>> %20Manual3_en-us.pdf
>>>>
>>>> Can you be specific on the view and graphics settings which
>>>> trigger the continuous rendering? (scale mode, tiling, obsolete
>>>> pixmaps, etc.) I tried but could not reproduce it...
>>>
>>> Continuous view. Screenshots of Behaviour-and Graphics settings
>>> tabs:
>>>
>>> Screenshot of graphics settings at
>>> https://www.dropbox.com/s/3b36vs2e01bz9me/qpdfview_settings.tgz
>>>
>>> With the settings from the screenshot, page 14 gave trouble. I
>>> have experimented with options 'Keep obsolete pixmaps', cache size
>>> and widening and narrowing the document window. The upshot is
>>> simply that different pages give trouble when I vary these.
>>
>> Hhhmmm, this bad. I used your graphics settings (and tried lower cache
>> sizes and various view mode) and the worst I could get using revision
>> 1660 was rendering the page twice using fit-to-width (which is
>> expected since rendering once is need to trim the margins and the
>> second time is to render fitted after trimmed).
>>
>> I am sorry that this is so much more tricky than anticipated. Can you
>> describe what you see, is it rendering on and on or does is flicker
>> twice? Have you tried rebuilding the branch from scratch? (Sorry, I am
>> just out of ideas on how to reproduce this...) (I also tried Qt4
>> versus Qt5 without a difference.)
>
> As to what I saw:
>
> The problem page is entirely blank, even without a wait symbol, and
> the page separator oscillates up and down.
>
> However,I just did a fresh checkout and build and now I cannot
> reproduce the problem either with this document.
>

Thanks for staying with me! I'd say we hope it was just a build issue
and continue using the branch and if nothing comes up on your or my end,
I'll merge this into trunk on Sunday evening. (So it hopefully sees more
widespread testing through the dailydebs...)

Best regards, Adam.

[Adam Reichold (adamreichold)]

Also please update to branch revision 1662 where I fine-tuned the
rounding and padding... Thanks!