BUILD 14/30: Calendar Layout Code Progress

⊕ show captionAbout the Title Picture: Today's progress was scribbling down drawing parameters that would be used for writing the calendar rendering code.

Today's sharepiece is the preparation I'm doing to make custom form generation software for the November Word Counting Calendar I posted yesterday. The goal is to have software draw a calendar for any month of any year using different color palettes, like this 2024 package that was made by hand with digital illustration software:

⊕ show captionFigure 1. Manually-colored calendars from 2024. Tedious and time consuming to make! This is what I want to automate with custom software.

Figuring out the Parameters

To reproduce the original design, I need to parameterize the calendars so they can handle the variable number of weeks in a month. There are potentially up to six different weeks, so it's not possible to have a single overlay that "looks good" to me.

The first step I took was to figure out what some of the parameters for drawing the calendar areas were.

⊕ show captionFigure 2. The original Adobe Illustrator file makes use of global swatches that produce the different color variations. Each PROGRESS summary also has different counts depending on the number of days in the week.

The hardest part is figuring out the layout grid which will be used for rendering both the individual cells and their layout as a whole.

The diagram above just shows the horizontal and vertical grid setup for the cells, but eventually I'll want to have a page grid as well that handles the larger elements like the TITLE and WEEK NAME COLUMNS. There will be a lot of numbers calculated.

After I have the numbers calculated, I can then use them to align elements on a PDF page that's generated by the software. As an example, here's the debug grid that shows the placement of editable fields on an ETP page and year and holiday text fields.

⊕ show captionFigure 3. This example of the ETP shows horizonal and vertical grid lines that are used to align elements. The Word Counting Calendar is more complex because it can't rely on a pre-rendered PDF shell to add elements to; everything has to be rendered from scratch.

Then I had to figure out the data generation to determine the start and end days of the calendar. I had written some code back in January 2024 for this, but it was a mess and I needed to review it. Below you can see the code output showing the calculated data generated from the start date of November 1, 2025.

⊕ show captionFigure 4. Terminal output of my test program to check that the correct calendar data is being generated from a single date. Combining this with the drawing code will yield magical PDFs!

That's as far as I got today. Tomorrow, I'll try to actually draw something onto a PDF. My guess is it will take two or three days, but it will be a significant advance in my product-generating infrastructure!

BUILD CHALLENGE COMMENTARY

It's a bit boring working on this by myself, honestly. I wish there were people doing stuff like this with me. I am a reluctant programmer when working solo without creative energy from others swirling around me. So I'm pacing myself, making a little bit of progress every day so I don't burn out. A little bit of progress is better than no progress.

BONUS ACHIEVEMENTS

I also had to spend a bit of time fixing the Visual Studio Code Intellisense configuration, as it was not catching errors in my code as I typed. This is a mixed-mode codebase consisting both of Typescript and CommonJS files in the server and in the client, so configuration is a bit tricky. I admit I relied ton Claude Code to check things. By combining its general patterns with my debugging insight, we got it done without a lot of frustration. Before such tools, I would have spent hours searching the web for some hint to how the configuration was supposed to work. It's an enormous mess, made even worse today because Google Search is essentially broken now.