The English book printed project: production report 1

Published on

After the release of the eShop (thank you for all the purchases!). I started this week another huge item on my TO-DO list for Pepper&Carrot: self-publishing it as a comic book. I do it because I find it exciting to make a big high quality comic book using only FLOSS from scratch! I'm not expecting much from the sales. I just want my own Pepper&Carrot book, 100% FLOSS to crown the last five years of production. Focusing on that target even drives me away from the Inktober challenge I usually very like. But it's a project with a lot of difficulties and I want to make it perfect. So I took the necessary time to do research and experiments before going into production. And that's where I am at start of October 2019. Here is the results of one week of intense research and tests:

The book

Deciding the format was hard: I bought samples done by my printer, reviewed all book at home. After a lot of thought on it, my project will be a large 8,5"x11" (21,59x27,94cm) and thick book with a hard-cover. It will include 193 pages of comics -from episode 1 to episode 29- printed in full resolution on a high-quality almost mate paper inside and glossy for the cover. ( I have a sample of this quality on my desk, this is really what I want). A gallery of additional artworks will be added on full page to the comic, full credits and the list of patrons to shape a 200 pages large book. My target dream price: in between 30$ and 40$ (without shipping). I'll see if I can do that, if I can't I'll explain why in a future update. So far, it looks like I can make it from my estimation.

A double page in Scribus

A dedicated cover

I want the book to have its own cover, so I plan to paint a specific illustration for it. It will take me days but I don't want to reuse the illustrations already in usage for the Glénat book project, the TokyoPop publishing, the Breton version, etc... I'll start this artwork next week and I'll show the progress on social medias.

100% made with FLOSS

"[...] there's an entire industry out there that spent the last ~25 years making sure it's a pain in the rear to do anything useful with PDFs without their expensive tools. Now you want to undermine their collective efforts? Think of the children! :)"

~ Satō Katsura (from here).

This quote summarizes perfectly the situation. As usual, I'll use only Free/Libre and open-Source software: Krita, Inkscape, Scribus on my Kubuntu 18.04.2 LTS. Yet, my printer provides a tutorial for Scribus, the *.icc and templates. (A FLOSS-friendly printer? Only when I'll receive perfect prints I'll be able to tell).

Testing various CMYK convertion methods (comparing a CMYK red from Krita and CmykTools)

Multilingual, collaborative on Git

English only? What about Spanish? Russian? or more? That's one of the most ambitious part of my project: I started to design a multilingual system for the maximum automation around a GIT repo with scripting. I plan to use the data already translated in order to publish a lot of languages; but I'll also need help to translate specific texts. This will come after, I'll start with the English version.

An early brainstorming/mind-map of the translation system for the book publishing repository.

Printer specifications

My printer works only with the CGATS21_CRPC1.icc CMYK color profile and the PDF/X-1a or PDF/X-3 file format. I can't expect in this process a man in the middle reviewing my file on a machine with proprietary software like the one of Adobe: everything goes directly to the print machine: it must be compliant and perfect. If anything fails, I'll have to pay for the mistake and the time of the operator. Also, PDF/X-1a or PDF/X-3 mean no transparency for designing the page.

Without transparency, I'll have to overlay page with translation and without to clean credits.
(Example gif animation of the process)

The test and bugs:

During the process of exporting dozens of test PDFs with various settings and trying everything the web wrote on the topic with trial and error, I made discoveries. I report them here if you are curious enough to read them. But also for them to get referenced later by search engine; I'm also posting my workarounds: they might help.

Rendering comparison, click to enlarge

Comparison details of picture on top (from left to right):

  • Scribus (Softproofed with CGATS21_CRPC6.icc but output with CGATS21_CRPC1.icc)
  • Krita displaying the extracted image from PDF.
  • Okular displaying the PDF output (not color managed).
  • Nomacs displaying the original sRGB.

The fog of CGATS_CPR1.icc

Haaaa, color management on Linux... All a poetry! The color space of the profile looks really small at a first glance, but according to the sample I bought; it is very capable of wonderful printed comics colors. Unfortunately, the Soft Proofing of this CMYK profile renders an horrible bleached rendering, feeling like being lost in the fog of a haunted wood. This rendering is consistent in Gimp, Krita and Scribus and it took me hours of test to exclude I was doing a mistake with my color workflow. But once rendered the issue disappear, and colors looks as good as a CMYK image can be (so after a real convert, not a soft-proof preview). This is also consistent in Krita and Scribus (not in Gimp because well.. still no CMYK as far as I know). So, no possible direct WYSIWYG workflow with Soft Proofing (What You See Is What You Get) but a WYSHITFOG workflow (What You See Happens In The Fog Of Gamma). Just kidding. I found a workaround: Switch to another CMYK profile during prod ; after hours of research I found that the CGATS_CPR6.icc while being softproofed looks similar CGATS_CPR1.icc rendered (not 1:1, but visually Ok). Note for later: don't forget to switch back for export.

