Category: Machine Shop

The Punched Card.py program can generate a set of test cards to simplify tweaking the rest of the process:

The Bash script calls the Python program twice to generate the two SVG files for printing and punching each card, which seemed simple enough.

Unfortunately, sending the SVG file directly to the printer demonstrated my lack of understanding of that whole process, so the script now:

• Converts the SVG to a PNG file
• Composites the logo image into a first blank-card sized PNG image
• Composites the logo underneath the card PNG to a second PNG
• Composites that PNG onto a Letter page in the proper position to hit a 1/3 Letter blank card to a third PNG

Which goes a little something like this:

#/usr/bin/bash
outdir="Cards/Tests/"
prefix="test"
for i in $(seq 5)
do
    printf "Test pattern %s: print" ${i}
    python Punched\ Card.py --layout print --test $i --seq 0 > ${outdir}test-${i}-pr.svg
    printf ", punch"
    python Punched\ Card.py --lbsvg --layout laser --test $i --seq 0 > ${outdir}test-${i}-lb.svg

    tf1=$(mktemp --suffix=.png ${prefix}-XXXX)
    printf ", Inkscape → PNG"
    inkscape --actions="select-all; page-fit-to-selection; export-dpi:300" --export-filename=$tf1 ${outdir}${prefix}-${i}-pr.svg

    printf ", Imagemagick → logo"
    tf2=$(mktemp --suffix=.png ${prefix}-XXXX)
    magick composite ${outdir}"Card logo.png" -gravity center -geometry "x880+0+20" -size 2421x1004 canvas:white $tf2

    printf ", Imagemagick → page"
    tf3=$(mktemp --suffix=.png ${prefix}-XXXX)
    magick composite $tf1 $tf2 $tf3
    magick composite -density 300 -gravity east -geometry "97.0%x97.9%+100-50" $tf3 -size 3300x2550 canvas:white ${outdir}${prefix}-${i}-lt.png

    #printf ", PNG → printer"
    #lp -d EPSON_ET-3830_Series -o media=TLetter ${outdir}${prefix}-${i}-lt.png

    rm $tf1 $tf2 $tf3
    printf ", done\n"
done

Although the script could print the final PNG for each card as it’s generated, I prefer to print them after eyeballing the results to fix the inevitable bloopers:

lp -d EPSON_ET-3830_Series -o media=TLetter Cards/Tests/test-?-lt.png

Using ImageMagick to slam PNG images around was significantly less complex and more direct than trying to contort the SVG file to produce the same result. In particular:

• Uniformly scaling the logo image to fit the card height actually worked, as opposed to specifying the logo file as an image in SVG file.
• Scaling the card PNG while compositing it onto the final page PNG worked much consistently, which counts for a lot.
• Hitting the middle of a 1/3 Letter blank fed from the printer’s paper tray required tedious trial-and-error.

The Cards/Tests/ output directory lives in the Programs directory with the Bash and Python programs, which made sense at the time.

The Card logo.png file also lives in Cards/Tests/ so I can have a different logo for each set of cards. A symlink to the appropriate logo file in Logos simplifies changing the artwork.

None of the constants will match your setup, so have fun.

With a fixture aligning a printed card in the laser for cutting and trays for incoming and outgoing cards, it’s time to generate SVGs for printing and cutting. I use the svg.py library to translate card geometry into SVG elements.

For example, this draws a rectangle around the card perimeter with a color that will automagically put it on a LightBurn tool layer used for alignment:

if args.layout == "laser":
    ToolEls.append(
        svg.Rect(
            x=0,
            y=0,
            width=svg.mm(CardSize[X]),
            height=svg.mm(CardSize[Y]),
            stroke=Tooling,
            stroke_width=svg.mm(DefStroke),
            fill="none",
        )
    )

Because I know the exact size of the card layout, all the coordinates / sizes / widths will be in hard millimeters. The constant INCH converts from the hard inch sizes of the OG IBM card layout.

The args.layout variable corresponds to a command-line switch selecting output for either “print” or “laser”, because each requires different SVG elements and attributes. In this case, the card outline appears only in the laser file, because it should not be printed on the card face.

Eventually, the SVG for the laser will look like this, with the blue rectangle boxing its red perimeter:

The corresponding SVG to be printed, without the rectangle:

Both SVGs have four alignment targets at exactly the same coordinates, although in different colors for their different purposes. The laser targets appear on a tool layer where they can be selected to position the laser head over the corresponding printed targets on the card in the fixture:

Subsequent steps in the process composite the fancy logo under the SVG layout and scale the result before printing the card.

This chunk of code produces those targets:

for c in ((1,1),(-1,1),(-1,-1),(1,-1)):
    ctr = (CardSize[X]/2 + c[X]*TargetOC[X]/2,CardSize[Y]/2 + c[Y]*TargetOC[Y]/2)
    MarkEls.append(
        svg.Circle(
            cx=svg.mm(ctr[X]),
            cy=svg.mm(ctr[Y]),
            r=svg.mm(TargetOD/2),
            stroke=Tooling if args.layout == "laser" else CardMark,
            stroke_width=svg.mm(DefStroke),
            fill="none",
        )
    )
    MarkEls.append(
        svg.Path(
            d=[
                svg.M(ctr[X] + TargetOD/2,ctr[Y] - TargetOD/2),
                svg.l(-TargetOD,TargetOD),
                svg.m(0,-TargetOD),
                svg.l(TargetOD,TargetOD),
            ],
            transform="scale(" + repr(1.0 if args.lbsvg else SVGSCALE) + ")",
            stroke=Tooling if args.layout == "laser" else CardMark,
            stroke_width=svg.mm(DefStroke if args.lbsvg else DefStroke/SVGSCALE),
            fill="none",
        )
    )

