Messages

No problem.

Have you tried the direct download and manual install approach?

http://www.bchemnet.com/suldr/pool/debian/extra/su/suldr-keyring_2_all.deb
terminal: sudo dpkg -i suldr-keyring_2_all.deb
refresh repository (apt-get update or equivalent)

Usually I recommend the most recent driver version that works with a printer, but in this case it might be worth trying 4.00.35 or 3.00.90 in case this is an obscure bug introduced in 4.00.39.  If not, and if this only happens with pdf files, another option might be to use a tool such as pdf2ps to convert the pdf to postscript before printing.  If neither of those helps, it may be a bug in the way the new CUPS is interacting with the driver.  In that case, your best bet is probably to just print 1 page at a time.

The only change was to add an explicit dependency on libcupsimage2, which would have no effect on a Buster system because that package was already a dependency of CUPS (but that was changed in the version of CUPS in testing/unstable, hence the need for the explicit dependency).

So I would not expect that those suldr package updates would have had any effect on your system.  The exception might be if you made a change to a configuration file that was overwritten by the default file when the package updated.  If so, the likely culprit is either /etc/sane.d/xerox_smfp.conf or /etc/sane.d/smfp.conf.

If not that, were there any other packages updated this month?

python-wcnk has been removed from Debian as part of the gradual removal of all python2 code.  I do not know if there is something that can replace it for python3.

I can change the dependency, but as far as I know the script does not work with pypdf2.  If you find otherwise, let me know.  However, given that Debian (hence Ubuntu, etc.) are in the process of removing python2 entirely from the distribution, I am not going to make changes to encourage use of pypdf itself via pip, or other python2 libraries.  All dependencies for this script should be changed to the python3 versions if it is going to remove useful, which requires rewriting the relevant portions of the code.

The utilities are python scripts, so the packages are their own sources.  You can manually download the packages if needed:
https://www.bchemnet.com/suldr/pool/debian/extra/su/suld-scantopc_0.4.5-5_all.deb
https://www.bchemnet.com/suldr/pool/debian/extra/su/suld-scantopc-gui_0.4.5-3_all.deb

Some Samsung (and other manufacturer) printers routinely print "black" by using color ink, if the job is color but converted to grayscale.  Other than the postscript option, I do not think there is anything you can do to change that behavior.  The only justification for printing black this way is to drive up sales of color ink.

I do not believe this is possible with that printer.  Some printers have an option to force grayscale at the printer level (i.e., by changing a setting on the printer itself) but the CLP-510 does not.  So grayscale would have to set on each device that sends a job, because I am unaware of any software way to modify the job request that an individual user sends when that job comes from a separate device.

You could set up the printer as a grayscale generic postscript printer rather than as the CLP-510 model (i.e., not using the Samsung driver at all).  That would universally prevent color from being an option, but might impact print quality.

All driver packages have been updated to include a dependency on libcupsimage2, to reflect a change in CUPS package structure start with CUPS 2.3.1.  This should prevent (or fix) issues with the printers that rely on the raster component of CUPS.

For those still using the Configurator, note that Debian has removed qt4 libraries entirely, so the Configurator is not installable with Debian testing, the next Debian Stable, or the latest Ubuntu (or other distributions) that pull from Debian testing/unstable.  Because of a major security issue a couple of years ago in openssl, after qt4 development was discontinued, one of the essential qt4 libraries for the Configurator is no longer functional.  Therefore, there is no secure way to keep the Configurator installed with a new distribution, and I am officially declaring my support for the Configurator ended.  I am leaving the packages in place for a while longer, but they will eventually disappear, likely along with many packages that are being utilized less than once a month on average (some driver versions, most i386 packages, and all armel packages).  I expect more compatibility issues to arise as CUPS evolves and these drivers continue to age, so I will need to prune the packages down to only those receiving significant use to match the effort I can invest in keeping any packages working.

I appreciate the thought, but no.  I am content knowing that I can make the world a little better than it otherwise would be for some people.

Install the package libcupsimage2.  I believe that will solve your problem.

It seems that cups no longer include this library by default, as of 2.3.1.  Until I have a chance to modify the packages here to add a dependency explicitly on that library, it will need to be installed manually.  This might still only be affecting a small number of people because several common cups drivers do explicitly depend on it, so many people probably have it installed even with cups 2.3.1.

