feat(imagick): add antialias option to ImagickImageBackEnd (#209)

[DASPRiD]

Add a $antialias constructor parameter (default true) to allow disabling antialiasing for sharper images, smaller file sizes, and better nearest-neighbor scalability.

Closes #209

[codecov]

Codecov Report

❌ Patch coverage is 60.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.79%. Comparing base (bf7d67c) to head (ec1cc10).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
src/Renderer/Image/ImagickImageBackEnd.php	60.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #235      +/-   ##
============================================
- Coverage     71.81%   71.79%   -0.03%     
- Complexity      995      996       +1     
============================================
  Files            49       49              
  Lines          3151     3155       +4     
============================================
+ Hits           2263     2265       +2     
- Misses          888      890       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vlakoff]

Thanks for adding the antialias mode! Since this hasn't shipped yet, I’d like to suggest a different approach for the implementation.

Currently, adding settings to the constructor creates a long sequence of Flag Arguments. This pattern makes the API harder to read—for example, in new ImagickImageBackEnd('png', 100, false), the values are "mystery guests" that require checking the source code to understand. It also makes the library harder to maintain, as adding any new rendering options in the future would require breaking changes to the constructor signature.

I’d suggest one of the following two patterns to keep the API clean and extensible:

Option A: Fluent "With" Methods

Keep the constructor minimal for required dependencies and use "wither" methods for optional configurations. This is self-documenting and keeps the usage clear.

public function withAntialias($antialias): self {
    $clone = clone $this;
    $clone->antialias = $antialias;
    return $clone;
}
// Usage: $backend = (new ImagickImageBackEnd())->withAntialias(false);

Option B: Configuration Object

If we expect the list of settings to grow (DPI, rendering intents, etc.), passing a dedicated options object is a very scalable way to handle configuration.

final class ImagickOptions {
    public function __construct(
        public readonly string $format = 'png',
        public readonly int $quality = 100,
        public readonly bool $antialias = true,
    ) {}
}
// Usage: $backend = new ImagickImageBackEnd(new ImagickOptions(antialias: false));

---

Option A seems interesting, though for codebase consistency, other such "chained setters" should eventually be implemented for the other settings as well.

Option B may seem redundant compared to just using the constructor with named parameters, but it adds an abstraction layer that is significantly more useful for future maintenance and evolution (e.g., standardizing options across different backends).

Both of these methods introduce new paradigms to the codebase, thus they should be carefully considered. However, I'd like to take the opportunity that this "parameter hell" hasn't been released yet to discard it in favor of a more descriptive approach. What do you think?

[DASPRiD]

Thanks for adding the antialias mode! Since this hasn't shipped yet, I’d like to suggest a different approach for the implementation.

It's actually in 3.1.0 already. We could consider a different approach for 4.x, but not too sure about either approach there.

[DASPRiD]

Although to be fair, fluent setters could be added on top of the current constructor method.

[vlakoff]

I noticed after commenting that the change had already been published. That’s fine — with only three arguments, the current constructor remains acceptable. My proposals are simply ideas to keep in reserve should additional options be introduced in the future.