fitwidth: wrong calculation? #30

By Erik on 2016-05-24T13:42:41.418Z

File: img2pdf.py

Line: 806

Using -b 0in:0.5in results in debug output border -> (0.0, 36.0).

I understand that border = (top-bottom-border, left-right-border), according to the documentation.

Thus, newborder should follow the same pattern.

If this is true, fitwidth and fitwidth use the wrong list position of newborder.

if pagesize is not None and imgsize is None:
        def layout_fun(imgwidthpx, imgheightpx, ndpi):
            (...)
            if pagewidth is not None:
                fitwidth = pagewidth-2*newborder[0]
            else:
                fitwidth = None
            if pageheight is not None:
                fitheight = pageheight-2*newborder[1]
            else:
                fitheight = None

fitwidthshould be computed using newborder[1] and fitheight using newborder[0]. Like below:

if pagesize is not None and imgsize is None:
        def layout_fun(imgwidthpx, imgheightpx, ndpi):
            (...)
            if pagewidth is not None:
                fitwidth = pagewidth-2*newborder[1]
            else:
                fitwidth = None
            if pageheight is not None:
                fitheight = pageheight-2*newborder[0]
            else:
                fitheight = None

By josch on 2016-05-25T19:07:49.802Z

I do not understand your bug report. Where do you see the problem?

If I run:

img2pdf --border 1cm:4cm input.jpeg > out.pdf

Then I get a PDF file with a large border on the left and right and a small border at the top and bottom. This is exactly what the documentation says should happen:

  -b L[:L], --border L[:L]
                    [...] One, or two length values can be given as
                    an argument, separated by a colon. One value specifies
                    the minimal border on all four sides. Two values
                    specify the minimal border on the top/bottom and
                    left/right, respectively. [...]

So where is the bug?

By Erik on 2016-05-25T22:40:44.461Z

Well, the technical aspect of the bug is that fitwidth is mixed with the top-bottom-border. And fitheight is mixed with the left-right-border. According to the code snippet I posted above.

Now, to your example. I downloaded a fresh zip and modified the code in question to exclude side effects. I ran your original code and then the modified code. The goal is a PDF with a narrow top-bottom margin and a wider left-right margin.

I opened both PDFs and measured the margins manually. In your_code the top-bottom margins are 0.5in each. In my_code the top-bottom margins are 0.25in each, as expected.

Please refer to the images attached.

Input image with border

0020.jp2

Your code

ve/bin/img2pdf -S 6inx9in -b 0.25in:0.5in -C L -o tmp_your_code.pdf 0020.jp2

tmp_your_code.pdf

Modified code

ve/bin/img2pdf -S 6inx9in -b 0.25in:0.5in -C L -o tmp_my_code.pdf 0020.jp2

tmp_my_code.pdf

By josch on 2016-05-26T06:19:55.790Z

Status changed to closed by commit d78b2cbdbc

*By Erik on 2016-05-24T13:42:41.418Z* File: _img2pdf.py_ Line: _806_ Using `-b 0in:0.5in` results in debug output `border -> (0.0, 36.0)`. I understand that `border = (top-bottom-border, left-right-border)`, according to the documentation. Thus, `newborder` should follow the same pattern. If this is true, `fitwidth` and `fitwidth` use the wrong list position of `newborder`. ``` if pagesize is not None and imgsize is None: def layout_fun(imgwidthpx, imgheightpx, ndpi): (...) if pagewidth is not None: fitwidth = pagewidth-2*newborder[0] else: fitwidth = None if pageheight is not None: fitheight = pageheight-2*newborder[1] else: fitheight = None ``` `fitwidth`should be computed using `newborder[1]` and `fitheight` using `newborder[0]`. Like below: ``` if pagesize is not None and imgsize is None: def layout_fun(imgwidthpx, imgheightpx, ndpi): (...) if pagewidth is not None: fitwidth = pagewidth-2*newborder[1] else: fitwidth = None if pageheight is not None: fitheight = pageheight-2*newborder[0] else: fitheight = None ``` --- *By josch on 2016-05-25T19:07:49.802Z* --- I do not understand your bug report. Where do you see the problem? If I run: img2pdf --border 1cm:4cm input.jpeg > out.pdf Then I get a PDF file with a large border on the left and right and a small border at the top and bottom. This is exactly what the documentation says should happen: -b L[:L], --border L[:L] [...] One, or two length values can be given as an argument, separated by a colon. One value specifies the minimal border on all four sides. Two values specify the minimal border on the top/bottom and left/right, respectively. [...] So where is the bug? --- *By Erik on 2016-05-25T22:40:44.461Z* --- Well, the technical aspect of the bug is that `fitwidth` is mixed with the top-bottom-border. And `fitheight` is mixed with the left-right-border. According to the code snippet I posted above. Now, to your example. I downloaded a fresh zip and modified the code in question to exclude side effects. I ran your original code and then the modified code. The goal is a PDF with a narrow top-bottom margin and a wider left-right margin. I opened both PDFs and measured the margins manually. In your_code the top-bottom margins are 0.5in each. In my_code the top-bottom margins are 0.25in each, as expected. Please refer to the images attached. # Input image with border [0020.jp2](/uploads/437ca4e1196576f4a261c4512cba6dc0/0020.jp2) # Your code `ve/bin/img2pdf -S 6inx9in -b 0.25in:0.5in -C L -o tmp_your_code.pdf 0020.jp2` [tmp_your_code.pdf](/uploads/8406de84c757c4d5cb4cfaf309624d80/tmp_your_code.pdf) # Modified code `ve/bin/img2pdf -S 6inx9in -b 0.25in:0.5in -C L -o tmp_my_code.pdf 0020.jp2` [tmp_my_code.pdf](/uploads/1aec8062f3166528ffd50279435ccbaf/tmp_my_code.pdf) --- *By josch on 2016-05-26T06:19:55.790Z* --- Status changed to closed by commit d78b2cbdbc70b2a1d5a6ed0ce39a30851d9c3bc9

Labels Milestones

fitwidth: wrong calculation? #30

Input image with border

Your code

Modified code