I thought PDF solved this crap

This is all about the tools used, and how they maybe don't quite fit together sometimes.

I have been working with the people at Ivory Graphics, as you may know. Having done a few things with them I am now quite good and making the artwork in the right format for them.

Little things like, if I have a pack of cards, making it a single multi-page PDF is better for them than separate files for each card. It also ensures they know the order I want the cards to be in, which can be nice. Another small detail is interleaving the face and back of the cards in the PDF - this is crucial for a marked deck or a deck that has stuff separately on both sides of the cards for example, but they do have macros which will take one "back" and slot it in to a deck as well.

But how do I make the artwork?

Well, I start with SVG. In fact, for the card faces, I have SVG and C code, and the C code has some SVG in it (like shapes of the suits and digits), some it constructs with code, and some it pulls in from files (like the various layers of court card artwork) which I originally edited in inkscape, and it constructs final SVGs.

However, for the box designs I have used inkscape to create and edit. The original PDF from Ivory (they have templates on their web site) is imported in to inkscape, and split in to layers to allow me to make a design. In some cases I have then imported symbols and whole playing cards from my generated SVG. It works well.

I then have scripts which use inkscape command line to export PDFs and then pdfunite to make multiple page PDFs with card backs in the right order. I do the same for the box, making one PDF which has all of the cut and fold outlines for reference and one that does not, ready for printing. I view the PDFs either in Safari or using Preview on my Mac.

Here is the latest deluxe Stargate box design as an example. I exported as PNG from Preview:

I can, of course, view the SVG for this in Safari too, works well, except that the gate symbols at the top do not show! This is because they use SVG "symbols", which seem to not to always work in Safari for no good reason. In other cases they work fine, so really not clear. Also, bizarrely (having just checked this to make sure I was right) Safari has stopped using the fonts in the SVG (that are loaded on this Mac) so it actually looks very wrong indeed! That used to work, so I'll have to figure out why it is not (I did update my MacOS the other day). This is a screenshot from Safari on my Mac:

Anyway, the final product is PDF format, albeit using RGB colour space. Ivory Graphics cope very well with converting to CMYK for print, I have to say, so that has not been an issue.

PDFs "just work" as you probably know. They embed fonts as needed, and they are a consistent format, and I have never had any problem with PDFs, honest. Seriously, it is impressive - so many other formats for things, even (as you see above) SVGs, are not reliable, but PDFs just work. So it is very sensible of Ivory Graphics to prefer PDF as the means to send them artwork.

But, to my surprise, this is not always the case. It seems that the Stargate on the box causes problems, and it is not clear why. The same Stargate on the card backs was no problem! Loading the PDF broke horribly for them with bits missing in all sorts of places. The comment was "And when I attempt to crop it, other sections drop off.". This example is the previous version on a white background, but you can see the cards are broken badly, and bits of the gate are a mess. What on Earth is going wrong?

This was, I believe, loading in to Adobe Illustrator. To fix that she did something involving Photoshop and then Illustrator, and probably something else, and managed to sort it. But this time she failed, and different ways of loading caused error of not recognising a shading or getting colours wrong. She spent time creating new shading even but was not entirely happy with it.

I am really surprised by this to be honest, PDFs really should "just work".

However, there was a fix, which I stumbled upon, and it "worked perfectly" allowing the PDF to just import with no problems. The alternative was to make a raster PNG which would work, but can lose detail.

What did I do? I opened in "Preview" on the Mac, and did Export PDF from it. The result was on the wrong page size, and even rotated, and a different (smaller) file size, but still properly vector graphics, and apparently loaded with no problem in to Illustrator and whatever other tools she is using. The proofs she then produced just looked spot on, and no problems at all.

Unfortunately we live in a world where we are removed from the nuts and bolts of such file formats enough that you have to basically play around at a high level until something seems to work. It is a shame really, and not a situation I like. Whilst I have good understanding of Postscript and SVG (and PNG), I don't when it comes to PDFs. Someone that does could probably explain what inkscape did that was special in some way that it sometimes breaks Illustrator but not breaking Preview.

Just goes to show that some times the simplest solutions work best, and a useful tip for next time. And well done to Zsuzsa from Ivory for her hard work on this. It is nice dealing with a company that really do try to get things right.

Printing, and microscopes!

I got a small £15 USB microscope off Amazon, as you do. Great fun, but there was a practical reason.

I have been trying to work out the logic of the printing from my Mac to a Brother QL-700 printer. I have this sussed when it comes to using linux (finally) with a lot of careful arguments to ghostscript and inkscape to take my initial SVGs and print them with no dithering. That is working well. But I am trying to work out how to print from a Mac when printing something that is fussy, like a bar code.

Printing PDFs

The most obvious choice was to make a PDF. I had carefully made the barcodes in the PDF to the exact print resolution of 300 dpi. Everything was vector based. On screen it is perfectly crisp and clear.

However, the printing from the Mac constantly insisted on scaling to fit page. Even when I put 100% scale the printing was not spot on, and did not read very well, if at all. In fact it was slightly better printed at 101%. This is silly.

Printing PNGs

So I tried PNGs. The good news is that by default, where the PNG has a resolution set, it defaults to print at 100% and seems to have the sense to align pixels well. I thought my problems were solved, and to the naked eye, the QR codes looked fine.

But I decided to check, which is where the microscope comes in!

I generated a PNG with a QR code at 100dpi with one PNG pixel per QR code unit/pixel.

This was the result!

As you can see, there are bits sticking out all over the place. It took me a while to work out what was happening! Basically, something in the process has decided to soften the edges of the pixels, and then something has decided to dither the greys that are then produced. Even tinkering with the dither settings I could not make it stop doing this. Surprisingly it does read, usually. (Yes, I also bought a 2D barcode reader from Amazon).

However, one small change makes it massively better. By making a PNG at 300dpi, and using 3x3 PNG pixels per QR unit/pixel I get this!

No bits sticking out. It is not quite perfect, but that may be the printer - it seems to bleed on the trailing edge of printing making all black slightly wider. I may be able to do something to compensate for that. This reads much more reliably than the previous one.

However, making a 600dpi image and 6x6 pixels did not help - it created anti-aliasing greys which dithered, though not as bad... If I was able to align this properly it would probably work as well.

So, the moral of the story is to make PNGs that match exactly the printer resolution, and ensure you have way more than 1x1 pixels for the bar code units. For this printer I would say at least 3 print pixels per unit.

P.S. linux pdfinfo command shows resolution in DPI and then has "(pixels per meter)" which is very confusing.