josch/img2pdf

Fork 10

[Feature request] Add the ability to resize the input image(s) to common paper sizes for the pages of the output PDF and add the ability to use portrait or landscape page mode for all or some of the pages in the output PDF #2

New issue

Closed

opened 2021-04-25 19:54:11 +00:00 by josch · 0 comments

josch commented

2021-04-25 19:54:11 +00:00

Owner

By josch on 2015-03-15T09:41:45.568Z

Created by: sahwar

It would have been nice if img2pdf had the ability to resize (all or some of) the images to common paper sizes (like A4, etc.) for the pages of the output PDF file[1]. The ability to make all (or some) of the pages in portrait or landscape PDF page mode is also good to have[2]. I don't know how difficult it is to implement things like these, but they would definitely be very useful. Maybe ImageMagick could be used for this (for the resizing of the input images to common paper sizes (these paper sizes pixels presented in terms of (approximate) pixel (px) dimensions, I guess?)). Something similar is available in GhostScript.

[1] This should probably make a PDF viewer list the common paper size of the output PDF produced by img2pdf in its Properties information dialog.
[2] This should probably make a PDF viewer list the page mode (portrait or landscape) of the output PDF produced by img2pdf in its Properties information dialog. However, I'm not sure if the PDF format supports having some pages in portrait page mode and some in landscape page mode in the SAME PDF file (maybe it does, but how would that be displayed in the output PDF's Properties?).

Imported comments:

By josch on 2015-03-06 14:23:26 UTC

I think you are mixing some things here.

For example I do not understand your comments about a PDF viewer. What does the user interface of a PDF viewer have to do with your feature request?

Using ImageMagick for resizing will not be useful because img2pdf is about lossless conversion and any resize operation involving ImageMagick will be lossy.

Making the page size different from the image size is indeed very easy. It is also possible to have different page sizes in the same PDF document.

What I'm wondering about is how to best make this configurable for the user.

What is the reason you'd find this useful? Is it for easier printing of the resulting PDF?

I think one way to solve this, is to have an additional option which forces a specific page size. So far, the page size was calculated from the input image size and the requested dpi. When forcing the page size, the image would just be centered in the page.

Maybe in addition to that it would be useful to have another new option which can be given instead of the current --dpi option and which will scale the input image such that it will fill a certain percentage of the requested page size.

So please propose a solution for these problems. The issue is not a technical one but one of how to present this new functionality in the user interface.

By sahwar on 2015-03-06 15:17:36 UTC

@josch

Yes, I may really be mixing things, sorry about that... The comments about the PDF viewer are irrelevant now that I think about it, sorry for that...

Using ImageMagick for resizing will not be useful because img2pdf is about lossless conversion and any resize operation involving ImageMagick will be lossy.

Yeah, I know, I don't know why I didn't think of that while posting that part of the feature request. :\

Making the page size different from the image size is indeed very easy. It is also possible to have different page sizes in the same PDF document.

That's exactly what I wanted to know, thanks for clarifying that!

What is the reason you'd find this useful? Is it for easier printing of the resulting PDF?

Yes, that's precisely for printing purposes as I guess that it's maybe not so important for viewing purposes(?).

What I'm wondering about is how to best make this configurable for the user.

Yes, that's what this is about.

I think one way to solve this, is to have an additional option which forces a specific page size.
[...]
When forcing the page size, the image would just be centered in the page.

Yes, that's a very good idea!
Maybe a syntax such as the following might do the trick:

--pagesize (pxwidth)x(pxheight)_1-200,300-405,450-500;(width)x(height)_201-299,406-449,501-600;...

This could force the page size for the specified page range. Revise it as needed.

So far, the page size was calculated from the input image size and the requested dpi.

This should be left as the default behaviour as it is now.

Maybe in addition to that it would be useful to have another new option which can be given instead of the current --dpi option and which will scale the input image such that it will fill a certain percentage of the requested page size.

The --dpi option shouldn't be removed, but adding an option for scaling the input image(s) (which is to be used instead of (or in conjunction with???) --dpi) is a very good solution. However, I can't distinguish between scaling the input images and forcing a page size for the PDF as I'm not really acquainted with the PDF file format specification. Sorry if that makes communiction about this feature request a bit difficult to comprehend, I'm doing my best in trying to put this feature request into words, but I'm not a native user of English. :\

