It's taken some time for me to nail down what is happening here, but here are the basics:
Client: WinPrint Hylafax on Windows 10
Server (send only): Hylafax+ 7.0.1 running with Asterisk 13.13 and iaxmodem 1.3.0
Nothing has changed in the setup of the server or the clients. Within the last couple weeks I have gotten many reports that some recipients of our faxes have only gotten black pages. Once I was able to nail down an exact example and have them fax it back to me, I saw that it truly was a completely black page. The only thing not black was the TSI header at the top of the page. I checked the log files and tracked down the file for this particular fax job, located the document file on the server, downloaded it to my workstation, and was surprised to find that it is 3 pages of black. That means the GhostScript process on the server encoded the file from the client program into a completely black page. The WinPrint Hylafax program has been uninstalled and reinstalled with no change. Where do I go to figure out and fix this issue? It isn't with every fax job, but a large enough number that it's becoming a problem.
I will attach the send log file for this transmission.
Here is the TiffInfo for the document on the server:
Either WinPrint HylaFAX is submitting a black document or Ghostscript is converting the document that WinPrint HylaFAX is submitting into an all black page. You'll need to look at the original file submitted by the client (Postscript, PDF, PCL, or TIFF) from the docq directory (in the example you showed it would have been docq/doc88814.ps) and look at it. Assuming it looks fine in another viewer (which would seem to make WinPrint innocent) then you'd need to step through the Ghostscript conversion process to see what it's doing wrong. You can get the Ghostscript commands by setting ServerTracing to 0xFFF in /var/spool/hylafax/etc/config and then restarting faxq. Then the syslog will show "FaxQueuer" entries that include the conversion syntax.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the response, Lee. Based on your input letting me know which file is the one submitted from WinPrint Hylafax, I was able to see that the client is submitting a completely black page. I checked the support page, and we were running a slightly older version, so I updated the client on the machine that is experiencing this the most, but it didn't change. I discovered that the person at this PC is using ScandallPro to scan documents and send them through Hylafax. I'm going to do some testing to see if there is some incompatibility between ScandallPro and WinPrint Hylafax that might be causing this. I'll update when I find something.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's taken some time for me to nail down what is happening here, but here are the basics:
Client: WinPrint Hylafax on Windows 10
Server (send only): Hylafax+ 7.0.1 running with Asterisk 13.13 and iaxmodem 1.3.0
Nothing has changed in the setup of the server or the clients. Within the last couple weeks I have gotten many reports that some recipients of our faxes have only gotten black pages. Once I was able to nail down an exact example and have them fax it back to me, I saw that it truly was a completely black page. The only thing not black was the TSI header at the top of the page. I checked the log files and tracked down the file for this particular fax job, located the document file on the server, downloaded it to my workstation, and was surprised to find that it is 3 pages of black. That means the GhostScript process on the server encoded the file from the client program into a completely black page. The WinPrint Hylafax program has been uninstalled and reinstalled with no change. Where do I go to figure out and fix this issue? It isn't with every fax job, but a large enough number that it's becoming a problem.
I will attach the send log file for this transmission.
Here is the TiffInfo for the document on the server:
[log]# tiffinfo ../docq/doc88814.ps\;1de1
TIFF Directory at offset 0x8 (8)
Subfile Type: multi-page document (2 = 0x2)
Image Width: 1728 Image Length: 2156
Resolution: 203, 196 pixels/inch
Bits/Sample: 1
Compression Scheme: CCITT Group 4
Photometric Interpretation: min-is-white
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 2156
Planar Configuration: single image plane
Page Number: 0-0
Software: GPL Ghostscript 8.70
DateTime: 2021:04:27 13:12:37
Group 4 Options: (0 = 0x0)
TIFF Directory at offset 0x472 (1138)
Subfile Type: multi-page document (2 = 0x2)
Image Width: 1728 Image Length: 2156
Resolution: 203, 196 pixels/inch
Bits/Sample: 1
Compression Scheme: CCITT Group 4
Photometric Interpretation: min-is-white
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 2156
Planar Configuration: single image plane
Page Number: 1-0
Software: GPL Ghostscript 8.70
DateTime: 2021:04:27 13:12:37
Group 4 Options: (0 = 0x0)
TIFF Directory at offset 0x8dc (2268)
Subfile Type: multi-page document (2 = 0x2)
Image Width: 1728 Image Length: 2156
Resolution: 203, 196 pixels/inch
Bits/Sample: 1
Compression Scheme: CCITT Group 4
Photometric Interpretation: min-is-white
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 2156
Planar Configuration: single image plane
Page Number: 2-0
Software: GPL Ghostscript 8.70
DateTime: 2021:04:27 13:12:37
Group 4 Options: (0 = 0x0)
Thanks in advance for any help you can provide.
Brian
Either WinPrint HylaFAX is submitting a black document or Ghostscript is converting the document that WinPrint HylaFAX is submitting into an all black page. You'll need to look at the original file submitted by the client (Postscript, PDF, PCL, or TIFF) from the docq directory (in the example you showed it would have been docq/doc88814.ps) and look at it. Assuming it looks fine in another viewer (which would seem to make WinPrint innocent) then you'd need to step through the Ghostscript conversion process to see what it's doing wrong. You can get the Ghostscript commands by setting ServerTracing to 0xFFF in /var/spool/hylafax/etc/config and then restarting faxq. Then the syslog will show "FaxQueuer" entries that include the conversion syntax.
Thanks for the response, Lee. Based on your input letting me know which file is the one submitted from WinPrint Hylafax, I was able to see that the client is submitting a completely black page. I checked the support page, and we were running a slightly older version, so I updated the client on the machine that is experiencing this the most, but it didn't change. I discovered that the person at this PC is using ScandallPro to scan documents and send them through Hylafax. I'm going to do some testing to see if there is some incompatibility between ScandallPro and WinPrint Hylafax that might be causing this. I'll update when I find something.