D18179: PDF: Implement scaling for non-rasterized printing

[Michael Weghorn]

michaelweghorn added a comment.


  In D18179#391664 <https://phabricator.kde.org/D18179#391664>, @aacid wrote:
  
  > Maybe an enum is better than a bool so if in the future more scaling options are implemented we don't need to change the signature again?
  
  
  Sounds reasonable. I'll change that in the next version.

INLINE COMMENTS

> aacid wrote in fileprinter.h:82
> this is not binary compatible, we try not to break the binary compatibility of the okular public classes.
> 
> Add another method (without the default values) and make this one call the new one.
> 
> Same for all the functions you're adding new parameters to.
> 
> Or you can try to convince me that maintainting binary compatibilty is not needed :D

I don't really feel up to the task of convincing you. :D
The only point I can come up with is that your comment in ab96e0c07def2f572a8bb3e32f90e597e6761627 <https://phabricator.kde.org/R223:ab96e0c07def2f572a8bb3e32f90e597e6761627> indicates that that commit //might// have broken binary compatibility already and thus it might be worth considering bumping the so version anyway (in which case I think this here should no longer be any problem, but I haven't really had to deal with binary compatibility in the past).

Otherwise, I don't mind adding the suggested extra methods.

Will those extra methods then stay there forever or can the methods then be "merged" again once another ABI-incompatible change is done?

Just out of curiosity: Do you know of specific applications/third-party generators,... that use libokularcore?

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D18179

To: michaelweghorn, #okular, ngraham, sander
Cc: aacid, fvogt, okular-devel, ngraham, darcyshen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20190112/a3bc6ce7/attachment.html>