Bug Report URL (Krita):

Soft Proofed preview VS real convertion with CGATS21_CRPC1.icc.

The 72ppi TIFF of Scribus

When I started to get a somehow functional color managed workflow, It was obvious I'll have to bring modifications to the comic pages and adress issues I could spot with the CMYK profile (too dark pages, out of gamut effect that translate badly to CMYK,etc). That's something no other publisher did with Pepper&Carrot (certainly to 'respect the art') and they often just went at printing the RGB as it is with more or less success (and sometime, disasters for certain crowdfunding). Well, I'll want to adapt the art and I can. So, I ran a series of test to evaluate how I could save my modifications directly in CMYK and get them in Scribus. I decided to pre-convert pages to CMYK in Krita and export them as Tiff then import them on Scribus: this was fixing the "preview in the fog" workflow but I discovered Scribus was skipping the resolution ppi of Tiff and import them as 72ppi by default. I then tried to update my version. I tested also the last version in development. All of them had this issue, this is too hard to work like that for 200 pages, too many manual tweaks and I wasn't feeling confident for the TIFF format in general. So better to drop this option.

Bug Report URL (Scribus) :

Comparing the same page with various convertion method in Scribus: original on right.

Remastering the artworks on pages for print

On newer tests, it has appeared the best cross-format for CMYK pictures between Krita and Scribus was 'CMYK JPGs'. That's really curious; this format was a taboo for my teachers when I learned Pre-Press with QuarkXPress and Indesign around 2000 (in my youth). But it works and with a compression as near as possible to lossless for this format (100% quality) it is even a good solution for a transition flat format. Things I learned. But I don't feel good about using this format: thumbnails on the file browser looks terrible and it still feels like a hack in a way.

Anyway, I discovered during the process that -with the right settings- the export to PDF of Scribus was doing the conversion to CMYK on the fly whatever input was entered on Scribus; including sRGB format. Splendid technology. I then tested the quality of the exported PDF CMYK of Scribus in competition with Krita and Cmyktools. I obtained very similar results with Scribus and Krita. Cmyktools had other very interesting optimization, but the software being not maintained since 2011, the GUI was spanning accross my two monitors and the resulting CMYK was color inverted after extraction from the PDF. I had to exclude it. The quality of auto-converted CMYK via Scribus had similar (if not exact) quality of the one converted by Krita. I guess it is the same LittleCMS magic under the hood for both of them.

I then decided to go with only the 8Bit RGB workspace for my modification: unify my artworks for web and for print in a single format and remaster the sRGB with Soft Proofing activated for CGATS_CPR1.icc (in fact, 'workarounded' with CGATS_CPR6.icc to avoid the fog). Tweaking slightly the RGB will mean modifying Pepper&Carrot online pages too or how the episodes were designed at release. Remastering them for the book project is the right effort to do at the source to avoid CMYK mistake for the future converting while keeping always the sources artwork in a single place.

Left: Original, Right: the type of RGB corrections that might happens, (work in progress, not happy with the contrast yet).

Validation of the PDF for print

On testing the output PDF of Scribus, the harder is to know when I produce a valid PDF export. How to inspect it? I have not found a perfect solution... I still blindly have to trust something on the output of Scribus. Knowing the buggy nature of FLOSS and how the project degenerate quickly this is not making me confident. But I found a couple of options, mostly via command line interface, on a GNU/Linux system:


Imagemagick can list a lot of information about the PDF with the command here under, including the CMYK nature of the PDF. Unfortunately, no color space. Does it mean ImageMagick doesn't do it? Or Scribus skip including it? I'll never know.

$ identify -verbose output.pdf

Imagemagick can also convert a page of the PDF to a PSD. This command under will return a wrong resolution PSD (a thumbnail) and Krita can open it. CMYK values are well set on the PSD, but the color profile is lost: Krita fallback to Chemical Proof profile: showing something quite similar to Poppler.

$ convert output.pdf output.psd


