[Draft] Add two PoC testcases to libcupsfilters test suite (text→PDF and malformed PDF)

[shreyanshtiwari4]

Summary

This draft PR adds two small Proof-of-Concept testcases to cupsfilters/test-filter-cases.txt, along with their corresponding input files in cupsfilters/test_files/.

The purpose of this PoC is to better understand how the libcupsfilters test harness (testfilters) behaves for simple input→output scenarios, and to explore how we can later expand automated CI coverage using such testcases.

This PR is not intended for merging yet — it is meant for discussion, feedback, and refinement of directions for future test additions.

---

Added Testcases

1. text/plain → application/pdf (Positive Test)

Entry added to test-filter-cases.txt:

cupsfilters/test_files/test_text_simple.txt	text/plain	cupsfilters/test_files/output_files/output_text_simple.pdf	application/pdf	Generic	PDF Color 2	1	1	text/plain,application/pdf	201	poc-user	poc-print	1

Local Behavior (PoC-Only Test Run)

Ran:

./testfilters cupsfilters/test-filter-cases-poc.txt 2 2

From the log:

• Converting from text/plain to application/pdf
• Adding texttopdf to chain
• texttopdf completed with status 0
• Test Status 1: Successful

The output file "cupsfilters/test_files/output_files/output_text_simple.pdf" was created successfully (~1125 bytes) and appears as a valid PDF.

Conclusion:
This PoC correctly exercises the texttopdf filter and demonstrates that the test harness handles simple text→PDF transforms reliably.

2. malformed PDF → application/pdf (Exploratory “Negative” Test)

Entry added to test-filter-cases.txt:

cupsfilters/test_files/malformed.pdf	application/pdf cupsfilters/test_files/output_files/output_malformed_should_fail.pdf	application/pdf	Generic	PDF Color 2	1	1	application/pdf	202	poc-user-malformed	expect-fail	1

malformed.pdf is a deliberately invalid “PDF” consisting of:

NotAPDF
%EOF

Local behavior (same PoC-only run as above)

From the log:

• Converting from application/pdf to application/pdf
• No filter at all in chain, passing through the data
• Test Status 2: Successful

The output file "cupsfilters/test_files/output_files/output_malformed_should_fail.pdf" was created with size 26 bytes, i.e. essentially a direct copy of the malformed input.(although I was expecting a Ghostscript failure)

From observation I think the reason this happens:

• For application/pdf → application/pdf, the universal filter detects that no transformation is needed and selects no filter chain.
• As a result, the malformed PDF never reaches Ghostscript and therefore does not produce errors such as:
  • “Missing Root object”
  • “Unable to find start of cross-reference table”
  • “Unexpected page count”

Conclusion:
This PoC demonstrates the current behavior: malformed-PDF handling only triggers Ghostscript failures when the test requests a transformation such as PDF→PWG or PDF→PCLm.

[tillkamppeter]

Note that we do not actually do application/pdf → application/pdf, but instead application/pdf → application/vnd.cups-pdf which resolves to a call of pdftopdf. pdftopdf, independent whether the old QPDF-based one ot the new PDFio-based one shhould error out. Both PDF manipulation libraries should error on invalid PDF.

[shreyanshtiwari4]

I had initially used application/pdf → application/pdf, which explains why the malformed test was just a pass-through.
I’ll update the testcase to use application/vnd.cups-pdf as the output MIME so that pdftopdf is part of the chain, and then re-test the behavior of the malformed PDF. If pdftopdf doesn’t error out on this invalid input, that might be a good candidate for a small regression test.