Can Linux be used professionally for Desktop Publishing?

This isn’t a click bait headline and I won’t have an answer either way be the end of this post. There was this article in my RSS feed yesterday pointing out that the Linux Foundation wasn’t “dog fooding” FOSS or Linux with their annual report. Buried in the metadata of the PDF that they circulated was the not too surprising fact that the brochure was created with Adobe Creative Suite on macOS Catalina 10.15. The blogger considers it quite the indictment. I’m not so sure but I would like to explore if Linux can be used by desktop publishing (DTP) professionals. I’ll caveat this exploration by saying it was the early 1990s when I was last at all seriously involved in DTP. So some of my conventional wisdom may be dated. With that stated, let’s explore the potential of Linux professional DTP.

My question is not if Linux can hypothetically be used for desktop publishing. It is if it can practically be used in this role. There is a dramatic difference between those two statements. When someone says something can hypothetically do something that means if you stand on your head and repeat incantations maybe just maybe you’ll get something out of the whole process. It’s like people who get Doom running on a TI-85 calculator. There certainly are merits for saying it’s worth doing something for the sake of doing it, but no one does that experiment hoping to actually play Doom regularly on a TI-85 calculator when all is said and done. So to qualify for being beyond a mere hypothetical we can’t just punt to something like LaTeX, as good as it is for it’s intended purposes, or some other similarly unqualified software which would technically generate graphics, Postscript, or PDF files.

In an ideal world the simplest way to answer is if it’s possible to run the industry standard desktop publishing software, Adobe Creative Suite, under Linux. That is pretty much an emphatic no. Technically some of them run to various levels under WINE emulation. I don’t have a license for Adobe Creative Cloud so don’t know for sure how it works beyond what I can read on the WINE or PlayOnLinux status boards. The statuses there if even read optimistically aren’t something that I’d want to bank a professional job on. Again this isn’t about experimenting with DTP on Linux it’s about if it’s possible to do it professionally. Having programs that run intermittently or unstably, assuming they run at all, isn’t something you would sign up for when getting paid for your work is on the line. The question then becomes if there are apps which do the same things as the industry leading programs. The answer is a pretty strong “yes” thankfully.

The desktop publishing process is going to fall into a few specific categories for the various stages of work. Starting at the earliest stages would be the development of graphics. Those graphics fall into the category of raster (photographs, paintings, etc.) or vector (line art, logos, animation frames). The vector category can get a bit blurred with 3D modeling, where the modeling is done similar to vector graphics but the outputs can end up being raster graphics. On the photography side you have the entire photo editing, photo color management, and so on. We rarely look at these graphical outputs in the raw. Instead they are assembled with headlines, prose, and other flourishments into brochures, posters, catalogs, etc. That process is called page layout which is the next stage of the process. In the modern world with digital distribution being prominent that can be almost the last process. Simply print that out to a PDF file and you can distribute it to millions of people globally. Lots of stuff is still physically printed though. For very low volume and low quality work it’s possible to print that PDF file out on your own local printer or at your local Kinkos. Most work though is going to go through an offset printing process, which means a service bureau or print shop which will go through it’s own production stages to turn that output into assembled final products. To reduce that process into a sentence isn’t doing it justice but exploring it is a bit out of the scope of this discussion, although not entirely as we will see.

So for each of those stages is there software which can be used to fill in for the Adobe Suite which is the industry standard? The answer is yes! Before we get too far ahead of ourselves though they aren’t one for one replacements. They are not feature for feature identical. They are not complete replacements. The question is if they are replacement enough for most uses. Putting oneself in the shoes of a graphics designer who needs to do photo manipulation, raster graphic generation, vector graphic generation, and page layout, which tools are available? I created an Ubuntu Linux 20.04 and loaded it up with what seems to be the most popular software for doing these sorts of tasks on Linux:

Linux Creative Apps
Linux Creative Apps

From right to left you have:

  • Krita for digital painting and raster graphics work
  • GIMP for raster graphics work
  • Inkscape for vector graphics work
  • Scribus for page layout and generating output for print shops

