This is a third, distinct issue found while debugging the Ricoh SP112 /
foo2ddst setup covered in #<issue_1> and #<issue_2>.
Observation
A 1-page document (confirmed as exactly 1 page via the source
application's print preview before sending) consistently shows
"Pages: 2" in the CUPS web UI job list (/jobs) when printed through
foo2ddst. Only one physical sheet is actually printed — this is purely
an accounting/display discrepancy in CUPS's job page count, not an
actual duplicate print.
Switching the same printer queue to an alternative PPD/filter
(https://github.com/vaginessa/ricoh-sp112-ppd, pstoricohddst-gdi) with
the same document does NOT reproduce this — it correctly shows
"Pages: 1".
Root cause
foo2ddst.c's start_page() function emits its own CUPS page-accounting
marker:
++pageno;
if (IsCUPS)
fprintf(stderr, "PAGE: %d %d\n", pageno, Copies);
However, the standard CUPS "pstops" filter — which runs earlier in the
filter chain, before foomatic-rip/foo2ddst-wrapper ever sees the data —
already emits this same "PAGE: n copies" marker once per real page, as
is standard practice across CUPS printer filters. foo2ddst emitting a
second, redundant marker per page causes CUPS to count each physical
page twice.
Fix that resolved it locally
Removed the redundant fprintf() call in start_page() (foo2ddst.c, near
line 560-562):
++pageno;
if (IsCUPS)
fprintf(stderr, "PAGE: %d %d\n", pageno, Copies);
After rebuilding without this line, single-page jobs correctly show
"Pages: 1" in the CUPS job list, with no change in actual printed
output (still exactly one sheet).
Suggested fix upstream
Remove the redundant PAGE: emission from foo2ddst.c's start_page(),
since page accounting is already handled by the upstream "pstops"
filter. This is likely low-impact/cosmetic (doesn't affect actual
printing) but does affect job accounting accuracy shown to users and
any tooling that relies on CUPS's reported page counts (e.g. usage
tracking, quota systems).
Happy to provide the full patch diff if useful.
This is a third, distinct issue found while debugging the Ricoh SP112 /
foo2ddst setup covered in #<issue_1> and #<issue_2>.
Observation
A 1-page document (confirmed as exactly 1 page via the source
application's print preview before sending) consistently shows
"Pages: 2" in the CUPS web UI job list (/jobs) when printed through
foo2ddst. Only one physical sheet is actually printed — this is purely
an accounting/display discrepancy in CUPS's job page count, not an
actual duplicate print.
Switching the same printer queue to an alternative PPD/filter
(https://github.com/vaginessa/ricoh-sp112-ppd, pstoricohddst-gdi) with
the same document does NOT reproduce this — it correctly shows
"Pages: 1".
Root cause
foo2ddst.c's start_page() function emits its own CUPS page-accounting
marker:
However, the standard CUPS "pstops" filter — which runs earlier in the
filter chain, before foomatic-rip/foo2ddst-wrapper ever sees the data —
already emits this same "PAGE: n copies" marker once per real page, as
is standard practice across CUPS printer filters. foo2ddst emitting a
second, redundant marker per page causes CUPS to count each physical
page twice.
Fix that resolved it locally
Removed the redundant fprintf() call in start_page() (foo2ddst.c, near
line 560-562):
After rebuilding without this line, single-page jobs correctly show
"Pages: 1" in the CUPS job list, with no change in actual printed
output (still exactly one sheet).
Suggested fix upstream
Remove the redundant PAGE: emission from foo2ddst.c's start_page(),
since page accounting is already handled by the upstream "pstops"
filter. This is likely low-impact/cosmetic (doesn't affect actual
printing) but does affect job accounting accuracy shown to users and
any tooling that relies on CUPS's reported page counts (e.g. usage
tracking, quota systems).
Happy to provide the full patch diff if useful.