Hello, my name is Hideki Honda and I am a point of contact of Canon for various IT vendors. I am contacting with you because you announced that you are going to deprecate opvp devices in https://www.ghostscript.com/doc/9.53.3/News.htm Canon has 2 printer drivers that depends on opvp devices: * Canon Linux LIPS4 printer driver This driver is downloaded by 150 times per month in average. More than 170 models use this driver. In Japanese market, many hospitals uses this driver for their payment systems. * Canon Linux CAPT printer driver This driver is downloaded by 4800 times per month in average. Canon’s low-end printers uses this driver and they are sold 300,000 per year. So Canon would like to ask you to cancel the deprecation plan of opvp devices.
We did reverse that decision a couple of months ago, after another developer contacted us: https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c6ce09aa5c9e I have some changes to the opvp/oprp devices in the pipeline (when I get the time!), the purpose of which is to remove the many global variables in their sources. When I get those changes done, would you be willing/able to run some basic tests to make sure I haven't inadvertently broken anything?
Thank you for your quick response. We are very glad to hear that opvp will not be deprecated! Actually we were aware of your code changes in https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c6ce09aa5c9e, but the changes are not applied in v9.53.3. That is why we contacted with you. One thing to confirm: You will remove the deprecation announcement in next release, right? As you might know, Fedora33 uses GS v9.53.3. Since it is difficult for customers to downgrade to GSv9.52, we are telling our customers that they should get the latest source code of GS and overwrite it by themselves. It would be great if you would release GS based on the latest source code so that we could provide better experience to our customers. Lastly, yes we would love to run basic tests. Please let us know when it is ready.
The device sources were never removed, the devices were "just" left out of the default builds, so it's a fairly easy task to reintroduce the devices. If you contact the Fedora Ghostscript package maintainer with a request to reinstate the devices, they should be able to roll it out as a trivial update. Point them here, and I can work with them to make that happen.
As far as we know, Fedora maybe the only Linux distributer that includes GS v9.53.3. However, other distributer also might include GS v9.53.3 in the near future. Since it is impossible for us to handle all distributers, it might result in poor user experience where user cannot print. If the latest GS would support opvp again, it would address the above concern! It would also be much easier if we could say “Please use the latest GS” when user might have trouble of cannot printing. So please re-consider releasing GS with opvp support.
(In reply to Chris Liddell (chrisl) from comment #3) > The device sources were never removed, the devices were "just" left out of > the default builds, so it's a fairly easy task to reintroduce the devices. > > If you contact the Fedora Ghostscript package maintainer with a request to > reinstate the devices, they should be able to roll it out as a trivial > update. Point them here, and I can work with them to make that happen. Fedora has resolved this issue. Please refer https://bugzilla.redhat.com/show_bug.cgi?id=1899885 https://bugzilla.redhat.com/show_bug.cgi?id=1909950
In an effort to remove global variable from the devices that ship with ghostscript, changes were made to the opvp/oprp device to place its globals into the gs device structure. This required a fair amount of changes to the device code. In addition, mismatches between some of the client API prototypes and function calls were fixed. The commit with the changes is here https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8b47f269b83b172b22606806fe5ec272d974e797 To ensure there are no problems with the next release for the opvp device, I would like to see if any parties who make use of this device would do testing with the updated version. We did some rudimentary testing with a simple harness that we included, but it would be better if we had some feedback from users of the device. One area that could use some testing, is the interface between the 0.2 and 1.0 API calls.
No response, so closing.