Technically these four apps would fit the bill for everything an independent graphics artist would need to generate creative products. Of the four Krita is best positioned. It is actually top of its class on Windows, Mac, and Linux for digital painting so may be the one place where creation on Linux is on par with other platforms. GIMP is hypothetically a potential replacement for Photoshop however it makes no attempts to have the same workflows or plugins compatibility therefore would take a lot of getting used to for beyond simple tasks. Inkscape would be a great stand in for Adobe Illustrator. It can’t do everything Illustrator can but it’s core workflows for simpler graphics are comparable. Again when one gets into more complex types of creations the differences may add up. Lastly there is Scribus which can be used for page layout. Again it has most of the major features one needs for DTP work but it will have sufficiently different workflows and some deficiencies for people coming from Adobe products.

If something does 80% of what you need, the important 80%, is it sufficient to claim to be useable as said replacement? That is basically where the discussion about this lies. Picking up a new tool is always a challenge. Even with industry titans behind them it is hard to get users entrenched in one tool to switch over. However we do know that can happen. The effort has to be worth the result for potential users though. It may be the case that on Linux the feature sets are now complete enough that for many uses these tools can be replacements for professional desktop workflows. When I looked at this years ago the one glaring hole that existed was in the world of color management. Color management is something we take for granted but graphic designers and printers cannot. At the very least tools, especially tools near the end of the production process, must be aware of at least dealing with colors in the print color space of CMYK (Cyan, Magenta, Yellow, and Black). These are the primary print colors that we can make any color with (not really but for the sake of this discussion it’s sufficient). Print tools that only work in the RGB (Red, Green, Blue) color space we have with monitors won’t cut it. It seems that all the tools now support CMYK, although the support in GIMP is still partial.

Beyond these color space issues is another important color issue in print: spot color. When making photographs you definitely want to be using the CMYK technique of breaking up the colors in the image into these primary colors so that it can be printed in photorealism with just four colors. However if you want a nice solid color, or gradations in one color, you often want to specify that exact color. There are entire color systems, most famous PANTONE, which allow one to specify a color in an exact way that can be reproduced in print. Think about it like when you go to the hardware store to pick a paint color for your walls. You flip through swatches, pick the one you want, hand it over to the technician who then mixes the various colors in a way that produces the exact color you want. That is exactly how spot colors work in printing. Can you just do it with CMYK? Kind of you can but it doesn’t create as solid a color because the trick that makes the process work is called screening. Also as noted above the CMYK color “gamut”, range of colors it can create, is constrained so it may not be possible to create that exact color either. For these reasons it is critical that designers be able to specify spot colors. Until recently that wasn’t realistically possible with these applications. Now it is.

So one can create the basic products, with some high percentage of the capabilities of the tools matching Adobe capabilities. What about the hand off to the printer? This is where the page layout tool really has to have it together. Can it provide a file that the printer can use with everything the printer needs to accurately reproduce the final product? I honestly don’t know. Scribus seems to have a lot of what would be minimally sufficient. It can do the “separations”, the process of breaking the colors down into their CMYK and spot colors, it can do proper page markings for alignment etc. It can output the pages with bleeds (colors going over the edge of the page so that when printed there is a margin for error when trimming). It can output those as PDF files, raw Postscript, and importantly embed the fonts. Is that enough though? I honestly can’t say.

Back in the day when I worked at a service bureau that handled this final stage of taking graphic designer’s files and generating films for printing we would have each of the standard software packages being used. At the time there was no robust common format like PDF that could be used as a lingua franca between programs. It may be that today that point is moot. If it is then there is a real chance it’s possible for a professional graphic designer to use this tool chain to produce work that printers can use. From what I’m reading it sounds like PDF files are almost preferred. The only other file format even mentioned in places I looked at was Adobe InDesign, the biggest but not the only commercial page layout application. Adobe’s PDF format then may be the magic that really opens up the possibility of using these tools as a professional graphic designer in desktop publishing.

That’s all glass is half full view, but what are potential stumbling blocks? By far the biggest is lack of familiarity and needing to learn a new tool. It’s the same thing when as a programmer I have to pick up a new framework, language, or IDE. Things aren’t where you expect them to be. Features are often kind of the same but sufficiently different to be not as intuitive. We get into our habits and patterns and to break out of them takes effort. Beyond just familiarity there is the potential scalibility issue. I’m thinking about this mostly from the perspective of an individual contributor but for larger workflows there are content management systems built around these industries’ workflows. I don’t know if there is anything comparable in these applications but there definitely isn’t some unified experience around it like in the commercial packages.

