Upgrading to 1.4 causes problems with doc.text() ?

[westwick]

Previously in 1.3.5 I was able to draw text on the right side of the pdf with the following line:

doc.text(doc.internal.pageSize.width - 10, 30, 'Align Right?', null, null, 'right');

But this stopped working in 1.4, which you can see here:
http://jsbin.com/mevemoyula/edit?html,js,output

[westwick]

Looks like the problem is with doc.internal.pageSize - width property has been replaced with getWidth() getter? Would be really nice to include things like that in release notes :D

I would personally consider this a breaking change so if you are following semver it should be a major 2.0 release instead of minor 1.x. Great library though thanks for all the hard work!

[Uzlopak]

Yes, we replaced it, because it was breaking in older browsers.
But you have to admit, that internal(!) functions are not part of the actual API, so theoretically it is allowed to have "breaking code" in it.
And I disagree, that we have to use version 2.0.0 according to semver. Changing the first digit means, that the code has complete different API and/or completely refactored codebase so there is no guarantee for you to use your old code for it . Changing the second digit means that the code can have breaking code changes. Changing the last digit means, there are only Bugfixes and or minor changes.

In the future we will try not to forget such small changes in the changelog.

[westwick]

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Major is not just 'complete different API', but any breaking change. I would consider this an incompatible API change whether or not it's internal since you expose it anyway but just my opinion not trying to argue :)

Do you have a different suggestion to draw something on the right side of the PDF without using the internal methods? I was also using this pagesize.width value to draw a line all the way across the page for example.

[Uzlopak]

Actually it would make more sense, to have x-value to be the distance from right and not from left.

But this would be something for jsPDF 2.0

Like I wrote, it was breaking in older browsers. So we changed it to a simpler method. And you know it would be totally childish, to change it to jsPDF 2.0, if it was just this change.

And yeah... then just use pageSize.getWidth(). And it has to be a function call, or else it wont work.

[westwick]

So there is no way to do it without using internal methods, which you expose publically (so is it really truly 'internal' if they aren't private?), and then introduce breaking changes in a minor version (minor version should only "add functionality in a backwards-compatible manner"). Whether or not you think it's childish, these are the guidelines semver has laid out, but it's also ok for you to just say you aren't using semver. (Laravel for example does their own versioning system to avoid constant major version increases)

To stay compliant with semver you could have left the .width property available while updating all internal methods to getWidth() for older browsers. This would keep things backwards compatible :)

[Uzlopak]

internal is used for interaction of the plugin-system. So you could say this is the plugin programming interface (PPI?) and not the application programming interface (API). So we are still semver conform.

If you decide to dock to the PPI and not to the API, then this is your own choice.

Your suggestion to keep .width wouldn't have worked. You need a function call, so that you have a variable width per Instance and not global. This was previously realized by Getter accessor function, which was implemented in ECMA 5.1. So Devs reported, that Browsers like IE 8 would not work because of this implementation. We still have the goal to be as much as browser compatible as possible. So we had to implement the access to width and height as methods.

[westwick]

Whether or not it is your intent if you google 'doc.internal.pagesize.width' you can see many people use these variables for drawing various things. And what about the plugin developers?

Regardless of the exact implementation details, I don't see why you couldn't have left the previous implementation in place while also adding the new one to use internally, thus fixing old browser issues while also maintaining backwards compatibility. Anyway, that's just my opinion, I've said enough here! Have a great day.

[Uzlopak]

I don't see why you couldn't have left the previous implementation in place while also adding the new one to use internally,

I answered it above.

[westwick]

There are ways around that was my point. 👋

[Uzlopak]

There was not a way around that.