I just now found out about the status of SULDR.  I finally after many years of successfully using my CLX-3175FW had to uninstall the printer definition and rebuild it.  But, that said, I'm interested in helping out if you choose to shut down the site.

I appreciate the offer and will definitely keep it in mind.  If I again reach a point where it looks like I am unable to continue, I will reach out privately.

There are no binaries for the Raspberry Pi, nor is the source code available.  Samsung never released either and HP has done nothing since purchasing the Samsung printer line.  As far as I can tell, it is impossible to use this printer with the Raspberry Pi directly.

Have you tried the suggestions in issue 11 for scanners?
https://www.bchemnet.com/suldr/scanning.html#11

The network-1 package is only for much older driver versions.

You could also try the latest driver2 package, which theoretically should work with that printer.

It is part of the standard Debian and Raspbian repository, so you should be able to install it the same way as any other package.

This driver will not work with the Raspberry Pi 4, no matter how you try to install it.  The issue is that the driver for ARM processors is built only for much older processers than the type used in the Raspberry Pi.

There is some evidence that the printer may work if you install the splix driver (printer-driver-splix package), and set it up as a ML-1660 printer.  This method should be compatible with the Raspberry Pi.

For all practical purposes, the Scan to PC utility is dead and will rarely work.  Nobody is actively maintaining it.  You are free to try it, but if it does not work then you are on your own.  For the reasons outlined in the link below, there is no real motiviation to address the issues.

See this announcement: https://www.bchemnet.com/suldr/forum/index.php?topic=366.0

Additionally (as of June 2020), some of the necessary python2 libraries have been removed from Debian as part of the planned elimination of all python2 code.  Therefore, anyone interested in utilizing this tool would first need to update it to all python3 libraries.  Unfortunately, not all the libraries utilized by scantopc have 1:1 replacements in python3, so it is not just a matter of substituting all libraries directly.

HP has shown no interest in updating the Samsung printer driver, and has no financial incentive to do so (after all, there has not been a new Samsung-branded printer in nearly 3 years as of this moment).  As of this post, the latest driver release is nearly 3 years old, and is really based on code that is now 5 or more years old.  So the driver is going to gradually stop working on modern Linux systems as Linux and CUPS continue to evolve.

In addition, qt3 and qt4 are long obselete, so the Configurator packages (last updated 7 years ago) will often not install, or even if they do they still not work.  This will continue to get more frequent.  Even if you do manage to get everything installed, note that the relevant qt packages depend on an obselete and insecure openssl, and will not work with a modern library.  That is the main reason I am not attempting to repackage these programs in a way that will allow them to be installed even after distros drop the necessary dependencies.

Finally, CUPS has made design changes that, starting with version 2.3 (included in most mid-2019 Linux distros), are intended to make all drivers and PPD (printer instruction) files obselete.  As of 2.3, some releases of CUPS already do not work with the Samsung PPD files due to the use of non-standard keys in the Samsung PPD files.  Sometime in the next couple of years, it is likely that a current CUPS install will simply not work at all with these drivers on any system.  The new approach for CUPS is based entirely on the IPP protocol, which some (but by no means all) Samsung printers support, to varying extents.  See, for example:
https://www.cups.org/blog/2018-06-06-demystifying-cups-development.html
https://github.com/apple/cups/issues/5562

Somewhat related, scanning support that depends on the Samsung drivers continues to get less reliable each year due to various system changes in Linux, and there is no work around for this.

So nearly all Samsung-branded printers are going to stop working in Linux over the next few years if you keep an up-to-date system.  I will continue to host the files and resources here for a couple of more years, but after that there will not be much point and the best solution to a non-working Samsung printer will probably be to replace it.

Unfortunately, all I can offer as a solution is to try a different version of the driver.  Or to contact HP to see if they have any interest in developing an updated driver, but I doubt it both because they have no financial incentive and because CUPS is making changes that will eventually make obselete all drivers in Linux (and printers that do not support the new CUPS approach).

Do you mean the c467 (not c647)?  As far as I know Samsung, never produced a printer with a model number of c647 (or c6 anything).

My three suggestions are to (in no particular order):
1. If you installed via the repository, try using the Samsung installer.  Or if you installed using the Samsung installer, switch to using the repository.
2. Try a different driver version within the supported range.
3. Try printing by USB, even if only temporarily, to determine if it is a problem specific to the wireless connection.

