Fix font glyph path

[BobLd]

This replaces #742

Sorry for the long PR. Many file modified are just tidy up.

Regarding how font matrices are actually supposed to work, this is not clear as per the documenation. have a look here if you want to see some discussion:

• FontMatrix of CFF fonts veraPDF/veraPDF-library#1010
• https://bugs.ghostscript.com/show_bug.cgi?id=690724

All my changes are backed by visual tests (for both glyph paths and bounding boxes)

Added test documents either come from:

• FontMatrix of CFF fonts veraPDF/veraPDF-library#1010
• https://pdfa.org/stressful-pdf-corpus/

[BobLd]

@EliotJones I've pushed a commit to fix a compilation warning.

Regarding your point about sealed classes, the only 2 public ones I sealed I could find are CompactFontFormatFontCollection and GlyphList, let me know if you want me to unseal them (I'm not sure how could people derive and use classes based on those, but I really could be wrong)

[EliotJones]

just a couple of places becoming sealed that would change the public API, otherwise LGTM even though I'm still not 100% on what's happening but if the tests look good then it should be right

[EliotJones]

Out of interest what is happening here?

[BobLd]

This is tested in RepresentativeWindEnergyDeals() in the GenerateLetterGlyphImages. Document is GHOSTSCRIPT-698168-0.pdf. You can try to open it in Acrobat reader (supports ICC) and Firefox/pdf.js (does not support ICC) and you will see the difference.

In this particular test, the color space is ICC, but we don't support it. So we use the Alternate CC. The input values are not within the RGB range (which is the alternate CC).

In the case of ICC, the Alternate CC is defined as (I've put in bold the part that justifies this change):

(Optional) An alternate colour space that shall be used in case the one specified in the stream data is not supported. PDF readers should not use this colour space. The alternate space may be any valid colour space (except a Pattern colour space) that has the number of components specified by N. If this entry is omitted and the PDF reader does not understand the ICC profile data, the colour space that shall be used is DeviceGray, DeviceRGB, or DeviceCMYK, depending on whether the value of N is 1, 3, or 4, respectively. There shall not be conversion of source colour values, such as a tint transformation, when using the alternate colour space. Colour values within the range of the ICCBased colour space might not be within the range of the alternate colour space. In this case and after constraining to the ICCBased range, the nearest values within the range of the alternate space shall be substituted without error indication.

Do let me know if you understand that in a different way.

[BobLd]

I think this is how they do in PdfBox, where they clamp values too.

https://github.com/apache/pdfbox/blob/33ebd39096a650df157a846d9e8c631a1e3631ab/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDICCBased.java#L291C13-L291C75

Again, happy for you to tell me if you understand that differently

[BobLd]

I agree with you, this is not exactly clear what happens. And reading the discussions in the links I've put, it seems we are not the only ones. I tried to document the code to reflect that