P.S. Thanks for having the patience to discuss this feature request even though my wording is a bit clunky (and I do mix or fail to distinguish between some concepts...).

By josch on 2015-03-06 17:54:31 UTC

Thanks for your feedback.

As for PDF limitations, you can imagine every PDF page to be like a vector graphic image. You have literally all the freedom you want when it comes to arranging the objects on the page, resizing them, rotating them or applying other transformations.

I think that a complex syntax would be the wrong approach because there exists other software which is perfectly capable to concatenate individual PDF files together. So img2pdf could be run several times with different page sizes, and another software could then concatenate the resulting PDF files into a single document. One software that comes to my mind that can do this concatenation (in a lossless way) is pdftk. I rather have multiple pieces of software but have each piece do well what it does instead of having a single piece of software that can do everything.

So what do you think of the following proposal:

Remove the -x and -y options and replace them by a new option called --pagesize which accepts either AxB formatted arguments specifying the page size explicitly or arguments like A1, A2, A3, A4, A5 or letter for some predefined paper size settings. This option cannot be specified at the same time as --dpi.

Add another option called --bordersize which allows to give the absolute border size in points. If the --dpi option is also specified, then the pdf page will be increased to have that border on all four sides. If the --pagesize option is specified, then the image will be shrank such that the image has at least the given amount of distance from the page border.

I can also imagine that it could be useful to give the image size as a value relative to the page size instead of specifying the border value. Would this be useful for you or does specifying the border size suffice?

By sahwar on 2015-03-06 18:52:24 UTC

@josch

Thanks for the minimalistic explanation about the limitations of the PDF file format.

Personally, I don't find my proposed syntax to be that complex. Here's the same example as in my previous post but with an added explanation in case you didn't understand it:

--pagesize 1200x600_1-200,300-405,450-500;1000x400_201-299,406-449,501-600;...

The above means 'force page size 1200x600 (in pixels) for pages 1-200, 300-405, 450-500, force page size 1000x400 (in pixels) for pages 201-299, 406-449, 501-600' all for the same output PDF file.

However, I agree with you that adding a ton of features to the program just for the sake of adding them is pointless and using pdftk to (losslessly) concatenate (i.e. combine) the output PDFs into a single output PDF is a very good way and avoids having to add a (rather complex) syntax as the one I showed above to img2pdf because I'm also in favor of the UNIX program design philosophy (i.e. "The Unix philosophy emphasizes building short, simple, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. The Unix philosophy favors composability as opposed to monolithic design. --Wikipedia").

I rather have multiple pieces of software but have each piece do well what it does instead of having a single piece of software that can do everything.

Ditto.

Remove the -x and -y options and replace them by a new option called --pagesize which accepts either AxB formatted arguments specifying the page size explicitly or arguments like A1, A2, A3, A4, A5 or letter for some predefined paper size settings.

Yes, --pagesize could be like that. However, it's perhaps wise not to remove the -x and -y options because someone may want to use just one of them and not both as required by --pagesize AxB.

This option cannot be specified at the same time as --dpi.

Why not? Do the current options -x and -y not work if used in conjunction with --dpi? I'm asking because I haven't tried to use them at the same time.

Add another option called --bordersize which allows to give the absolute border size in points. If the --dpi option is also specified, then the pdf page will be increased to have that border on all four sides. If the --pagesize option is specified, then the image will be shrank such that the image has at least the given amount of distance from the page border.

Yes, another good idea, --bordersize sounds nice. But all of that functionality should definitely be explained in detail in the README.md so as to avoid dumb questions and confusion.

I can also imagine that it could be useful to give the image size as a value relative to the page size instead of specifying the border value. Would this be useful for you or does specifying the border size suffice?

Why not have both if you're going to implement something like that anyway (though I'm not sure if I really understand what you mean by that and I also don't know if --bordersize and the other proposed thing could be used together - I think that you mean that they can't be used together)? :)

Other than that, you've great ideas about how and what to implement for this feature request!

By josch on 2015-03-06 19:04:47 UTC

You will see that I pushed a commit about half an hour ago which replaces the -x and -y option with the --pagesize option. It caters for being able to only specifying one of them by allowing xB and Ax formats as well.