Poppler via Poppler-utils can list all the image inside a PDF and report if they are CMYK. Same, no color profile, so it can be CMYK-pizza or CMYK-chocolate, this is not Poppler-utils business. I would really like to know if they are all profiled with CGATS_CPR1.icc or if the PDF as a global file is tagged with CGATS_CPR1.icc...

$ pdfimages -list output.pdf

A useful output!

It is also possible to extract the content of the PDF to a folder using the Poppler-utils this way:

$ mkdir extracted

$ pdfimages -all output.pdf extracted/img

The Tiff, PPM or JPG obtained this way are CMYK files but unfortunately have no profile so Krita will display them with the default generic free/libre CMYK color profile: ChemicalProof. You'll need to convert them manually to CGATS_CPR1.icc with Imagemagick (apply simply the profile; no convert/scaling):

$ cd extracted

$ convert img-000.tif -profile /path/to/your/CGATS_CPR1.icc img-profiled.tif

Then you can open in Krita and control the quality of the Scribus rendered files with the color picker to see how it manages the black, how out of gamut colors are scaled, etc.... That's my best solution so far!


Okular, the Plasma desktop PDF reader can read the PDF thanks to Poppler under the hood. But same error here: the CMYK colors are not profiled and fallback to a default profile like Chemical Proof. It is still a blast to have the possibility to read a version of a CMYK PDF on a PDF reader, even if the colors are not faithful: the picture are still readable.


Krita can open a page of the PDF; but will do a bit the same than a Poppler conversion: the picture has same generic CMYK rendering and the result is even not CMYK anymore but all converted in the default RGB used by Krita (sRGB-elle-V2-srgbtrc.icc)...

Conclusion and more links:

I know a lot of you will skip reading this long log and that's fine. I wrote this long results of my research for a future person who will get same trouble as I do and will search Internet to see if other tempted this quest. That's a bottle in a ocean, and a way to log my efforts on the way.

Here are my sources and best Internet links I could find on the topic. I triaged them from reading hundreds of pages.





link Anonymouse  

While I'm not versed in graphical design, I do so enjoy seeing the progress you are making getting an English version of Pepper & Carrot to comic readers. I want it! =3

But oh no! No Inktober! Sadness!!

link Francisco  

Very interesting everything you expose in this article, although I think I will need to reread it several times, since it is dense and contains a lot of information. Currently, I work on an illustrated album, which is actually a somewhat stuck project for some years, and your work is a reference for my project. Congratulations!

I have observed that you use the Nomacs image viewer, instead of the default KDE Plasma, Gwenview. Currently, my OS is Manjaro KDE, and Gwenview is very useful when previewing .kra files, and can even manage my monitor profile correctly. However, it seems to ignore the periles embedded in Krita sRGB files. Is Nomac able to do full color management?

link Leo Plaw  

Thank you for putting in all of the hard work to figure this out David. FOSS needs people like you to thoroughly put it through it's paces to figure out the short comings so a profession workflow can be built.

link Pierre Schiller  

I've read it all. Thank you for making it such detailed text. I too come from a print background, so I can relate to all you have to exposed here. Addessing CMYK on pdf generated by open source, I guess it kind of is the "authorship" and technology licencing from 30 years ago. Fortunatelly the audio visual entertainment industry through The Linux Foundation had gotten far as to use open source solutions and formats and profiles. Let's just hope that becomes a reality in printing.

link zeograd  

It's great to see you document the FLOSS way to do professional comic publication.
Do you know which part exactly could the community focus on to improve the process ?

link David Revoy Author,

Hey Zeograd! Thank you.
No idea on what could improve the process. I guess I would feel better if I had the alternative to "Adobe Acrobat Pro"; from what I read on the usual prepress workflow, one does the desktop-publishing work with InDesign, output as PDF then can load the PDF into "Adobe Acrobat Pro" and check if the PDF is perfect (no missing image, good layout, good color profile, compliant with a PDF standard via a box that list all the metadata/tags of the PDF). On FLOSS; Okular (using Poppler in background) is not so far to that. But the "color management" is missing. And only for that bit, I can't tell if color management is missing in Okular, or if Scribus malformed my PDF at output. Without any tool to diagnosis a PDF, I think it will be hard to do serious work. For sure, I'm taking a risk when I'll have to export the 200 pages with Scribus that will weight probably 1GB without being able to see how look my PDF. I'll have to blindly trust in getting a good, perfect, rendering.

link David Revoy Author,

Thank you for the comment. I hope too!

