EpsonTest predates the adapter layer: PrintCommandsToEpsonPrinterAsync
takes an EpsonPrinter and drives it directly, so PrinterWrapperFactory,
the model adapters and the 0x20 dispatch were never exercised. Against a
POS895 that path feeds with ESC d, which the firmware ignores, so every
cut slices through the last printed line, and it never sends a logo at
all - the only logo branch is the HTML one, which uses GS ( L, the
command that prints nothing on this hardware.
PrintCommandsViaAdapterAsync instead does what EpsonPrintService does for
a real job: query GS I 1, let PrinterWrapperFactory choose the adapter
from the reported byte, then print the logo and commands through it and
cut. It logs the reported id and the chosen adapter, so a wrong or
missing model byte is visible rather than silent.
Menu gains a third target and the non-interactive form accepts "pos895",
so `dotnet run -- final pos895` prints a Final receipt with its logo
through the production path. That covers the one part of the POS895 work
nothing had executed end to end: the ESC * bit-image logo.
Note EpsonTest must be run from its own directory; the logo paths are
relative and `dotnet run --project` from the repo root cannot resolve
them. That predates this change.
Claude-Session: https://claude.ai/code/session_01E6N3P4nSZLtp4BC2LXVref
Use fully-qualified KitchenReceipt namespace for Gang, Dish, and
DishModifications in BuildSampleKitchenReceipt and
BuildSampleKitchenReceiptNextDish to resolve CS0104 errors caused by
identical type names in BarReceipt and KitchenReceipt namespaces.
Add global.json to pin SDK to .NET 8.0 for compatibility with .slnx.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Replace commented-out code blocks with arrow-key navigation menu.
First menu selects receipt type (Kitchen/Final/Invoice/Bar/OrderItems),
second selects printer target (HTML or Epson hardware).
Co-Authored-By: Paperclip <noreply@paperclip.ing>
