[Feature Request]: Modern library for printer communication and print control

[deeprobin]

I have noticed that there is still a big flaw in printing in the .NET environment.

Even in an age of digitalization, printers are used extensively. In companies to print labels, delivery bills or labels, in the private environment to print documents, tax returns and many other applications.

Unfortunately, there is still no really good print library in the .NET environment. There is System.Drawing.Printing and the C++/CLI library in the WPF repository System.Printing.
Both are strictly limited to Windows, already very legacy and very limited.

The more companies move into the cloud, the more important it is to make the whole thing platform-independent.

My suggestion is to add an API that

• provides low level access to the printing protocols
  • IPP Naming suggestion: System.Printing.Ipp (the protocol which is used by CUPS)
  • SMB - Naming suggestion: System.Printing.Smb (if there are no licensing problems, because SMB is proprietary)
  • Native printers (Windows printing apis / installed printers) - System.Printing.Builtin
• An abstraction over these protocols / universal api: System.Printing

As you can easily see my suggestion is to recreate System.Printing even if this API already exists in WPF (I could well imagine that WPF would then use this API in the long run).

It would make sense to distribute this API as a Nuget package for this reason instead of including it in the BCL.

---

The whole thing here is just a rough wish. I have heard especially in the company where I work as well as from other companies that they really want something like this and therefore a real-world case is there.

Feel free to leave your feedback. Since this would be a larger project, if there is an interest on the part of Microsoft and the community, I would deal with it in detail and create API Proposals.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have noticed that there is still a big flaw in printing in the .NET environment.

Even in an age of digitalization, printers are used extensively. In companies to print labels, delivery bills or labels, in the private environment to print documents, tax returns and many other applications.

Unfortunately, there is still no really good print library in the .NET environment. There is System.Drawing.Printing and the C++/CLI library in the WPF repository System.Printing.
Both are strictly limited to Windows, already very legacy and very limited.

The more companies move into the cloud, the more important it is to make the whole thing platform-independent.

My suggestion is to add an API that

• provides low level access to the printing protocols
  • IPP Naming suggestion: System.Printing.Ipp (the protocol which is used by CUPS)
  • SMB - Naming suggestion: System.Printing.Smb (if there are no licensing problems, because SMB is proprietary)
  • Native printers (Windows printing apis / installed printers) - System.Printing.Builtin
• An abstraction over these protocols / universal api: System.Printing

As you can easily see my suggestion is to recreate System.Printing even if this API already exists in WPF (I could well imagine that WPF would then use this API in the long run).

It would make sense to distribute this API as a Nuget package for this reason instead of including it in the BCL.

---

The whole thing here is just a rough wish. I have heard especially in the company where I work as well as from other companies that they really want something like this and therefore a real-world case is there.

Feel free to leave your feedback. Since this would be a larger project, if there is an interest on the part of Microsoft and the community, I would deal with it in detail and create API Proposals.

Author:	deeprobin
Assignees:	-
Labels:	area-System.Runtime
Milestone:	-

Tagging subscribers to this area: @dotnet/area-system-drawing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have noticed that there is still a big flaw in printing in the .NET environment.

Even in an age of digitalization, printers are used extensively. In companies to print labels, delivery bills or labels, in the private environment to print documents, tax returns and many other applications.

Unfortunately, there is still no really good print library in the .NET environment. There is System.Drawing.Printing and the C++/CLI library in the WPF repository System.Printing.
Both are strictly limited to Windows, already very legacy and very limited.

The more companies move into the cloud, the more important it is to make the whole thing platform-independent.

My suggestion is to add an API that

• provides low level access to the printing protocols
  • IPP Naming suggestion: System.Printing.Ipp (the protocol which is used by CUPS)
  • SMB - Naming suggestion: System.Printing.Smb (if there are no licensing problems, because SMB is proprietary)
  • Native printers (Windows printing apis / installed printers) - System.Printing.Builtin
• An abstraction over these protocols / universal api: System.Printing

As you can easily see my suggestion is to recreate System.Printing even if this API already exists in WPF (I could well imagine that WPF would then use this API in the long run).

It would make sense to distribute this API as a Nuget package for this reason instead of including it in the BCL.

---

The whole thing here is just a rough wish. I have heard especially in the company where I work as well as from other companies that they really want something like this and therefore a real-world case is there.