I solve this problem in ubuntu 19.04 installing printe-driver-splix and this openprinting ppd --> https://mega.nz/#!9kcz2Cbb!xwTwiaD-RJTtEDu19V1NFSxZiAcRLapId0HO82Rs3Vc

Thanks for sharing.  Note that a more stable link to the ppd is https://github.com/rshev/SpliXextras .  It is possible that sufficiently motivated individuals could use this as a model for adapting other PPD files for use with splix (printing only, not for scanning), as the content differences between this and the Samsung PPD are not large.

This error seems to be appearing with several ML printers on distros that have updated to cups 2.2.11 or pulled recent patches into 2.2.10.  Although there are no CUPS errors reported, I believe this is due to some change in CUPS.  Please report it as a bug to Fedora and ask that it be escalated to CUPS.  But honestly I expect that the CUPS team will say "not our problem", as they seem determined to keep making changes that are breaking support for Samsung printers.

As a fix, my best suggestion is to revert back to CUPS 2.2.10.

This problem is related to the CUPS issue reported here:
https://github.com/apple/cups/issues/5562

The gist is that CUPS is making changes that are not compatible with the Samsung drivers.  CUPS 2.2.11 has recently been patched to restore working behavior for Samsung printers, but there is no guarantee that will remain true.  Debian inherited the problematic change in 2.2.10-4 and it may remain as of 2.2.10-6.  If you are using a Debian-based distribution and still have this problem, report it to the bug tracker and reference the CUPS issue above.

This is all related to a complete change in the way that CUPS handles printer drivers, as described here:
https://www.cups.org/blog/2018-06-06-demystifying-cups-development.html

The gist is that printers that do not use IPP, and/or that use custom drivers such as the Samsung driver, and at risk of no longer working after CUPS 2.3 is released (although they will likely continue working for some unknown amount of time after the initial release).  Some of the newer Samsung-branded printers support IPP, so will not necessarily be affected by the changes.  I do not know what the long-term implications are for continuing to provide this repository and the associated drivers.

I suggest trying to revert your CUPS package to the previously installed verison (e.g., using snapshot.debian.org, although you may need multiple packages) to see if the printer works again.  If so, then it is a bug in CUPS and should be reported through the Debian bug reporter.

I have reworked the supported printers page to make recommended versions more clear.

Thanks for sharing.  I will add this to the information about scanning.

Thanks for the input.  I have taken some of your suggestions.  The two main ones I did not take were the suggestion for sans-serif and to narrow the text display.  Personally I find serif much easier to read, I know all about the arguments for why sans is supposed to be easier on a screen but my experience differs.  And I admit to being a real dinosaur about the text padding issue, because I prefer to control text width by managing window size, and artificially narrowing the display complicates my window mangement.

Neither of those is a good argument for user interface design, because I am not the target the audience for this website.  Consider it a silent protest to the design decisions others are making that I dislike.  Of course, I still do not use a "smart" phone and detest all touch interfaces, so my ideas of interface design are far out of sync with current norms.

I am glad that you have found the site useful.

W: Failed to fetch http://www.bchemnet.com/suldr/dists/debian/extra/binary-amd64/Packages  Bad header line

When this error occurs with an otherwise apparently working repository or one that had been working, it pretty much always means some sort of network traffic error occurred.  The error should automatically clear quickly, but apt sometimes get stuck in some odd state.  Usually clearing the cache takes care of it, but obviously not this time.  Some other things you can try to force apt to find the repository again:
1. Change the "http" to "https" in the repository source line.  In some cases, it might be necessary to update the repository files, and then revert back to "http" to get it to work.
2. Comment out/deactivate (or delete) the bchemnet repository line, update apt, add the line back and update again.
3. If neither of the above works, it could be a persistent DNS or path resolution problem.  (However, I doubt this because if it was you would probably not be able to reach this forum.)  If know how, you can try changing the DNS servers being used by your computer/network, updating apt, and then changing the DNS servers back.
4. Wait 24 hours, clear the cache again, and repeat 1 or 2.

The repository is up, but there may be some temporary network path issue reaching it from some locations.  If the issues persists in a day or two and clearing the cache does not solve it, reply here.