The --dpi option controls how big the output pdf page is by giving the dots per inch. It thus does not make sense to use it together with another option that controls how big the output pdf page is. Another change I committed half an hour ago makes this clear by making those two options mutually exclusive.

I prefer to explain commandline arguments in the --help output. That way, even a man page can easily be generated using help2man. The README.md can be used to give some examples and a general overview.

Lets call the other additional option --imgsize. It can either be given in

AxB or Ax or xB forms, specifying the image size explicitly
or can be given in the form A%xB% or A%x or xB% in which case it will scale the width or height of the image to A, respectively B percent of the size it would otherwise have
or can be given in the form A%%xB%% or A%%x or xB%% in which ase it will scale the width or height of the image to A, respectively B percent of the page size
or a combination of the above like AxB%% or A%xB or A%%xB%

This option cannot be specified together with the --bordersize option.

Addendum: the --bordersize option should allow a format of either A, A:B, A:B:C or A:B:C:D. The first option means a border size of A for all four sides, the second option means a border size of A for top and bottom and B for left and right, the third option means a top border of A, a left and right border of B and a bottom border of C while the last option specifies the border size for all four borders. This works analog as the CSS margin or padding options.

2nd addendum: with the --bordersize option the image will be scaled without changing the aspect ratio such that it touches two borders exactly. If more fine grained control over image size is required, then the --imgsize option should be used instead. This way, the --bordersize option is just a convenient short hand that makes it easy to generate printable pdf images of maximum printable size.

3rd addendum: I could also go wild and add an option to position the image on the page but unless somebody has a real use case for that I'll not add this and just keep the image centered in all scenarios.

By sahwar on 2015-03-06 19:56:07 UTC

@josch

Well, if --pagesize/-s replaces -x- and -y completely and enables the inclusion of just width or just height, then I don't see any problem with the removal of -x and -y and I salute your commit!

When I said to include detailed information in README.md, I actually meant the --help option or the man img2pdf option, but maybe you should add more specific examples of usage in the README.md for noobs like me (though I myself have used img2pdf many times before). :)

Do you plan on adding a man page for img2pdf (I'm not aware if it is currently available)? I don't really see the point in adding one as --help does the same thing and they'll be identical in terms of content, but you may want to add it for the sake of completeness (if you haven't already done that).

--imgsize and --bordersize sound great, nice work! I hope that there won't be many bugs related to this commit.

P.S. BTW, does $ pip install img2pdf fetch and install the latest version?

By xiota on 2015-03-06 20:17:40 UTC

@josch I tried the new --pagesize / -s option, and it appears to work as expected. I am relieved that it is not as cumbersome as sahwar's proposal would have been.

You are still working on --imgsize and --bordersize? Are they really necessary? Will anyone use them? After they are implemented, what's next? Multiple images per page? Spacing between images? Offsetting the images? Creation of presentation handouts with notes... Etc? (As you mentioned earlier...) There are other tools that provide these features (such as pdftk and pdfjam).

By josch on 2015-03-06 21:04:56 UTC

@xiota I see your point. I was thinking about arranging multiple images on a page today as well but not as a possible plan for a future addition but because I was pondering whether the --imgsize and --bordersize options would go too much in the direction of feature bloat.

So I'm still thinking about --imgsize and --bordersize and whether I should add them. One reason would be that if I add shorthands like "A4" or "letter" to the --pagesize options to make printing easier, then it is certainly needed to allow a border because most consumer printers I've seen do not allow borderless printing.

So maybe I'll not add --imgsize but only --bordersize to keep things simple...

img2pdf is meant to be a simple converter from one to the other. There already exist features like multi-page support (multiple input images will result in a pdf with multiple pages) which could easily be achieved by letting img2pdf convert one image at a time and concatenate the result with pdftk. It's hard to find the line where features stop being useful and just bloatware.

So thanks for giving your 2 cents, they are definitely appreciated. I hope I find a good balance in this case.

By sahwar on 2015-03-06 21:41:31 UTC

@josch
I guess that --bordersize will be enough, adding --imgsize may be an overkill and something that leads to a feature bloat. Perhaps if someone wants the functionality of --imgsize, they'll be able to fork img2pdf and implement it themselves.

img2pdf is great even without the above options, so you decide whether or not to include them.

By josch on 2016-02-02T18:59:25.370Z

Status changed to closed

