Neofarma KB

c6000au

Leitura de 3 min

Faz sentido. Como a MP4200 é ESC/POS direto (raw socket/serial), ela bypassa o driver Windows completamente. O C6000AU é o oposto — precisa do driver Windows como intermediário porque o driver é quem traduz “papel 85x40, rolo contínuo” em comandos que a impressora entende para cortar.

O que o Adobe está fazendo por baixo:

Quando você seleciona um preset no Adobe, ele está setando três coisas no DEVMODE do print job: (1) um Windows Form (paper size registrado) com as dimensões, (2) o media source como “Roll Paper” (contínuo), e (3) a orientação. Seu service precisa replicar exatamente isso.

Abordagem recomendada:

O caminho mais limpo do Node no Windows é PowerShell via child_process. A lógica fica assim:

  1. Node lê o PDF — pdf-lib extrai o MediaBox, converte de pontos para mmm (÷ 2.835), pega a altura
  2. Node decide o preset — snap para o menor preset ≥ altura ([25, 30, 40, 45].find(h => h >= alturaMm)) ou, se preferir exato, usa a altura do PDF
  3. Node chama PowerShell — que usa .NET System.Drawing.Printing para imprimir com PaperSize customizado e media source de rolo contínuo

O ponto crítico é o media source. O driver da Epson expõe “Roll Paper” como um dos PaperSource.Kind disponíveis. No PowerShell/.NET você itera os PrinterSettings.PaperSources e seleciona o que corresponde a rolo contínuo — é o equivalente programático de você selecionando “rolo contínuo” no Adobe.

Sobre preset vs. exato: usar a altura exata do PDF requer criar um Windows Form dinâmico (Add-PrinterPort/Add-PrinterForm) ou setar o PaperSize customizado diretamente no .NET sem registrar no sistema. A segunda opção é mais limpa — o .NET aceita new PaperSize("Custom", width, height) em centésimos de polegada sem precisar registrar nada.

Arquitetura do fluxo:

PDF salvo → File watcher (ou API call) no Node
  → pdf-lib extrai altura
  → calcula dimensões em centésimos de polegada
  → spawn PowerShell com script que:
      - abre o PDF via .NET PrintDocument
      - seta PaperSize(85mm, altura)
      - seta PaperSource = Roll Paper
      - envia para "Epson C6000AU"

Duas decisões pra você tomar antes de implementar:

  1. Trigger: file watcher no diretório de saída dos PDFs, ou o sistema que gera o rótulo chama uma API no seu service?

  2. Renderização do PDF no .NET: PrintDocument do .NET não renderiza PDF nativamente. Você precisa de um renderizador — PdfiumViewer (wrapper do Pdfium, gratuito, NuGet) é o padrão. Alternativamente, o Ghostscript via CLI renderiza e imprime, e aceita paper size customizado via flags (-dDEVICEWIDTHPOINTS, -dDEVICEHEIGHTPOINTS). Ghostscript pode ser mais simples porque elimina o .NET inteiro — fica Node → GS CLI direto.

Qual caminho te parece mais alinhado com o que já tem rodando?

Visão de gráfico