fi and ffi and really old tech impacting modern PDFs

Yes, some shit from so long ago impacts things today...

 

Okay. Hi, I had an interesting complaint from a customer today where the document we sent them demanding payment of a direct debit notification had weird errors on it.

Now, we sent them a notification of direct debit collection and a PDF and the PDF when they viewed it when they printed it. So they printed it and scanned it and sent it to us which is you know a lot of effort.

Every digit on that document, the date uh everything and the bank details and so on were all fives. Every digit was a five. And it wasn't even a complete five. It was like a truncated five. It was very messy

And there was also a weird thing where the word notification was notation.

Um, which doesn't make sense.

And this brought me back this brought me back a lot of decades. I mean, I don't know how many decades.

We've got to be talking 45 years, maybe.

My dad had a printing press. 

He's he actually had several over the years, including a big industrial one 

But he had a printing press.

And so he would compose things to print with an uppercase and lower case. And in those days that meant a wooden case of lead type upper and a wooden case of lead type lower.

And it had all of the letters you'd need.

And one of the letters in this was an FI.

Looks like this.

And there was also FFI.

That's not a terribly good example of an FI, but the the point is the FI sort of merged together where the dot over the I became the top of the F as a single lead character.

And that was the thing that that that's what you used.

Now fast forward today, we have.

Now first off just to address the complaint. The direct debit notification has plain text ASCII saying all of the details about the direct debit notification. everything, the amount, the account, the name, everything in plain text. Paper ASCII.

We may go as far as some UTF8 encoding of a pound sign, I think, and that's about as far as we go. But even that would still be readable

But we also add a PDF. And this is just a courtesy. People like this.

The PDF we use by default uses a font which has an alternative character set for the digits. So the digits can either be really fancy different sizes huge descenders weird or unified sort of spacing of the digits.

Now for any accounting purpose you want the digits that are unified spacing. You want digits that line up. And so by default, we use this alternate version of the character set on the font to make the digits line up and most things show it fine. The downside is copy and paste from it tends to be messed up, which is a real shame.

And I'd love to find a way of making that work. And it's all down to go script and god knows what. But anyway, most PDF viewers of the PDFs we send show the characters correctly.

This particular customer, I don't know what they have, but it shows all the alternate digit characters as a five.

So, everything was fives. What can I say? It's mad.

But a clue as to how bad it is is the FI character in the word notification did not show correctly, which gave gave him the wrong spelling, layout, whatever notification

So this just gave a clue of how bad his PDF view is. And what struck me is how this goes back to the days of that lead type, those 45 years ago and how that's impacting something happening in 2026 and that is just unbelievable.

So yeah, happens. Wow.

Crazy.

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.