Lastly there is the sellability of your skills issue. Someone whom hires you to make a brochure for them probably doesn’t care if you use InDesign, QuarkXPress, Scribus, or anything else as long as the job gets done well, on time, and on budget. If you are proficient enough in the tools you can probably assure that. However as soon as you have to start collaborating will the same be said? If you are working on the vector graphics and someone else is working on the final composition can you all “play nicely” with your various tool sets. There seems to be enough standard formats that that is strongly possible. In programming speak it’s like if I’m coding in IntelliJ and you are coding in VIM. It mostly doesn’t matter, but it may create some issues (i.e. spaces vs. tabs issues in the programming environment space).

What about being able to sell yourself from a professional perspective. If you ultimately decide to go work for a someone what sings better on your resume “Adobe Photoshop, Illustrator, and InDesign” or “GIMP, Inkscape, and Scribus”? If you had both with equal proficiency that my speak even greater volumes but if you had to choose just one to specialize in and build a career around in a way that makes yourself marketable to potential employers the Linux/FOSS stack is probably not it right now.

What I’m seeing in all of this is that from a technological perspective while there isn’t 100% feature parity, and no where close to that, for many/most uses it is more than sufficient. In the case of Krita it’s probably the first class package even. With the standardized output file formats being supported by all programs there is a real chance that one could make a go at using these tools professionally to create great work that integrates well with other’s workflows all the way down to print production. It’s not a slam dunk that it’s possible but it looks highly possible. The road blocks then become a transition familiarity problem, assuming not starting with them in the first place, and potential marketability problems. These are not insurmountable at all though.

Getting back to the Linux Foundation’s brochure faux pas, is it as bad as the original blogger highlighted? Assuming they outsourced the graphic design I would say absolutely not. I would imagine in the print world you would be hard pressed to find a firm that isn’t using Adobe Creative Suite. If they are doing it internally I’m still going to lean on it probably not being that bad. Their marketing team doesn’t have infinite resources. The people they hire will be trained in the latest industry standard tools which, like it or not, are Adobe Creative Suite running on Mac/PC. I’m actually far more put off by them using Microsoft Office PowerPoint on Mac/Windows laptops for presentations than this issue. I get why they may need to use Mac/Windows and have Office installed for interoperability (food for another post) but they could at least do public presentations in LibreOffice distributed as PDFs worst case. There was something that the original post highlighted which does bother me though.

The blogger went through a few layers of metadata to figure out the ultimate production platform. The top level metadata would have been sufficient to discover it normally. However in this case it wasn’t. The metadata at the top level didn’t show the true originator but instead showed the producer as “Linux kernel 0.12.1 for Workgroups” and the creator as “Sharp Zaurus XR-5000 (Maemo5) Edition”. Was this something nefarious or did something overwrite this with this nonsensical data? I have no idea. I call it nonsensical because I have never heard of “Linux for Workgroups” much less a kernel specifically for it. There was a Linux kernel 0.12 but it is from 1991, a mere few month safter the very first announcement of Linux ever on USENET. The Sharp Zaurus was a PDA type device made in the mid-1990s not a modern device. If someone was going through the trouble of faking out the metadata for nefarious purposes this is not the combination of values they’d pick. Were they trolling? Is there some program which post-processed the data which use these ridiculous values as defaults in the same way a programmer uses 1900 as a default bogus year to make it crystal clear it’s not a real value? I don’t know. I’d be curious to see what happened there. It just looks bad either way though.

I’d like to leave on a constructive note. In my research for this article I ran across an entire blog dedicated to this topic called Libre Graphics World. It seems to be a great spot for highlighting updates to the program, content generated by artists and designers using these tools, and some tutorials on how to do things with these tools. I’ve often wanted to explore my creative side in ways other than writing software. I have no raw talent in these areas but that’s not the point. Fumbling with these tools creates very little momentum for continuing with it. I’m going to attempt to follow the tutorials to gain some proficiency in these FOSS desktop software graphic design tools running on my Linux machine though.

Picture of Me (Hank)


Updates (126)
Journal (119)
Software Engineering (115)
Daily Updates (84)
Commentary (68)
Methodology (58)