link David Revoy Author,

Thank you. Yes, all this paper-cuts in my article feels so minors compare to what is done so far and the possibilities of this tools. Unfortunately, I know that this is the typical kind of paper-cuts that would rool the eyes of a professional while testing it for the first time. I'm glad I can find a way with workaround but it took a lot of time. I will be happy if it happens one day for my workarounds to be replaced by real features. FLOSS tools are very capable. But a ton of comfort is missing and many bugs are hard to accept in a professional environment. Maybe prepress is an industry where the userbase think the things have to work as in a factory?

link David Revoy Author,

Thank you very much. Yes, I'm using Nomacs; the reason over Gwenview is the compact GUI and the navigation (middle mouse to zoom/pan). For the issue you had about color management with Gwenview and *.kra this is not the fault of Gwenview; Nomacs has the same behavior (they use the same libs underneath). The Krita preview is just a mergedimage.png at the root of the *.kra file (a zip). This PNG is like exactly a RGB 8Bit version of how look the projection of the file on Krita viewport at the moment of saving. It's a projection as pure RGB 8bit, not really the real datas (that can be CMYK/L*a*b/etc...)

link David Revoy Author,

Thank you! Hehe, I'll try to find time to do one or two inked drawing maybe ;)

link Great job!  

You are tracing a new route: hope you reach success and happyness.

link TappedOut  

Is the (missing) color profile the only issue, you know of to work out?

link David Revoy Author,

That's the main issue :) No idea if Scribus will send a PDF without the good color profile embeded or if it is there. I have no tools to tell; and I don't want to buy a copy of Windows with Acrobat Pro just to check. I'll probably try to read the file in a Hex editor and look for the text string.

link Vulphere  

Some interesting technical information there, especially regarding the colour profile and challenges to ensure accurate colour reproduction.

link TappedOut  

Can you crowd-source that to people that do, or does that go against the spirit of your project?

link David Revoy Author,

Good idea, I'll add links to my repositories and suggestion about how to help on next reports.
For sure, I'll open the PDF to the community and source *.sla will get its repository; proofreading the book by fresh eyes is an essential step in this project.

link David Revoy Author,

Thank you!

link saski'o  

I'm excited to hear more about the process for getting prints in other languages once you figure that out, and what the automation will be like.
I'd like to get a copy of the book in zbalermorna once I finish helping out with that translation.

link David Revoy Author,

For sure I'll share all!
Yes, Lojban is on my top list and I spoke with Gleki about it.
I don't know if it means the one with Lojban font, or with the latin characters. But it will be an interesting quest; and a premiere!

link saski'o  

It's the special font. I've been talking with the guy maintaining the font and it looks like it's been moved to a new unicode space. But yes, it'll be very interesting.

link Châu  

Also try hexdump command line tool from terminal

link Doudou  

Wow, ça c'est de la contribution tous azimuts au libre ! Bravo !

link Samuel A Rowan  

I recently discovered your work through Xacur's Kickstarter campaign and hearing that these lovely comics will be printed excites me greatly! I'll be sure to check back often to see when it drops!

link Châu  

PDF is Adobe's dog. I wish can create more modern system use SVG replace PDF. Another good bitmap image format for replace TIFF (another Adobe dog) is OpenEXR but I never see any person use it for print (or CYMK file). It support 16 bit and 32 bit float color for wide dynamic range. OpenEXR format support any channel name.

Probably your printer people also have other software reorganize your book pages, order for one big page have 8 or 16 book page (or other number) for print at one time, then they fold it for cut become book. This software is probably close source. Also final raster software for their printer. Can build full open source system if can get open source printer. Diffusion and screen algorithms is available in graphics research papers.

link David Revoy Author,

Merci :)

link Eric  

