* print: xps_driver says whether a Windows printer's driver renders XPS itself
craft_print::xps_driver(printer) reads PRINTER_DRIVER_XPS through winprint's new
PrinterDevice::is_xps_driver (storytold/winprint.rs#21): Some(true) for v4 drivers and v3
drivers with an XPS rendering filter, Some(false) for GDI drivers, None when it can't be read and
on other systems. On a GDI driver, reached through Windows' XPS-to-GDI conversion, a page with
transparency prints with halos, as black boxes or not at all (storytold/pdfcraft#6155, #5838,
#5940), so PdfCraft will flatten it for those drivers only.
The Windows end-to-end test checks the CI queue's "Generic / Text Only" driver reads as GDI.
* Test: the GDI-driver check in a helper (keeps the end-to-end test under the complexity limit)
* winprint bc06a7c48b768eb27a828c7986f6d2868b245ee0: storytold/winprint.rs main with #21 (PrinterDevice::is_xps_driver)
* craft-print: ask macOS for Auto Select when a job names no tray
CUPS gives a job that names no tray the PPD's default tray. On a queue
whose default tray is empty (a Xerox AltaLink defaulting to Tray 1), the
printer holds every job ("Tray 1 is empty") while CUPS reports it
completed, so nothing prints. Preview prints because the macOS Print
dialog's Paper Feed: Auto Select sends AP_D_InputSlot with an empty value,
which drops the PPD's default tray (storytold/pdfcraft#3752).
- lp_args sends `-o AP_D_InputSlot=` on macOS when the job's options name
no InputSlot. A tray the job names wins; checked with cupsfilter on a
synthetic PPD: with both, CUPS emits the InputSlot's code.
- apply_queue_defaults (now shared with apps that read options
themselves, such as PdfCraft) gives the driver's tray option an
AUTO_SELECT choice, labelled "Auto Select", first and as the default,
so a dialog shows what lp_args sends. It is left out when the user's
lpoptions defaults name another tray, since lp adds that tray to every
job and it wins.
Linux jobs are unchanged: AP_D_InputSlot is Apple's.
* craft-print: match queue defaults to the PPD without regard to case
CUPS treats PPD option and choice names as case-insensitive. A queue
default spelled otherwise than the PPD (inputslot=tray2 for InputSlot
Tray2) was ignored, so on macOS apply_queue_defaults showed Auto Select
although lp would send Tray2. Keys and choices now match case-
insensitively and keep the PPD's spelling. lpoptions -l prints the PPD's
spelling, so this matters for callers passing defaults from elsewhere.
Review: storytold/craft-libs#232 (CodeRabbit).
* README: keep both the macOS tray and the Flatpak notes (the merge left the conflict markers in)
---------
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
storytold/pdfcraft#5806: Print in grayscale was refused ("the printer's driver did not retain
the requested grayscale; nothing was sent") on drivers that list no grey option the ticket can
name: Microsoft Print to PDF lists only Color, and an HP Photosmart driver has only its own
ns0000:JobHPPrintInGrayScale.
- Job::grey_pages: the caller has already made the pages grey. Grayscale is still asked of the
driver, but a driver that has no grey option, or doesn't keep it, prints the job instead of
refusing it. Off (the default), such a driver is refused as before, since the pages would
come out in colour.
- The ticket asks for psk:Grayscale when the driver lists that and not psk:Monochrome
(grey_option); Windows dropped the Monochrome it didn't list and colour came back.
- Offered::grey records whether PageOutputColor has a grey option at all.
printers() ran `lpstat -l -p -d` and `lpstat -e` with no time limit. When the CUPS scheduler
stops answering (macOS cupsd stopped serving its local socket in storytold/pdfcraft#6761), both
block forever and the Print dialog looks for printers until the app is closed.
Both now run through output_within (the bounded wait pdfcraft's lpoptions read already uses):
the queues get 15 s, network discovery 10 s. A scheduler that doesn't answer gives an empty list
and a warning naming cupsd; discovery that hangs only loses the driverless printers.
winprint.rs#19 draws each page at the resolution the job's ticket asks for instead of ~96 dpi
(storytold/pdfcraft#4941, #2676). #12 writes QName property values as prefix:local, which
drivers such as the Microsoft IPP Class Driver otherwise reject when merging the ticket
(storytold/pdfcraft#3823). #3 accepts whitespace around xsd:integer values in
PrintCapabilities (Toshiba Universal Printer 2, storytold/pdfcraft#2430).
The public API craft-print uses is unchanged; only the rev and the lockfile move.
printer_queues() (#618) lists the queues without asking any driver, so
every printer's two_sided is unknown there. A Print dialog listing from it
still needs to know whether the printer the user picks takes two-sided
settings, without asking every other driver as printers() does: Windows
takes about 48 s to give up on a printer it can't reach, such as a WSD
printer on another network (storytold/pdfcraft#2192).
two_sided(printer) finds that queue and reads its driver's capabilities
with the same check printers() makes, so the answers match. It is None
when there is no such queue, when the capabilities can't be read, and off
Windows, as printers() reports there.
The paused-printer test now checks that two_sided(name) gives printers()'s
answer for the test queue from exactly one driver query, and a new test
checks that a name no queue has is unknown. The query counting moves into
a small helper, which keeps windows_jobs_reach_the_spooler under the
cognitive-complexity limit.
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
Windows.Data.Pdf draws a page on several of its own worker threads, which
share the print control's device context. With winprint 5f80b9b's
single-threaded factory Direct2D takes no locks, so those threads race in
d2d1.dll and the app closes while printing, most often on pages with Type 3
fonts (storytold/pdfcraft#5006, storytold/pdfcraft#2684).
storytold/winprint.rs#11 made the factory multi-threaded; it was merged as
64e7afd4.
craft-winprint-gdi moves to the same revision, so one checkout of
winprint.rs serves both; crates/gdi is unchanged between 417ac3c and
64e7afd4.
Co-authored-by: mertan-wq <235487900+mertan-wq@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* craft-print: a job can be cancelled until it starts reaching the spooler
On Windows a job asks the printer's driver for its capabilities before
anything is sent. A networked printer in power save can hold that query
for a long time, and an app had no way to give up on the job without
risking it printing later (storytold/wordcraft#5710; CodeRabbit on
storytold/wordcraft#5732).
A Cancel token, passed to the new submit_cancellable, moves a job from
pending to cancelled or to sending. The job checks it at the last point
before anything reaches the spooler: on Windows after the driver has
answered, before the job file is written; on macOS and Linux before lp
starts. A cancelled job returns an error and is never sent; a job already
being sent completes. submit and submit_with_progress are unchanged, and
Error keeps its one variant so callers that match on it still compile.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* craft-print: a job turns to sending with the provider held; the job file waits for it
Review: marked as sending before it took the PrintTicket provider, a job
could then wait behind another job's driver call that a sleeping printer
held, and an app that waits only for jobs being sent would wait on it.
The job now turns to sending only once it holds the provider, right
before printing, and writes its file only after that, so a cancelled job
leaves no copy of the document behind.
A test-only hold in the driver call lets the Windows spooler test cancel
a job while its driver doesn't answer: the cancel wins and, once the
driver answers, the job stops instead of reaching the paused queue.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* craft-print: the DEVMODE conversion comes before a job turns to sending
CodeRabbit on #622: winprint converts the ticket to a DEVMODE, a driver
call a sleeping printer can stall, before it creates the native job, so
a job stalled there had already turned to sending and couldn't be
cancelled. The conversion now runs first, with the provider held, while
the job can still be cancelled; the provider stays held until the first
copy's own conversion, so no other job comes between them.
Tests: the Windows spooler test also cancels a job held in that
conversion; the CUPS test gives a spooler that can't start, so any
attempt to start it would change the error. README: cancellation in the
progress section.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* craft-print: clarify cancellation during winprint conversion repeat
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The live spooler test only checked that printer_queues() reports
two_sided as unknown, which would still pass if it called printers() and
cleared the field (CodeRabbit on #618). A test-only per-thread counter in
two_sided(), the one PrintCapabilities query printer discovery makes,
now shows printers() querying the test queue's driver (the control) and
printer_queues() querying none.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On Windows, printers() reads each driver's PrintCapabilities to report
two-sided support before it returns. A networked printer in power save
can hold that query for a long time, so a Print dialog showed no printer
at all, not even the ones that were awake (storytold/wordcraft#5710,
storytold/wordcraft#5645, storytold/wordcraft#5413).
printer_queues() returns the same queues and default from EnumPrinters
and GetDefaultPrinter with two_sided unknown, and makes no driver call.
Submission still checks the job's options with the driver. On other
platforms it is printers(). printers() is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Windows.Data.Pdf draws a page on several of its own worker threads, which
share the print control's device context. With winprint 5f80b9b's
single-threaded factory Direct2D takes no locks, so those threads race in
d2d1.dll and the app closes while printing, most often on pages with Type 3
fonts (storytold/pdfcraft#5006, storytold/pdfcraft#2684).
storytold/winprint.rs#11 made the factory multi-threaded; it was merged as
64e7afd4.
craft-winprint-gdi moves to the same revision, so one checkout of
winprint.rs serves both; crates/gdi is unchanged between 417ac3c and
64e7afd4.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* print: charge skipped whitespace and comments to the lexer's token budget
Lexer::skip_ws scanned whitespace and comments without charging them,
so an annotation object behind a long comment was rescanned in full for
every reference to it, outside the per-object and job-wide budgets. The
skipped bytes now count like tokens, and the scan stops at the budget.
* address review: fail objstm load when header lexer exhausts, restore token charge on failed reference lookahead
* address review: charge objstm header lexer tokens to the job budget
The first time a process opens a PrintTicket provider for a queue whose
provider is PrintConfig.dll, winspool.drv creates a process-wide cache
without a lock. When two threads make those first calls together,
winspool can keep a pointer to a cache it has already freed, and a later
PTOpenProvider call crashes the process with an access violation in
ntdll. Listing printers from several threads at once reaches it through
two_sided.
Hold one process-wide lock around every call that reaches the provider:
PrintCapabilities::fetch in two_sided and driver_ticket, the
PrintTicketBuilder in driver_ticket, fetch_xml_for_ticket in
imageable_margin, and the start of print_with_progress, where winprint
converts the ticket to a DEVMODE. The job releases the lock at its first
progress report, before it sends progress to the submitting thread. A
lock poisoned by a panic is still taken.
* craft-print: log why the printer list is empty when lpstat can't run; document Flatpak needs
Flatpak apps saw "No printers found" with working CUPS printers: the Freedesktop
runtime has libcups but not lpstat/lp, and the sandbox had neither the CUPS socket
nor Avahi (driverless printers come from lpstat -e). Log the spawn failure and say
in the README what a Flatpak must bundle and grant.
* craft-print: log a failed lpstat -p -d; README separates what each Flatpak piece is for
Review (CodeRabbit): a non-zero lpstat exit was dropped silently, and the README
said any missing piece empties the printer list when only lpstat and the socket do.
* craft-print README: driver options need the PPD, remote servers need network, socket paths are remapped
Review (CodeRabbit): printer_options reads /etc/cups/ppd before lpoptions, so it is
the PPD, not lpoptions, that a Flatpak lacks; a client.conf server is reached only
with --share=network.
* craft-print README: scope the CUPS_SERVER override to one app; describe the stricter socket wrapper
Review (CodeRabbit): flatpak override without an app id applies to every app.
Review follow-up. The test asserted `respell(validated, driver_default) == None`.
respell also returns None when it refuses a ticket, and in_drivers_spelling then
keeps the ticket as it is, so a ticket still spelled `ns0000` passed.
The test now compares the vendor namespace declarations of the ticket driver_ticket
returns with those of the driver's own default ticket and fails when a namespace the
driver declares is under another prefix. The comparison is
`ticket::prefixes_unlike_the_drivers` (test-only), unit-tested here: it flags the ticket
as the merge returns it, passes the respelled one and the driver's own, and flags a
ticket respell refused, where `respell(..) == None` can't tell it from a correct one.
Checked against a Brother HL-L2390DW: the test passes, and fails with
`(brother namespace, "ns0000", "brpsk")` when in_drivers_spelling is made to return
the merged ticket.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FQ5PzHVUcntEHU97zniM5U
Review follow-up. When two vendor namespaces trade prefixes, both prefixes stay
declared, so a name written with one of them as an element or attribute name
(`<ns0000:Feature/>`, `ns0000:flag="1"`) still parsed and resolved after the
root declarations changed, but to the other namespace. respell only rewrites
`name`/`constrained` values and QName values, so such a name would not follow.
respell now returns None when any element or attribute is named in a namespace
whose prefix changes. Names in a namespace that keeps its prefix do not block
the respelling, and the real Brother tickets (vendor names only in `name`
attributes and QName values) are respelled as before.
Tests: regression cases for element and attribute names in a swap and in a
prefix chain, and a control for names in an untouched namespace. Each ticket
is asserted well-formed with every prefix resolving, so the case is refused
for the name, not for a parse failure. The refusal tests fail with the guard
disabled.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FQ5PzHVUcntEHU97zniM5U
Review of #307:
- respell rewrites the root's namespace declarations, so an element below the
root that declares either prefix of a rename again (ns0000 or brpsk) would make
a name resolve to another namespace once the prefixes change. It now returns
None for such a ticket, and a test covers both prefixes.
- The vendor-element test replaced only an opening tag, left the closing tag
behind and so never parsed: it passed because respell refused the broken XML,
not because of what it was meant to check. Every refusal fixture is now
asserted well-formed, and the element is replaced whole. Doing so showed the
element guard was redundant: an element or attribute name in a renamed
namespace leaves an undeclared prefix, which the final parse of the result
already refuses. The guard is removed and the test now exercises that check.
- Doc comments on the new constants and tests.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FQ5PzHVUcntEHU97znim5u
Windows' PTMergeAndValidatePrintTicket names a vendor namespace with a generated
prefix (ns0000) as soon as the merged ticket uses a name from it. driver_ticket
merges the driver's own paper option from its capabilities, which carries vendor
properties, so a Brother HL-L2390DW's ticket came back with ns0000 where the
driver's own default ticket says brpsk. XML-wise the two are the same; the
driver's print pipeline reads the prefix as text. The job was accepted and then
ID2D1PrintControl::AddPage (or Close, in older builds) failed with 0x80040003,
reported by winprint as "Render error" / "Failed to close print control: No such
interface supported".
The same ticket sent raw with brpsk prints; with only the prefix changed to
ns0000 it fails the same way, so the prefix is the whole difference.
driver_ticket now re-spells the validated ticket with the prefixes of the driver's
own default ticket (an empty ticket, validated), through ticket::respell: pure
XML, tested on every platform, and a no-op unless a vendor namespace is spelled
differently. It rewrites only the root declarations and the vendor names in name
/ constrained attributes and QName values, handles two namespaces trading
prefixes, and leaves the ticket as it is when a rename could be ambiguous or leave
a prefix undeclared.
Verified on a Brother HL-L2390DW: the job spools, and pdfcraft head's doc_print
that failed at AddPage prints.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FQ5PzHVUcntEHU97znim5u
The driver's PrintCapabilities tell a driver that dropped a requested value
from one that never had the feature. Grayscale on a driver with no colour
option and uncollated copies on one that can't collate are accepted, like
one-sided on a queue without duplex. Collated copies on a driver that can't
collate are refused with their own message. The capabilities are read only
when the strict check fails.
- craft-ui shown_names resolves label collisions with hash-map counts and a worklist, so a
crafted cascade is linear instead of cubic (CodeRabbit CWE-407, ui/src/printing.rs:32)
- parse_ppd caps group, option and choice labels at 256 characters before each option copies
its group (CodeRabbit CWE-400, print/src/lib.rs:232)
- printers_parsed tracks seen destinations in a HashSet (CodeRabbit CWE-407, lib.rs:417)
- sheets::Reader::rect checks an inline array's length before reading it and borrows direct
objects instead of deep-cloning the inherited MediaBox/CropBox/Rotate for every page
(CodeRabbit CWE-400, print/src/sheets.rs:774)
* print, ui: a printer is shown by its name, not its CUPS queue name
CUPS queue names can't hold dots or spaces, so macOS adds the printer at
192.0.2.15 as the queue `_192_0_2_15`, and the Print dialog showed that
underscored name. The name the user knows is the queue's description
(CUPS `printer-info`).
craft-print now lists queues with `lpstat -l -p -d` (same lines, plus
each queue's indented details) and keeps the first `Description:` as
`Printer::description`, capped at 256 characters. Windows names are
already human, so they leave it empty.
craft-ui's `Printer` gains `label`; the dialog shows it, or the name when
it's empty, and `shown_names` adds the queue name in brackets when two
printers would show the same text. Selection and jobs still use `name`.
Both structs gain a field, so apps that build them by hand add it
(`..Default::default()` works for craft-ui's) when they update the pin.
* print, ui: an empty first description stays first, and shown names never collide
parse_lpstat tracks whether a queue has had its Description line, so an
empty first one isn't replaced by a later one. shown_names checks the
final texts: printers whose bracketed text another label already reads
show their queue names instead.
The Windows job ticket always named a colour: Monochrome when the job
asked for grayscale, Color otherwise. Merged over the user's printing
preferences, that Color replaced a black and white the user had picked
in the driver's own Properties dialog, so the job came out in colour
(storytold/pdfcraft#2422).
The ticket now names a colour only when grayscale is asked for. Without
it the driver validates the ticket from the user's preferences, as the
CUPS backend and `verify_job_options` already assumed.
Checked on an HP OfficeJet 250 (PCL-3 driver) with its preferences set
to black and white: the validated ticket had psk:Color and the DEVMODE
dmColor 2 before, psk:Monochrome and dmColor 1 after. With colour
preferences it is psk:Color either way.
- `the_ticket_carries_the_job_options`: no PageOutputColor without
grayscale (fails on the old ticket).
- `the_preferences_colour_reaches_a_job_without_grayscale` (ignored,
needs CRAFT_PRINT_TEST_PRINTER; sends no job): the job's validated
colour equals the preferences' colour. Fails on the old ticket with the
queue set to black and white; passes on HP OfficeJet 250, Microsoft
Print to PDF and OneNote.
- The Windows command preview says `color=(driver default)`, like
`duplex=(queue default)`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Windows path refused any explicit duplex request whose validated PrintTicket lacked the duplex feature. The Print dialog asks for one-sided by default, so every queue without a duplex unit refused with default settings, although one-sided is all such a queue can do and nothing was dropped.
A one-sided request is now satisfied when the driver's PrintCapabilities offer no duplex feature at all. Two-sided requests without the feature, a driver that offers the feature but returns a ticket without the setting, and capabilities that cannot be read are still refused. Copies, collation, colour, paper, orientation and scaling are checked as before.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
FredApps
Juan JuradoandFredApps
art804andFredApps
robertobulltechandrobertobulltech
Zhihui Song
ashandClaude Opus 5.5
Dylan M. Taylor
.CooCoo
aiongg
aiongg
skylar taylor-barrick
Bishal De
magdale76andClaude Opus 5.5
Justin CapellaandClaude Sonnet 5.5
