# Printing Issues: black images **URL:** \ **Category:** Community Support\ **Tags:** tlclient, linux\ **Created:** [14 July 2024 14:25 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006 "2024-07-14T14:25:15Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![k97](https://avatars.discourse-cdn.com/v4/letter/k/da6949/32.png) [@k97](https://community.thinlinc.com/u/k97)\ **Post date:** [14 July 2024 14:25 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006/1 "2024-07-14T14:25:15Z")
When printing with thinlocal, images get a black background. In some cases, I get almost completely black A4 pages. Client: 4.16.0 on Linux Server: 4.16.0 The image shows a picture of a direct-print (from the system the client is running on) next to a thinlocal-print of the same test-page. ![IMG_4820](https://europe1.discourse-cdn.com/flex005/uploads/thinlinc/original/1X/d1884cfb97ba679226e1c2da178e2d2e7395146a.jpeg) ---
**Author:** ![aaron](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/aaron/32/13_2.png) [@aaron](https://community.thinlinc.com/u/aaron)\ **Post date:** [16 July 2024 03:18 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006/2 "2024-07-16T03:18:15Z")
Hi @k97, Thanks for the report. I don’t have a straight answer for you I’m afraid, printers are tempremental things… this is nothing I’ve seen before. We would have to try and reproduce it so we can troubleshoot. What distribution were you using both client and server side? I assume you were printing from the same application in both cases? @samuel any ideas? ---
**Author:** ![samuel](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/samuel/32/335_2.png) [@samuel](https://community.thinlinc.com/u/samuel)\ **Post date:** [16 July 2024 10:49 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006/3 "2024-07-16T10:49:03Z")
This is not something I’ve seen before. Would it be possible for you to share this document with us so that we can investigate what’s happening @k97? What operating system do you use on the client machine? ---
**Author:** ![k97](https://avatars.discourse-cdn.com/v4/letter/k/da6949/32.png) [@k97](https://community.thinlinc.com/u/k97)\ **Post date:** [17 July 2024 12:55 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006/4 "2024-07-17T12:55:32Z")
Thanks for your replies. On server side it’s the current Tuxedo-OS (KDE). On client side the problem appears with Ubuntu+KDE (Kubuntu 22.04) and Tuxedo (with KDE). No problem with the windows tlclient. The printed document is the printer-test-page from the setup-dialog. Same problem with other documents with embedded images. I attached another picture that shows the print via window-client (left) and via kubuntu (right). ![IMG_4835](https://europe1.discourse-cdn.com/flex005/uploads/thinlinc/original/1X/ba15223f2c8e06fe9a7d86d24aa1bc81834bc577.jpeg) ---
**Author:** ![aaron](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/aaron/32/13_2.png) [@aaron](https://community.thinlinc.com/u/aaron)\ **Post date:** [22 July 2024 00:41 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006/5 "2024-07-22T00:41:06Z")
Hi @k97, I don’t have access to the KDE printer test page, but I can see that the gradient in the header isn’t working either. So I did a quick test using the “Print Black & White” page at [https://printtester.com](https://printtester.com), which contains a gradient. Printing both locally and via `thinlocal` worked fine. Would you be able to perform the same test and see if it works for you? ThinLinc basically hands the print job over to whichever printer is configured as “default” on your local machine. Could you also check that this is configured correctly? ---
**Author:** ![CendioOssman](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/cendioossman/32/385_2.png) [@CendioOssman](https://community.thinlinc.com/u/CendioOssman)\ **Post date:** [22 July 2024 08:48 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006/6 "2024-07-22T08:48:37Z")
This looks familiar and is something I’ve seen sometimes when the print data is converted to PostScript. ThinLinc does this on Linux for maximum compatibility. I’m not sure whether that is really needed for current systems, though, and we have a bugzilla entry to use the modern PDF format instead: [https://bugzilla.cendio.com/show\_bug.cgi?id=5347](https://bugzilla.cendio.com/show_bug.cgi?id=5347) Unfortunately, I’m not aware of any way to work around the issue with the current client. ---
**Author:** ![k97](https://avatars.discourse-cdn.com/v4/letter/k/da6949/32.png) [@k97](https://community.thinlinc.com/u/k97)\ **Post date:** [22 July 2024 10:52 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006/7 "2024-07-22T10:52:34Z")
No issues with the printtester gradients. It also seems to depend on the applications from which printing is done. I printed the same document three times (reduced to 16 pages on one to save color). In the photo, you can see all three prints: 1. page: Printed with Chrome 2. page: Printed with Firefox 3. page: Printed with Okular (no black box, but the scaling doesn’t work). It’s exactly the same with xubuntu instead of tuxedo on server-side. I can share the document, but I’m not allowed to upload pdf-docs. ![IMG_4836](https://europe1.discourse-cdn.com/flex005/uploads/thinlinc/original/1X/84394be5335975af686d582f756537522c4dd75c.jpeg) ---
**Author:** ![aaron](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/aaron/32/13_2.png) [@aaron](https://community.thinlinc.com/u/aaron)\ **Post date:** [22 July 2024 19:31 UTC](https://community.thinlinc.com/t/printing-issues-black-images/1006/8 "2024-07-22T19:31:32Z")
Thanks for the info @k97. As @CendioOssman pointed out, we do have a known issue in our bugzilla which may be causing this. I was also reading the other day that CUPS are removing driver support completely in favour of “IPP Everywhere”: > > > \> Note: The goal of this issue is to have a place to discuss the eventual remova…l of printer driver support and support for raw queues in OpenPrinting CUPS v3.0. The \[original Apple CUPS bug report\](https://github.com/apple/cups/issues/5271) has some additional history, and what exists here is an updated summary of that historical discussion. > > Why do we want to do this? > > \- Raw queues used for special-use printers require custom applications that know about printer capabilities and how to produce printer-ready (document) data. Using CUPS is a convenience, but plenty of applications talk directly to printers (think Point of Sale systems) > \- Raw queues used for shared printers require client software to talk directly to the server to get the printer capabilities, which breaks when sandboxing/AppArmor/SELinux is used > \- Almost every printer manufactured since 2010 supports IPP/2.0 with standard file formats > - Holdouts are industrial label printers and certain vertical market printers > \- PPDs and drivers have been holding us back from offering better user experience (ready media, localization, full range of printer options/values), improved document processing, and improved accounting > \- PPDs and drivers are a security and distribution nightmare > > We already have a replacement for raw queues for shared printers (local/temporary queues managed by cupsd), and raw queues for special-use printers already largely bypass CUPS and can use existing commands or character device files to communicate with those printers. > > As for printer drivers, those few printers that "need" them can migrate to standalone applications/services using the CUPS API to provide an IPP Everywhere-compatible Printer instance. \[PAPPL\](https://github.com/michaelrsweet/pappl) provides a convenient framework for easily creating these applications and porting existing CUPS raster drivers, and the following printer applications are already available or (in the case of Gutenprint) under development: > > \- \[hp-printer-app\](https://github.com/michaelrsweet/hp-printer-app): PAPPL-based PCL printer application based on the CUPS rastertohp driver. > \- \[LPrint\](https://github.com/michaelrsweet/lprint): PAPPL-based label printer application, currently supporting Zebra and Dymo label printers with plans to support more, based on the CUPS rastertolabel driver. "Raw" printing is supported as well if you have an application that produces the native print data format. > \- \[ps-printer-app\](https://github.com/openprinting/ps-printer-ps): PAPPL-based PostScript printer application that supports all CUPS/PostScript printers via PPDs and includes all of the Foomatic and HPLIP drivers. > \- \[Ghostscript Printer Application\](https://github.com/OpenPrinting/ghostscript-printer-app): PAPPL-based printer application for Ghostscript-based printer drivers. > \- \[Gutenprint\](http://gutenprint.sf.net): A PAPPL-based printer application for all Gutenprint printer drivers. Apparently IPP Everywhere means that everything gets converted to PDF and sent straight to the printer. So it may not worth spending much time fixing the “old” CUPS behaviour, but rather upgrade ThinLinc to make use of the new “driverless” CUPS once it is released. In the mean time, a workaround may be to print to PDF, save the file to a “shared drive” from the client, and print locally using an application which is known to give the right output. Not ideal, but hopefully it’s only a minority of documents which don’t print properly in ThinLinc. Hope that helps.