Feel free to leave your feedback. Since this would be a larger project, if there is an interest on the part of Microsoft and the community, I would deal with it in detail and create API Proposals.

Author:	deeprobin
Assignees:	-
Labels:	area-System.Drawing, untriaged
Milestone:	-

[krwq]

@danmoseley this might fit better in dotnet/iot

[deeprobin]

@krwq What does printing have to do with IoT?

[krwq]

@deeprobin dotnet/iot is about hardware and printer is a physical device like any other. Printer doesn't really fit runtime repo in my eyes since most apps won't need it - APIs sounds super useful but it's a bit of its own beast. It seems like it would need either a separate package or be added to other repo. IMO from dotnet org dotnet/iot seems might fit best.

[deeprobin]

@krwq
Thanks for your clarification.

I assumed that dotnet/iot is only for IoT specific purposes like controlling small microcontrollers with interfaces like GPIO and not controlling printers which is mostly done over the network nowadays. For example, the IPP protocol¹ is an HTTP-based protocol that works over the network (and not over serial ports, for example).
As I see it, there are currently only APIs for some microcontrollers under dotnet/iot (see src/devices), so I don't see this project there.

I would also like to refer to the description in the README.md here:

.NET can be used to build applications for IoT devices and scenarios. IoT applications typically interact with sensors, displays and input devices that require the use of GPIO pins, serial ports or similar hardware.

Since, depending on the implementation, the Windows API² (using GDI or XPS) can be used instead of, say, IPP, I thought the dotnet/runtime repository would be a consideration.
One consideration would be to make the naming similar to IoT projects in System.Device. Like for example System.Device.Printers (by the way, I don't understand why "Device" is singular here), but the dotnet/iot repository seems wrong to me.

@richlander I saw you are active in dotnet/iot repository. I'd like to hear your thoughts on this.

However, we could also consider starting a separate repository for this. A repository like dotnet/printing.

I am also willing to support the printing project, but this will be a somewhat larger project (especially in the design of the API shape - the implementation is rather secondary) and I would definitely need support.

Footnotes

1. IPP 1.0

   • RFC 2565 - Internet Printing Protocol/1.0: Encoding and Transport
   • RFC 2566 - Internet Printing Protocol/1.0: Model and Semantics
   • RFC 2567 - Design Goals for an Internet Printing Protocol
   • RFC 2568 - Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol
   • RFC 2639 - Internet Printing Protocol/1.0: Implementor's Guide
   • RFC 2569 - Mapping between LPD and IPP Protocols

   IPP 1.1

   • RFC 2910 (obsolete) - Internet Printing Protocol/1.1: Encoding and Transport
   • RFC 2911 (obsolete) - Internet Printing Protocol/1.1: Model and Semantics
   • RFC 3196 - Internet Printing Protocol/1.1: Implementor's Guide
   • RFC 3510 - Internet Printing Protocol/1.1: IPP URL Scheme
   • RFC 7472 - Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme
   • RFC 8010 - Internet Printing Protocol/1.1: Encoding and Transport
   • RFC 8011 - Internet Printing Protocol/1.1: Model and Semantics

   IPP 2.0, 2.1 and 2.2

   • PWG 5100.10-2009
   • PWG 5100.12-2015
   ↩

2. Win32 APIs

   • Print Spooler API
   • Print Document Package API
   • Print Ticket API
   • GDI Print API
   • XPS Print API (depr.)
   ↩

[krwq]

@deeprobin it's true majority of the devices are I2C/SPI based but there are some exceptions, i.e. still picture or RFID/NFC devices - while device itself would maybe sometimes match criteria, reading data is way out of scope and is super complex but it would make device pointless without it. Then we have some other border-line devices i.e. NMEA 0183 - the device is serial port but protocol is essentially rather advanced parser or FT4222 which is a USB device which requires external driver but exposes GPIO/I2C/SPI so we added it for easier interop between that and other devices.

As for naming it predates me but System.Device.Gpio is only used for implementing generic purpose protocols and I think singular refers to specific protocol in use at a moment. Iot.Device.Bindings has plural form though and that's where devices live.

Regardless dotnet/iot seems like better match than dotnet/runtime even if it's not perfect and can be used as a stop (Iot.Device.Bindings specifically where making justified breaking changes is ok). If it grows too large we could potentially make this a separate nuget package.