LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-09-20 09:49:15 +03:00
Code Issues Packages Projects Releases Wiki Activity
116f82d21a
ladybird/Userland/Libraries/LibPDF/ColorSpace.h

268 lines
9.1 KiB
C
Raw Normal View History

LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
/*
LibPDF: Propagate ColorSpace errors
2022-03-06 03:52:00 +03:00
* Copyright (c) 2021-2022, Matthew Olsson <mattco@serenityos.org>
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-09 03:23:00 +03:00
#include <AK/DeprecatedFlyString.h>
Everywhere: Fix badly-formatted includes In 7c5e30daaa615ad3a2ef55222423a747ac0a1227, the focus was "only" on Userland/Libraries/, whereas this commit cleans up the remaining headers in the repo, and any new badly-formatted include.
2023-01-02 17:15:14 +03:00
#include <AK/Forward.h>
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
#include <LibGfx/Color.h>
LibPDF: Use proper ICC profiles for ICCBasedColorSpace
2023-07-19 04:35:49 +03:00
#include <LibGfx/ICC/Profile.h>
LibPDF: Use Variant<Color, PaintStyle> instead of Color for ColorSpaces This is in anticipation of Pattern color space support which does not yield a simple color.
2023-12-05 15:51:42 +03:00
#include <LibGfx/PaintStyle.h>
LibPDF: Implement SeparationColorSpace Requires PDF::Function, which isn't implemented yet, so this has no visual effect yet.
2023-11-04 23:02:28 +03:00
#include <LibPDF/Function.h>
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
#include <LibPDF/Value.h>
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
#define ENUMERATE_COLOR_SPACE_FAMILIES(V) \
V(DeviceGray, true) \
V(DeviceRGB, true) \
V(DeviceCMYK, true) \
V(CalGray, false) \
V(CalRGB, false) \
V(Lab, false) \
V(ICCBased, false) \
V(Indexed, false) \
LibPDF: Allow /Pattern to be used directly as a color space name Per spec: "If the color space is one that can be specified by a name and no additional parameters (DeviceGray, DeviceRGB, DeviceCMYK, and certain cases of Pattern), the name may be specified directly." We still don't implement /Pattern color spaces, but now we no longer crash trying to look up the potentially-nonexistent /ColorSpace dictionary on the page object when /Pattern is used directly as color space name. On top of #21514, reduces number of crashes on 300 random PDFs from the web (the first 300 from 0000.zip from https://pdfa.org/new-large-scale-pdf-corpus-now-publicly-available/) from 42 (14%) to 34 (11%).
2023-10-20 18:12:38 +03:00
V(Pattern, true) \
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
V(Separation, false) \
V(DeviceN, false)
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
namespace PDF {
LibPDF: Use Variant<Color, PaintStyle> instead of Color for ColorSpaces This is in anticipation of Pattern color space support which does not yield a simple color.
2023-12-05 15:51:42 +03:00
typedef Variant<Gfx::Color, NonnullRefPtr<Gfx::PaintStyle>> ColorOrStyle;
class Renderer;
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
class ColorSpaceFamily {
public:
LibPDF: Rename ColorSpaceFamily function to may_be_specified_directly() It used to be called ColorSpaceFamily::never_needs_parameters(). But in the cpp file, the macro arg was called ever_needs_parameters, and the spec says "If the color space is one that can be specified by a name and no additional parameters (DeviceGray, DeviceRGB, DeviceCMYK, and certain cases of Pattern), the name may be specified directly." so let's use that language here. No behavior change.
2023-10-20 18:11:03 +03:00
ColorSpaceFamily(DeprecatedFlyString name, bool may_be_specified_directly)
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
: m_name(move(name))
LibPDF: Rename ColorSpaceFamily function to may_be_specified_directly() It used to be called ColorSpaceFamily::never_needs_parameters(). But in the cpp file, the macro arg was called ever_needs_parameters, and the spec says "If the color space is one that can be specified by a name and no additional parameters (DeviceGray, DeviceRGB, DeviceCMYK, and certain cases of Pattern), the name may be specified directly." so let's use that language here. No behavior change.
2023-10-20 18:11:03 +03:00
, m_may_be_specified_directly(may_be_specified_directly)
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
{
}
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-08 05:48:11 +03:00
DeprecatedFlyString name() const { return m_name; }
LibPDF: Rename ColorSpaceFamily function to may_be_specified_directly() It used to be called ColorSpaceFamily::never_needs_parameters(). But in the cpp file, the macro arg was called ever_needs_parameters, and the spec says "If the color space is one that can be specified by a name and no additional parameters (DeviceGray, DeviceRGB, DeviceCMYK, and certain cases of Pattern), the name may be specified directly." so let's use that language here. No behavior change.
2023-10-20 18:11:03 +03:00
bool may_be_specified_directly() const { return m_may_be_specified_directly; }
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-09 03:23:00 +03:00
static PDFErrorOr<ColorSpaceFamily> get(DeprecatedFlyString const&);
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
LibPDF: Rename ColorSpaceFamily function to may_be_specified_directly() It used to be called ColorSpaceFamily::never_needs_parameters(). But in the cpp file, the macro arg was called ever_needs_parameters, and the spec says "If the color space is one that can be specified by a name and no additional parameters (DeviceGray, DeviceRGB, DeviceCMYK, and certain cases of Pattern), the name may be specified directly." so let's use that language here. No behavior change.
2023-10-20 18:11:03 +03:00
#define ENUMERATE(name, may_be_specified_directly) static ColorSpaceFamily name;
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
ENUMERATE_COLOR_SPACE_FAMILIES(ENUMERATE)
#undef ENUMERATE
LibPDF: Add ColorSpaceFamily::operator== No behavior change.
2023-11-06 15:23:48 +03:00
bool operator==(ColorSpaceFamily const& other) const
{
return m_name == other.m_name;
}
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
private:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-09 03:23:00 +03:00
DeprecatedFlyString m_name;
LibPDF: Rename ColorSpaceFamily function to may_be_specified_directly() It used to be called ColorSpaceFamily::never_needs_parameters(). But in the cpp file, the macro arg was called ever_needs_parameters, and the spec says "If the color space is one that can be specified by a name and no additional parameters (DeviceGray, DeviceRGB, DeviceCMYK, and certain cases of Pattern), the name may be specified directly." so let's use that language here. No behavior change.
2023-10-20 18:11:03 +03:00
bool m_may_be_specified_directly;
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
};
LibPDF: Move color space creation from Renderer to ColorSpace
2022-03-24 20:08:08 +03:00
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
class ColorSpace : public RefCounted<ColorSpace> {
public:
LibPDF: Pass Renderer to ColorSpace
2023-12-07 16:45:44 +03:00
static PDFErrorOr<NonnullRefPtr<ColorSpace>> create(Document*, NonnullRefPtr<Object>, Renderer&);
static PDFErrorOr<NonnullRefPtr<ColorSpace>> create(DeprecatedFlyString const&, Renderer&);
static PDFErrorOr<NonnullRefPtr<ColorSpace>> create(Document*, NonnullRefPtr<ArrayObject>, Renderer&);
LibPDF: Move color space creation from Renderer to ColorSpace
2022-03-24 20:08:08 +03:00
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
virtual ~ColorSpace() = default;
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
virtual PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const = 0;
virtual PDFErrorOr<ColorOrStyle> style(ReadonlySpan<Value> arguments) const
{
Vector<float, 4> float_arguments;
for (auto& argument : arguments)
float_arguments.append(argument.to_float());
return style(float_arguments);
}
LibPDF: Add more knowledge to ColorSpaces classes ColorSpaces now can tell users how many components they expect, and the default decode array that should be used when converting unit bit sequences into color space component input values during image rendering.
2022-11-24 20:43:31 +03:00
virtual int number_of_components() const = 0;
LibPDF: Add spec link to default_decode()
2023-11-03 08:44:41 +03:00
virtual Vector<float> default_decode() const = 0; // "TABLE 4.40 Default Decode arrays"
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
virtual ColorSpaceFamily const& family() const = 0;
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
};
class DeviceGrayColorSpace final : public ColorSpace {
public:
LibPDF: Propagate ColorSpace errors
2022-03-06 03:52:00 +03:00
static NonnullRefPtr<DeviceGrayColorSpace> the();
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
LibPDF: Move color space creation from Renderer to ColorSpace
2022-03-24 20:08:08 +03:00
~DeviceGrayColorSpace() override = default;
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Add more knowledge to ColorSpaces classes ColorSpaces now can tell users how many components they expect, and the default decode array that should be used when converting unit bit sequences into color space component input values during image rendering.
2022-11-24 20:43:31 +03:00
int number_of_components() const override { return 1; }
Vector<float> default_decode() const override;
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::DeviceGray; }
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
private:
DeviceGrayColorSpace() = default;
};
class DeviceRGBColorSpace final : public ColorSpace {
public:
LibPDF: Propagate ColorSpace errors
2022-03-06 03:52:00 +03:00
static NonnullRefPtr<DeviceRGBColorSpace> the();
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
LibPDF: Move color space creation from Renderer to ColorSpace
2022-03-24 20:08:08 +03:00
~DeviceRGBColorSpace() override = default;
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Add more knowledge to ColorSpaces classes ColorSpaces now can tell users how many components they expect, and the default decode array that should be used when converting unit bit sequences into color space component input values during image rendering.
2022-11-24 20:43:31 +03:00
int number_of_components() const override { return 3; }
Vector<float> default_decode() const override;
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::DeviceRGB; }
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
private:
DeviceRGBColorSpace() = default;
};
class DeviceCMYKColorSpace final : public ColorSpace {
public:
LibPDF: Make DeviceCMYKColorSpace::the() fallible No behavior change.
2024-01-31 04:59:50 +03:00
static ErrorOr<NonnullRefPtr<DeviceCMYKColorSpace>> the();
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
LibPDF: Move color space creation from Renderer to ColorSpace
2022-03-24 20:08:08 +03:00
~DeviceCMYKColorSpace() override = default;
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Add more knowledge to ColorSpaces classes ColorSpaces now can tell users how many components they expect, and the default decode array that should be used when converting unit bit sequences into color space component input values during image rendering.
2022-11-24 20:43:31 +03:00
int number_of_components() const override { return 4; }
Vector<float> default_decode() const override;
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::DeviceCMYK; }
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
private:
DeviceCMYKColorSpace() = default;
};
LibPDF: Sketch out DeviceN color spaces a bit Documents using them now show render-time diagnostics instead of asserting that number of parameters passed to a color don't match whatever number of channels the previously-set color space had. Fixes two asserts on the `-n 500` 0000.zip test set.
2023-10-24 20:26:20 +03:00
class DeviceNColorSpace final : public ColorSpace {
public:
LibPDF: Pass Renderer to ColorSpace
2023-12-07 16:45:44 +03:00
static PDFErrorOr<NonnullRefPtr<DeviceNColorSpace>> create(Document*, Vector<Value>&& parameters, Renderer&);
LibPDF: Sketch out DeviceN color spaces a bit Documents using them now show render-time diagnostics instead of asserting that number of parameters passed to a color don't match whatever number of channels the previously-set color space had. Fixes two asserts on the `-n 500` 0000.zip test set.
2023-10-24 20:26:20 +03:00
~DeviceNColorSpace() override = default;
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Sketch out DeviceN color spaces a bit Documents using them now show render-time diagnostics instead of asserting that number of parameters passed to a color don't match whatever number of channels the previously-set color space had. Fixes two asserts on the `-n 500` 0000.zip test set.
2023-10-24 20:26:20 +03:00
int number_of_components() const override;
Vector<float> default_decode() const override;
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::DeviceN; }
private:
LibPDF: Implement DeviceNColorSpace
2023-11-06 15:54:59 +03:00
DeviceNColorSpace(NonnullRefPtr<ColorSpace>, NonnullRefPtr<Function>);
LibPDF: Sketch out DeviceN color spaces a bit Documents using them now show render-time diagnostics instead of asserting that number of parameters passed to a color don't match whatever number of channels the previously-set color space had. Fixes two asserts on the `-n 500` 0000.zip test set.
2023-10-24 20:26:20 +03:00
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:19:34 +03:00
Vector<ByteString> m_names;
LibPDF: Implement DeviceNColorSpace
2023-11-06 15:54:59 +03:00
NonnullRefPtr<ColorSpace> m_alternate_space;
NonnullRefPtr<Function> m_tint_transform;
Vector<Value> mutable m_tint_output_values;
LibPDF: Sketch out DeviceN color spaces a bit Documents using them now show render-time diagnostics instead of asserting that number of parameters passed to a color don't match whatever number of channels the previously-set color space had. Fixes two asserts on the `-n 500` 0000.zip test set.
2023-10-24 20:26:20 +03:00
};
LibPDF: Implement CalGrayColorSpace I haven't seen this being used in the wild, but it's used in Tests/LibPDF/colorspaces.pdf.
2023-11-02 15:49:34 +03:00
class CalGrayColorSpace final : public ColorSpace {
public:
static PDFErrorOr<NonnullRefPtr<CalGrayColorSpace>> create(Document*, Vector<Value>&& parameters);
~CalGrayColorSpace() override = default;
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Implement CalGrayColorSpace I haven't seen this being used in the wild, but it's used in Tests/LibPDF/colorspaces.pdf.
2023-11-02 15:49:34 +03:00
int number_of_components() const override { return 1; }
Vector<float> default_decode() const override;
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::CalGray; }
private:
CalGrayColorSpace() = default;
Array<float, 3> m_whitepoint { 0, 0, 0 };
Array<float, 3> m_blackpoint { 0, 0, 0 };
float m_gamma { 1 };
};
LibPDF: Add support for the CalRGB ColorSpace This isn't tested all that well, as the PDF I am testing with only uses it for black (which is trivial). It can be tested further when LibPDF is able to process more complex PDFs that actually use this color space non-trivially.
2021-05-28 00:03:29 +03:00
class CalRGBColorSpace final : public ColorSpace {
public:
LibPDF: Move color space creation from Renderer to ColorSpace
2022-03-24 20:08:08 +03:00
static PDFErrorOr<NonnullRefPtr<CalRGBColorSpace>> create(Document*, Vector<Value>&& parameters);
~CalRGBColorSpace() override = default;
LibPDF: Add support for the CalRGB ColorSpace This isn't tested all that well, as the PDF I am testing with only uses it for black (which is trivial). It can be tested further when LibPDF is able to process more complex PDFs that actually use this color space non-trivially.
2021-05-28 00:03:29 +03:00
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Add more knowledge to ColorSpaces classes ColorSpaces now can tell users how many components they expect, and the default decode array that should be used when converting unit bit sequences into color space component input values during image rendering.
2022-11-24 20:43:31 +03:00
int number_of_components() const override { return 3; }
Vector<float> default_decode() const override;
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::CalRGB; }
LibPDF: Add support for the CalRGB ColorSpace This isn't tested all that well, as the PDF I am testing with only uses it for black (which is trivial). It can be tested further when LibPDF is able to process more complex PDFs that actually use this color space non-trivially.
2021-05-28 00:03:29 +03:00
private:
CalRGBColorSpace() = default;
Array<float, 3> m_whitepoint { 0, 0, 0 };
Array<float, 3> m_blackpoint { 0, 0, 0 };
Array<float, 3> m_gamma { 1, 1, 1 };
Array<float, 9> m_matrix { 1, 0, 0, 0, 1, 0, 0, 0, 1 };
};
LibPDF: Add basic ICCBased color space handling
2022-03-24 20:08:43 +03:00
class ICCBasedColorSpace final : public ColorSpace {
public:
LibPDF: Pass Renderer to ColorSpace
2023-12-07 16:45:44 +03:00
static PDFErrorOr<NonnullRefPtr<ColorSpace>> create(Document*, Vector<Value>&& parameters, Renderer&);
LibPDF: Add basic ICCBased color space handling
2022-03-24 20:08:43 +03:00
~ICCBasedColorSpace() override = default;
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Implement ICCBasedColorSpace::number_of_components() We now no longer crash on images that use an ICC-based color space. Reduces number of crashes on 300 random PDFs from the web (the first 300 from 0000.zip from https://pdfa.org/new-large-scale-pdf-corpus-now-publicly-available/) from 81 (27%) to 64 (21%). Also fixes all remaining crashes in 411_getting_started_with_instruments.pdf and 513_high_efficiency_image_file_format.pdf.
2023-10-20 04:54:34 +03:00
int number_of_components() const override;
LibPDF: Add more knowledge to ColorSpaces classes ColorSpaces now can tell users how many components they expect, and the default decode array that should be used when converting unit bit sequences into color space component input values during image rendering.
2022-11-24 20:43:31 +03:00
Vector<float> default_decode() const override;
LibPDF: Refactor parsing of ColorSpaces ColorSpaces can be specified in two ways: with a stream as operands of the color space operations (CS/cs), or as a separate PDF object, which is then referred to by other means (e.g., from Image XObjects and other entities). These two modes of addressing a ColorSpace are slightly different and need to be addressed separately. However, the current implementation embedded the full logic of the first case in the routine that created ColorSpace objects. This commit refactors the creation of ColorSpace to support both cases. First, a new ColorSpaceFamily class encapsulates the static aspects of a family, like its name or whether color space construction never requires parameters. Then we define the supported ColorSpaceFamily objects. On top of this also sit a breakage on how ColorSpaces are created. Two methods are now offered: one only providing construction of no-argument color spaces (and thus taking a simple name), and another taking an ArrayObject, hence used to create ColorSpaces requiring arguments. Finally, on top of *that* two ways to get a color space in the Renderer are made available: the first creates a ColorSpace with a name and a Resources dictionary, and another takes an Object. These model the two addressing modes described above.
2022-11-24 07:40:24 +03:00
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::ICCBased; }
LibPDF: Add basic ICCBased color space handling
2022-03-24 20:08:43 +03:00
LibPDF: Extract ICCBasedColorSpace::sRGB() helper
2023-10-20 15:17:14 +03:00
static NonnullRefPtr<Gfx::ICC::Profile> sRGB();
LibPDF: Add basic ICCBased color space handling
2022-03-24 20:08:43 +03:00
private:
LibPDF: Use proper ICC profiles for ICCBasedColorSpace
2023-07-19 04:35:49 +03:00
ICCBasedColorSpace(NonnullRefPtr<Gfx::ICC::Profile>);
static RefPtr<Gfx::ICC::Profile> s_srgb_profile;
NonnullRefPtr<Gfx::ICC::Profile> m_profile;
LibPDF: Don't reallocate Vectors in ICCBasedColorSpace all the time Microoptimization; according to ministat a bit faster: ``` N Min Max Median Avg Stddev x 50 1.0179932 1.0561159 1.0315337 1.0333617 0.0094757426 + 50 1.000875 1.0427601 1.0208509 1.0201902 0.01066116 Difference at 95.0% confidence -0.0131715 +/- 0.00400208 -1.27463% +/- 0.387287% (Student's t, pooled s = 0.0100859) ```
2024-01-09 04:22:22 +03:00
mutable Vector<float, 4> m_components;
mutable Vector<u8, 4> m_bytes;
LibPDF: Use MatrixMatrixConversion when possible Reduces time spent rendering page 3 of 0000849.pdf from 1.32s to 1.13s on my machine. Also reduces the time to run Meta/test_pdf.py on 0000.zip (without 0000849.pdf) from 56s to 54s.
2024-01-09 03:52:14 +03:00
Optional<Gfx::ICC::MatrixMatrixConversion> m_map;
LibPDF: Add basic ICCBased color space handling
2022-03-24 20:08:43 +03:00
};
LibPDF: Sketch out Lab color space Same as other recent color spaces: Enough to make us not assert, but not enough to actually produce color. Fixes 2 asserts on the `-n 500` 0000.zip pdfa dataset.
2023-10-24 21:13:04 +03:00
class LabColorSpace final : public ColorSpace {
public:
static PDFErrorOr<NonnullRefPtr<LabColorSpace>> create(Document*, Vector<Value>&& parameters);
~LabColorSpace() override = default;
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Sketch out Lab color space Same as other recent color spaces: Enough to make us not assert, but not enough to actually produce color. Fixes 2 asserts on the `-n 500` 0000.zip pdfa dataset.
2023-10-24 21:13:04 +03:00
int number_of_components() const override { return 3; }
Vector<float> default_decode() const override;
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::Lab; }
private:
LabColorSpace() = default;
LibPDF: Implement LabColorSpace
2023-11-02 16:52:43 +03:00
Array<float, 3> m_whitepoint { 0, 0, 0 };
Array<float, 3> m_blackpoint { 0, 0, 0 };
Array<float, 4> m_range { -100, 100, -100, 100 };
LibPDF: Sketch out Lab color space Same as other recent color spaces: Enough to make us not assert, but not enough to actually produce color. Fixes 2 asserts on the `-n 500` 0000.zip pdfa dataset.
2023-10-24 21:13:04 +03:00
};
LibPDF: Implement IndexedColorSpace
2023-11-03 08:49:04 +03:00
class IndexedColorSpace final : public ColorSpace {
public:
LibPDF: Pass Renderer to ColorSpace
2023-12-07 16:45:44 +03:00
static PDFErrorOr<NonnullRefPtr<ColorSpace>> create(Document*, Vector<Value>&& parameters, Renderer&);
LibPDF: Implement IndexedColorSpace
2023-11-03 08:49:04 +03:00
~IndexedColorSpace() override = default;
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Implement IndexedColorSpace
2023-11-03 08:49:04 +03:00
int number_of_components() const override { return 1; }
Vector<float> default_decode() const override;
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::Indexed; }
private:
IndexedColorSpace(NonnullRefPtr<ColorSpace>);
NonnullRefPtr<ColorSpace> m_base;
int m_hival { 0 };
Vector<u8> m_lookup;
};
LibPDF: Add smoke-and-mirror implementation of SeparationColorSpace None of the methods actually do anything, but we now create an actual SeparationColorSpace object for /Separation color spaces. This fixes a crash on page 810 of pdf_reference_1-7.pdf. Previously, we'd log a "separation color space not supported" error, which would lead to Renderer not updating its current color space. It'd stay a DeviceCYMK color space, which would then later assert when it got a 1-argument array as color (which now the SeparationColorSpace gets instead, which logs an "unimplemented" error for that instead of asserting).
2023-07-23 23:55:10 +03:00
class SeparationColorSpace final : public ColorSpace {
public:
LibPDF: Pass Renderer to ColorSpace
2023-12-07 16:45:44 +03:00
static PDFErrorOr<NonnullRefPtr<SeparationColorSpace>> create(Document*, Vector<Value>&& parameters, Renderer&);
LibPDF: Add smoke-and-mirror implementation of SeparationColorSpace None of the methods actually do anything, but we now create an actual SeparationColorSpace object for /Separation color spaces. This fixes a crash on page 810 of pdf_reference_1-7.pdf. Previously, we'd log a "separation color space not supported" error, which would lead to Renderer not updating its current color space. It'd stay a DeviceCYMK color space, which would then later assert when it got a 1-argument array as color (which now the SeparationColorSpace gets instead, which logs an "unimplemented" error for that instead of asserting).
2023-07-23 23:55:10 +03:00
~SeparationColorSpace() override = default;
LibPDF: Move ColorSpace::style() to take ReadonlySpan<float> All ColorSpace subclasses converted to float anyways, and this allows us to save lots of float->Value->float conversions during image color space processing. A bit faster: ``` N Min Max Median Avg Stddev x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916 + 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046 Difference at 95.0% confidence -0.0234004 +/- 0.00442595 -2.32785% +/- 0.440287% (Student's t, pooled s = 0.0111541) ```
2024-01-09 05:36:21 +03:00
PDFErrorOr<ColorOrStyle> style(ReadonlySpan<float> arguments) const override;
LibPDF: Implement two SeparationColorSpace methods Actually using separation color spaces still doesn't work, but we now no longer assert on them when they're used. Fixes 2 crashes on the `-n 500` 0000.zip pdfa dataset.
2023-10-24 20:39:58 +03:00
int number_of_components() const override { return 1; }
LibPDF: Add smoke-and-mirror implementation of SeparationColorSpace None of the methods actually do anything, but we now create an actual SeparationColorSpace object for /Separation color spaces. This fixes a crash on page 810 of pdf_reference_1-7.pdf. Previously, we'd log a "separation color space not supported" error, which would lead to Renderer not updating its current color space. It'd stay a DeviceCYMK color space, which would then later assert when it got a 1-argument array as color (which now the SeparationColorSpace gets instead, which logs an "unimplemented" error for that instead of asserting).
2023-07-23 23:55:10 +03:00
Vector<float> default_decode() const override;
ColorSpaceFamily const& family() const override { return ColorSpaceFamily::Separation; }
private:
LibPDF: Implement SeparationColorSpace Requires PDF::Function, which isn't implemented yet, so this has no visual effect yet.
2023-11-04 23:02:28 +03:00
SeparationColorSpace(NonnullRefPtr<ColorSpace>, NonnullRefPtr<Function>);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:19:34 +03:00
ByteString m_name;
LibPDF: Implement SeparationColorSpace Requires PDF::Function, which isn't implemented yet, so this has no visual effect yet.
2023-11-04 23:02:28 +03:00
NonnullRefPtr<ColorSpace> m_alternate_space;
NonnullRefPtr<Function> m_tint_transform;
Vector<Value> mutable m_tint_output_values;
LibPDF: Add smoke-and-mirror implementation of SeparationColorSpace None of the methods actually do anything, but we now create an actual SeparationColorSpace object for /Separation color spaces. This fixes a crash on page 810 of pdf_reference_1-7.pdf. Previously, we'd log a "separation color space not supported" error, which would lead to Renderer not updating its current color space. It'd stay a DeviceCYMK color space, which would then later assert when it got a 1-argument array as color (which now the SeparationColorSpace gets instead, which logs an "unimplemented" error for that instead of asserting).
2023-07-23 23:55:10 +03:00
};
LibPDF: Split ColorSpace into a different class for each color space While unnecessary at the moment, this will allow for more fine-grained control when complex color spaces get added.
2021-05-28 00:01:37 +03:00
}
Reference in New Issue Copy Permalink