The stroke attribute sets the color of the result, with the Python ternary operator picking the appropriate RGB value based on args.layout.

The args.lbsvg variable comes into play when the LightBurn interpretation of an SVG attribute or element differs from the Inkscape interpretation. I have absolutely no idea what’s going on in those situations, other than that the two programs sometimes regard coordinates / distances differently.

For example, LightBurn regards the “user units” in a Path as millimeters and Inkscape regards them as “SVG pixels” requiring a scale factor I defined as SVGSCALE = 96.0/25.4 to get the right size. If there’s a less awful way to match them, I’m all eyes.

Although setting args.layout to “laser” and args.lbsvg to True generally makes sense, I may want to print the “laser” layout for cross-checking. Hilarity generally ensues until I remember args.lbsvg. It’s worth noting the code has zero error checking, so hilarity generally continues until I fix whatever got missed.

With that in mind, this Path traces the card perimeter:

if args.layout == "laser":
    CardEls.append(
        svg.Path(
            d=[
                svg.M(0.25*INCH,0),
                svg.h(CardSize[X] - 2*0.25*INCH),
                svg.a(0.250*INCH,0.25*INCH,0,0,1,0.25*INCH,0.25*INCH),
                svg.v(CardSize[Y] - 2*0.25*INCH),
                svg.a(0.25*INCH,0.25*INCH,0,0,1,-0.25*INCH,0.25*INCH),
                svg.H(0.25*INCH),
                svg.a(0.25*INCH,0.25*INCH,0,0,1,-0.25*INCH,-0.25*INCH),
                svg.V(0.25*INCH/math.tan(math.radians(30))),
                svg.Z(),
            ],
            transform="scale(" + repr(1.0 if args.lbsvg else SVGSCALE) + ")",
            stroke=CardCut if args.layout == "laser" else Tooling,
            stroke_width=svg.mm(DefStroke if args.lbsvg else DefStroke/SVGSCALE),
            fill="none",
        ),
    )

Note that the stroke_width attribute also requires scaling, lest it take on a broad-brush aspect.

More on generating the various characters and punching the holes to come …

The Python source code as a GitHub Gist:

I derive a modest satisfaction from knowing Microsoft (which owns GitHub) uses my source code to train their Copilot LLM. Future generations of vibe coders will look at their programs and wonder WTF just happened.

Keeping stacks of punched cards under control is important for orderly production:

The two on the left fit finished cards and the larger ones fit 1/3 Letter paper raw cards.

The patterns come from boxes.py:

• Large trays
• Small trays

I added a finger slot behind the front opening so I could pick up the whole stack at once:

Admittedly, my “stacks” are nothing compared to the Bad Old Days, but …

The program adds a sequence number in columns 73-80 as a last-ditch effort to ensure the punch pattern matches the print pattern: after a few dozen cards, the digits in the last few columns become recognizable.

The LightBurn SVG layout as a GitHub Gist:

For reasons I cannot divulge at the moment, I have undertaken a project requiring Old School punched cards, although they will never be fed through a card reader. Because we live in the future, punched cards are no longer a cheap and readily available resource; I will always deeply regret trashing an entire box back in the day.

However, living in the future does confer some advantages:

The process involves a vast number of moving parts, not all of which I fully understand, but I can (generally) produce consistent results and that must suffice. This post is an overview; I will go into the moving parts in more detail so I can remember why I did what I did.

A Python program converts a line of text into an SVG file that contains either the card’s printable contents or the paths required to cut its holes & perimeter. A handful of command-line switches determines the outcome, so you run the program twice with different switches for each line of text to get a matched pair of SVG files.

A Bash script read a text file and hands each line to the Python program, producing two SVG files for each card. It then invokes Inkscape to convert the printable SVG into a PNG image, uses Imagemagic to composite the logo behind the card contents & scale the result to make my printer’s output match the laser’s dead-on positioning, then properly position the card image in a Letter-size PNG image that’s apparently the only way to print it accurately on a punched card:

That’s not full size.

N.B.: there’s no such thing as a blank card that will be punched later, because the printed card includes the text across the top. The program also suppresses the row digits where a punch will appear, thus making slight misalignments less painful and mismatched SVG files more obvious.

Print all the card images on precut 1/3 Letter size sheets of heavy cardstock:

Yes, the printing on the middle card is slightly skewed with respect to the precut card blank. The overall process must handle about two millimeters of positioning inaccuracy and whatever angular skew comes from the printer’s paper feed rollers / guides.

A DOS Windows BAT file feeds the SVG files with the holes & outline paths to LightBurn, one by one. No lie.

Put each printed card in a fixture and align its targets, whereupon LightBurn evaporates the holes and cuts the outline:

In my somewhat biased opinion, the results look good:

The Python program also produces cards with test patterns useful for wringing out the process:

“Punching” a lace card is no problem and, given an all-blank text line, the result looks like a blank card:

If you happen to have a card punch, be my guest.

The source text for the cards comes from the Apollo Guidance Computer in the Apollo 11 Command Module, via an amazing GitHub repository. You can run a virtual AGC in the privacy & comfort of your own home.

Useful links:

• The KEYPUNCH029 dot font: thank you scruss!
• Punched card codes, of which I used EBCDIC, from a heroic collection of punched card information
• Baffling Inkscape command line doc
• Imagemagick command line options doc
• SVG doc from Mozilla
• svg.py library for making SVG files
• Python library doc
• Another punched card generator