Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Split the existing PDFFunction in two classes, a private PDFFunction and a public PDFFunctionFactory, and utilize the latter in PDFDocument to allow various code to access the methods of PDFFunction` #8968

Merged
merged 2 commits into from
Sep 29, 2017
Merged

Split the existing PDFFunction in two classes, a private PDFFunction and a public PDFFunctionFactory, and utilize the latter in PDFDocument to allow various code to access the methods of PDFFunction` #8968

merged 2 commits into from
Sep 29, 2017

Commits on Sep 29, 2017

  1. Remove the unused inline parameter from various methods/functions i… 

    …n `PDFImage`, and change a couple of methods to use Objects rather than plain parameters

The `inline` parameter is passed to a number of methods/functions in `PDFImage`, despite not actually being used. Its value is never checked, nor is it ever assigned to the current `PDFImage` instance (i.e. no `this.inline = inline` exists).
Looking briefly at the history of this code, I was also unable to find a point in time where `inline` was being used.

As far as I'm concerned, `inline` does nothing more than add clutter to already very unwieldy method/function signatures, hence why I'm proposing that we just remove it.
To further simplify call-sites using `PDFImage`/`NativeImageDecoder`, a number of methods/functions are changed to take Objects rather than a bunch of (somewhat) randomly ordered parameters.
    @Snuffleupagus
    Snuffleupagus committed Sep 29, 2017
    Configuration menu
    Copy the full SHA
    5c961c7 View commit details
    Browse the repository at this point in the history

  2. Split the existing PDFFunction in two classes, a private `PDFFuncti… 

    …on` and a public `PDFFunctionFactory``, and utilize the latter in `PDFDocument` to allow various code to access the methods of `PDFFunction`

*Follow-up to PR 8909.*

This requires us to pass around `pdfFunctionFactory` to quite a lot of existing code, however I don't see another way of handling this while still guaranteeing that we can access `PDFFunction` as freely as in the old code.

Please note that the patch passes all tests locally (unit, font, reference), and I *very* much hope that we have sufficient test-coverage for the code in question to catch any typos/mistakes in the re-factoring.
    @Snuffleupagus
    Snuffleupagus committed Sep 29, 2017
    Configuration menu
    Copy the full SHA
    b8ec518 View commit details
    Browse the repository at this point in the history