I was browsing the Exiftool documentation (like one does on a Wednesday evening) and came across a page ( which describes a way to extract some metadata from embedded images in a PDF document. I haven't tried, but perhaps it can tell whether a color profile is embedded or used by an embedded PDF image.

link David Revoy Author,

Thank you Eric; I'll try and test!

link narayan  

If you're using poppler to inspect the pdf, you van maybe try out pdfium as well?

link David Revoy Author,

I quickly saw this tool while collecting info about Chromium embeded PDF reader and its origin in Apple. I vaguely remember I saw a Gihub project for it but the author had freshly archived it and stop the development; so I thought it was a dead end. Is it still alive and I did a mistake?

link narayan  

Well, LibreOffice started using pdfium one year ago to render their pdf's, so I guess it is well maintained?

link David Revoy Author,

Thanks for the info. It might be. But I'm not sure LibreOffice is really a reference in terms of bug free apps and has any interest into color management and CMYK. (sorry, I'm a big LibreOffice user since ten years, but 'trust', 'reliable', 'profesionnal' wouldn't be part of my vocabulary to describe it). I'll investigate a bit this way for sure.

link narayan  

Hi David, it's a big project with a lot of bugs, but I like the project and the activity around it. We use it in a professional setting as well and it works for our needs. What is your main gripe with it if I may ask?

Anyway, LO certainly isn't creative software, so I guess you'll be right!

link David Revoy Author,

Ha, sorry about my words! I was thinking about the Presentation and the LibreOffice Draw ; the Writer part is totally fine, and I do my bills and account with the Calc part too ("professionaly"). LibreOffice is so gigantic! My gripe: LODraw about having very limited freehand draw tools and no CMYK, also I wish they would join the bright side of the SVG instead the ODG :P For Presentation; I'm jealous about the font effect, smooth shadows, particules and transition the Apple computers propose to their users by default. Each time I do a Presentation in a conference; it looks static, just flipping page. I really wish someone was adding cool transitions and splendid graphical effect so the Linux conf and authors would look way cooler while doing conferences. :P

link David Revoy Author,

Mm... Another notes: when I said Writer is totally fine, that's not totally true: it's fine for my letters and quick three pages scenario ideas (my usage only scratch the surface of it) My wife made two thesis inside Writer; and the database/bibliography things was really painfully buggy. As soon as the amount of pages grows and specific feature are used this type of behavior appears (that's normal, untested territory). It was a rare condition, impossible to find how to replicate on a smaller sample, we haven't reported it.

link narayan  

Ah yes, the reference and bibliography system is quite a mess.. I myself (and others as well) am a proponent of integrating Zotero into LO, bit it all boils down to dev time which is sparse as in any foss project.

Impress is getting some attention lately (they made a dedicated impress team), so fingers crossed it becomes more stable and more feature rich.

link David Revoy Author,

Ha nice, thanks for the news!
I remember a change that was very important to me; when the dual screen thing with Presentation/Impress proposed to see a thumbnail of the next slide, a private text and the hours and duration of the presentation. This really made my work on FLOSS conferences easier.

link Edx  

Nice article, thanks. Just as a note, I was surprised by this myself when choosing CMYK JPG as transfer format: JPG at 100% quality is *NOT* lossless; see an explanation here: . I wish we had a standard CMYK PNG, for example.

link David Revoy Author,

True, that's a mistake and a dangerous shortcut I took while writing that, I made extensive research about JPEG in the past ( old article: ) and I knew that. So sorry and thanks for noticing it. I fixed the sentence by "with a compression as near as possible to lossless for this format (100% quality)" ;

link victor  

Salut David,

j'ai suivi ta voie (Linux Manjaro, Scribus, Krita, Gimp ...).
J'ai ajouté les outils

- aaphoto (ligne de commande) qui va tenter d'équilibrer ton image "au mieux", donc pas de subjectivité ! Voir ce lien

- Cyan (module autonome qui correspond à l'ancien module Separate) qui convertit ton RVB en CMJN (avec sélection d'un profil colorimétrique et une intention de rendu -perceptif, relatif etc-). Voir ce lien

- Une fois dans Scribus, les images ont le bon profil et j'applique un effet de luminosité d'"expérience" (de 10 à 30) à mes images.

J'ai fait des tests en impression à la demande (j'ai donc une référence pour mes qualité d'images) et cela ressort quasiment de la même manière que sur ma jet d'encre (avec un papier photo).
Je fais donc des tests sur celle-ci, essentiellement pour contrôler le caractère contrasté ou saturé des images. L'objectif étant d'obtenir la même chose lors de l'édition de nos bouquins.

En conclusion, il faut passer par le papier avant d'envoyer à l'imprimeur.


A noter que MuPDF sait lire les PDF avec profil CMJN ou RVB et il fait les conversions à la volée. La vue en CMJN (shift/E) reste très moche sur un écran!

link David Revoy Author,

Merci pour ce retour et toutes ces informations.

Post a reply

The comments on this article are archived and unfortunately not yet connected to a dedicated post on Mastodon. Feel free to continue the discussion on the social media of your choice. Link to this post:

You can also quote my account so I'll get a notification.
(eg. on my Mastodon profile.)