Trong khi cố gắng gửi tệp văn bản đến máy in lprtừ xterm, nội dung bị hỏng ngoài khả năng nhận biết, nguyên nhân cuối cùng được truy nguyên từ mã hóa của tệp. Thay vào đó, nếu tôi xử lý văn bản bằng iconv(ví dụ iconv -f utf-8 -t ascii//TRANSLIT:), thì tệp được in bình thường. Một đề nghị khác mà tôi đã gặp là thiết lập định dạng tài liệu (ví dụ lpr -o document-format=text/utf8:), nhưng điều này trả về lỗi lpr: Unsupported document-format "text/utf8". Tôi có thể luôn luôn bí danh lprlệnh để bao gồm chế biến bằng iconv, nhưng là có một cách tổng quát hơn để hỗ trợ bản địa utf-8 trong CUPS/ lprhệ thống?
Chỉnh sửa: Hệ điều hành của tôi là Debian 8 và trình quản lý cửa sổ của tôi là openbox(không có môi trường máy tính để bàn). Tôi có thể in tệp này mà không gặp sự cố nào từ MacOS X cũng như từ hệ thống Debian7 / Gnome3.
Từ hệ thống hiện tại của tôi, tôi nên chỉ ra rằng ngay cả sau khi thay đổi mã hóa ký tự từ UTF-8 sang ASCII, các ký tự dòng mới không được tôn trọng lpr, do đó các dòng được nối với nhau và được in cho đến khi đạt được lề giấy. Sau khi mã hóa và chuyển ngữ bằng iconvMacOS X, việc in vẫn hoạt động bình thường (do đó, vấn đề về dòng mới cũng dành riêng cho hệ thống hiện tại của tôi).
a2psbộ lọc. Tôi đã không nhận thức được nó. Máy in trong câu hỏi là một máy in laser quét HP4650. Làm thế nào người ta có thể xác định mã hóa được sử dụng bởi CUPS? Các ký tự thực sự được in, không liên quan rõ ràng đến đầu vào, bao gồm một gamma vốn của Hy Lạp, thủ đô C với một cây tuyết tùng, một o với một dấu mũ, và một chữ viết hoa W và T. Ngoài ra, việc không tôn trọng kết quả của các ký tự dòng mới cắt ngắn đầu ra ở lề giấy.
lpr -o document-format='text/plain;charset=utf-8'sẽ đủ để in như bạn muốn, nhưng điều này không thay đổi mặc định cài đặt CUPS của bạn có vẻ lỗi thời.
a2pschưa Mã hóa nào thực sự được sử dụng trên đầu ra, khi bạn thử utf-8? (Tôi đoán là vậyiso-8859-1)