By josch on 2016-02-02T18:59:25.680Z

This problem should now finally be taken care of with the 0.2.0 release.

*By josch on 2015-03-15T09:41:45.568Z* *Created by: sahwar* It would have been nice if `img2pdf` had the ability to resize (all or some of) the images to common paper sizes (like A4, etc.) for the pages of the output PDF file[1]. The ability to make all (or some) of the pages in portrait or landscape PDF page mode is also good to have[2]. I don't know how difficult it is to implement things like these, but they would definitely be very useful. Maybe ImageMagick could be used for this (for the resizing of the input images to common paper sizes (these paper sizes pixels presented in terms of (approximate) pixel (px) dimensions, I guess?)). Something similar is available in GhostScript. [1] This should probably make a PDF viewer list the common paper size of the output PDF produced by `img2pdf` in its Properties information dialog. [2] This should probably make a PDF viewer list the page mode (portrait or landscape) of the output PDF produced by `img2pdf` in its Properties information dialog. However, I'm not sure if the PDF format supports having some pages in portrait page mode and some in landscape page mode in the **SAME** PDF file (maybe it does, but how would that be displayed in the output PDF's Properties?). **Imported comments:** *By josch on 2015-03-06 14:23:26 UTC* I think you are mixing some things here. For example I do not understand your comments about a PDF viewer. What does the user interface of a PDF viewer have to do with your feature request? Using ImageMagick for resizing will not be useful because img2pdf is about *lossless* conversion and any resize operation involving ImageMagick will be lossy. Making the page size different from the image size is indeed very easy. It is also possible to have different page sizes in the same PDF document. What I'm wondering about is how to best make this configurable for the user. What is the reason you'd find this useful? Is it for easier printing of the resulting PDF? I think one way to solve this, is to have an additional option which forces a specific page size. So far, the page size was calculated from the input image size and the requested dpi. When forcing the page size, the image would just be centered in the page. Maybe in addition to that it would be useful to have another new option which can be given instead of the current --dpi option and which will scale the input image such that it will fill a certain percentage of the requested page size. So please propose a solution for these problems. The issue is not a technical one but one of how to present this new functionality in the user interface. *By sahwar on 2015-03-06 15:17:36 UTC* @josch Yes, I may really be mixing things, sorry about that... The comments about the PDF viewer are irrelevant now that I think about it, sorry for that... > Using ImageMagick for resizing will not be useful because img2pdf is about lossless conversion and any resize operation involving ImageMagick will be lossy. Yeah, I know, I don't know why I didn't think of that while posting that part of the feature request. :\ > Making the page size different from the image size is indeed very easy. It is also possible to have different page sizes in the same PDF document. That's exactly what I wanted to know, thanks for clarifying that! > What is the reason you'd find this useful? Is it for easier printing of the resulting PDF? Yes, that's precisely for printing purposes as I guess that it's maybe not so important for viewing purposes(?). >What I'm wondering about is how to best make this configurable for the user. Yes, that's what this is about. > I think one way to solve this, is to have an additional option which forces a specific page size. > [...] > When forcing the page size, the image would just be centered in the page. Yes, that's a very good idea! Maybe a syntax such as the following might do the trick: ``` --pagesize (pxwidth)x(pxheight)_1-200,300-405,450-500;(width)x(height)_201-299,406-449,501-600;... ```` This could force the page size for the specified page range. Revise it as needed. >So far, the page size was calculated from the input image size and the requested dpi. This should be left as the default behaviour as it is now. > Maybe in addition to that it would be useful to have another new option which can be given instead of the current --dpi option and which will scale the input image such that it will fill a certain percentage of the requested page size. The `--dpi` option shouldn't be removed, but adding an option for scaling the input image(s) (which is to be used instead of (or in conjunction with???) `--dpi`) is a very good solution. However, I can't distinguish between scaling the input images and forcing a page size for the PDF as I'm not really acquainted with the PDF file format specification. Sorry if that makes communiction about this feature request a bit difficult to comprehend, I'm doing my best in trying to put this feature request into words, but I'm not a native user of English. :\ P.S. Thanks for having the patience to discuss this feature request even though my wording is a bit clunky (and I do mix or fail to distinguish between some concepts...). *By josch on 2015-03-06 17:54:31 UTC* Thanks for your feedback. As for PDF limitations, you can imagine every PDF page to be like a vector graphic image. You have literally all the freedom you want when it comes to arranging the objects on the page, resizing them, rotating them or applying other transformations. I think that a complex syntax would be the wrong approach because there exists other software which is perfectly capable to concatenate individual PDF files together. So img2pdf could be run several times with different page sizes, and another software could then concatenate the resulting PDF files into a single document. One software that comes to my mind that can do this concatenation (in a lossless way) is pdftk. I rather have multiple pieces of software but have each piece do well what it does instead of having a single piece of software that can do everything. So what do you think of the following proposal: Remove the -x and -y options and replace them by a new option called --pagesize which accepts either AxB formatted arguments specifying the page size explicitly or arguments like A1, A2, A3, A4, A5 or letter for some predefined paper size settings. This option cannot be specified at the same time as --dpi. Add another option called --bordersize which allows to give the absolute border size in points. If the --dpi option is also specified, then the pdf page will be increased to have that border on all four sides. If the --pagesize option is specified, then the image will be shrank such that the image has at least the given amount of distance from the page border. I can also imagine that it could be useful to give the image size as a value relative to the page size instead of specifying the border value. Would this be useful for you or does specifying the border size suffice? *By sahwar on 2015-03-06 18:52:24 UTC* @josch Thanks for the minimalistic explanation about the limitations of the PDF file format. Personally, I don't find my proposed syntax to be *that* complex. Here's the same example as in my previous post but with an added explanation in case you didn't understand it: ```` --pagesize 1200x600_1-200,300-405,450-500;1000x400_201-299,406-449,501-600;... The above means 'force page size 1200x600 (in pixels) for pages 1-200, 300-405, 450-500, force page size 1000x400 (in pixels) for pages 201-299, 406-449, 501-600' all for the same output PDF file. ```` However, I agree with you that adding a ton of features to the program just for the sake of adding them is pointless and using `pdftk` to (losslessly) concatenate (i.e. combine) the output PDFs into a single output PDF is a very good way and avoids having to add a (*rather* complex) syntax as the one I showed above to `img2pdf` because I'm also in favor of the UNIX program design philosophy (i.e. "The Unix philosophy emphasizes building short, simple, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. The Unix philosophy favors composability as opposed to monolithic design. --Wikipedia"). > I rather have multiple pieces of software but have each piece do well what it does instead of having a single piece of software that can do everything. Ditto. > Remove the `-x` and `-y` options and replace them by a new option called `--pagesize` which accepts either AxB formatted arguments specifying the page size explicitly or arguments like A1, A2, A3, A4, A5 or letter for some predefined paper size settings. Yes, `--pagesize` could be like that. However, it's perhaps wise **not** to remove the `-x` and `-y` options because someone may want to use just one of them and not *both* as required by `--pagesize AxB`. > This option cannot be specified at the same time as `--dpi`. Why not? Do the current options `-x` and `-y` not work if used in conjunction with `--dpi`? I'm asking because I haven't tried to use them at the same time. > Add another option called `--bordersize` which allows to give the absolute border size in points. If the `--dpi` option is also specified, then the pdf page will be increased to have that border on all four sides. If the `--pagesize` option is specified, then the image will be shrank such that the image has at least the given amount of distance from the page border. Yes, another good idea, `--bordersize` sounds nice. But all of that functionality should definitely be explained in detail in the `README.md` so as to avoid dumb questions and confusion. > I can also imagine that it could be useful to give the image size as a value relative to the page size instead of specifying the border value. Would this be useful for you or does specifying the border size suffice? Why not have both if you're going to implement something like that anyway (though I'm not sure if I really understand what you mean by that and I also don't know if `--bordersize` and the other proposed thing could be used together - I think that you mean that they **can't** be used together)? :) Other than that, you've great ideas about how and what to implement for this feature request! *By josch on 2015-03-06 19:04:47 UTC* You will see that I pushed a commit about half an hour ago which replaces the -x and -y option with the --pagesize option. It caters for being able to only specifying one of them by allowing xB and Ax formats as well. The --dpi option controls how big the output pdf page is by giving the dots per inch. It thus does not make sense to use it together with another option that controls how big the output pdf page is. Another change I committed half an hour ago makes this clear by making those two options mutually exclusive. I prefer to explain commandline arguments in the --help output. That way, even a man page can easily be generated using help2man. The README.md can be used to give some examples and a general overview. Lets call the other additional option --imgsize. It can either be given in - AxB or Ax or xB forms, specifying the image size explicitly - or can be given in the form A%xB% or A%x or xB% in which case it will scale the width or height of the image to A, respectively B percent of the size it would otherwise have - or can be given in the form A%%xB%% or A%%x or xB%% in which ase it will scale the width or height of the image to A, respectively B percent of the page size - or a combination of the above like AxB%% or A%xB or A%%xB% This option cannot be specified together with the --bordersize option. Addendum: the --bordersize option should allow a format of either A, A:B, A:B:C or A:B:C:D. The first option means a border size of A for all four sides, the second option means a border size of A for top and bottom and B for left and right, the third option means a top border of A, a left and right border of B and a bottom border of C while the last option specifies the border size for all four borders. This works analog as the CSS margin or padding options. 2nd addendum: with the --bordersize option the image will be scaled without changing the aspect ratio such that it touches two borders exactly. If more fine grained control over image size is required, then the --imgsize option should be used instead. This way, the --bordersize option is just a convenient short hand that makes it easy to generate printable pdf images of maximum printable size. 3rd addendum: I could also go wild and add an option to position the image on the page but unless somebody has a real use case for that I'll not add this and just keep the image centered in all scenarios. *By sahwar on 2015-03-06 19:56:07 UTC* @josch Well, if `--pagesize`/`-s` replaces `-x-` and `-y` completely and enables the inclusion of just width or just height, then I don't see any problem with the removal of `-x` and `-y` and I salute your commit! When I said to include detailed information in `README.md`, I actually meant the `--help` option or the `man img2pdf` option, but maybe you should add more specific examples of usage in the `README.md` for noobs like me (though I myself have used `img2pdf` many times before). :) Do you plan on adding a man page for `img2pdf` (I'm not aware if it is currently available)? I don't really see the point in adding one as `--help` does the same thing and they'll be identical in terms of content, but you may want to add it for the sake of completeness (if you haven't already done that). `--imgsize` and `--bordersize` sound great, nice work! I hope that there won't be many bugs related to this commit. P.S. BTW, does `$ pip install img2pdf` fetch and install the latest version? *By xiota on 2015-03-06 20:17:40 UTC* @josch I tried the new --pagesize / -s option, and it appears to work as expected. I am relieved that it is not as cumbersome as sahwar's proposal would have been. You are still working on --imgsize and --bordersize? Are they really necessary? Will anyone use them? After they are implemented, what's next? Multiple images per page? Spacing between images? Offsetting the images? Creation of presentation handouts with notes... Etc? (As you mentioned earlier...) There are other tools that provide these features (such as pdftk and pdfjam). *By josch on 2015-03-06 21:04:56 UTC* @xiota I see your point. I was thinking about arranging multiple images on a page today as well but not as a possible plan for a future addition but because I was pondering whether the --imgsize and --bordersize options would go too much in the direction of feature bloat. So I'm still thinking about --imgsize and --bordersize and whether I should add them. One reason would be that if I add shorthands like "A4" or "letter" to the --pagesize options to make printing easier, then it is certainly needed to allow a border because most consumer printers I've seen do not allow borderless printing. So maybe I'll not add --imgsize but only --bordersize to keep things simple... img2pdf is meant to be a simple converter from one to the other. There already exist features like multi-page support (multiple input images will result in a pdf with multiple pages) which could easily be achieved by letting img2pdf convert one image at a time and concatenate the result with pdftk. It's hard to find the line where features stop being useful and just bloatware. So thanks for giving your 2 cents, they are definitely appreciated. I hope I find a good balance in this case. *By sahwar on 2015-03-06 21:41:31 UTC* @josch I guess that `--bordersize` will be enough, adding `--imgsize` may be an overkill and something that leads to a feature bloat. Perhaps if someone wants the functionality of `--imgsize`, they'll be able to fork `img2pdf` and implement it themselves. `img2pdf` is great even without the above options, so you decide whether or not to include them. --- *By josch on 2016-02-02T18:59:25.370Z* --- Status changed to closed --- *By josch on 2016-02-02T18:59:25.680Z* --- This problem should now finally be taken care of with the 0.2.0 release.