US Letter or A4 in the Calendar Maker: What the Paper Setting Changes, and What the Import Refuses

I work on OnePassApps, so this is our own app - every number below came out of the live build at app.onepassapps.com/apps/calendar-maker on 7 November 2026, in one signed-out browser session.

The Calendar Maker is the app in our suite that prints a year, a set of month pages or a weekly planner. My earlier post here covered the page counts, the events and the JSON export, and it said one thing plainly: it never changed the Paper or Orientation controls, so every count in it was the A4 landscape default. This post is that gap, and the other end of the same file - what the app does with a setup file you hand it.

Try it yourself: the Calendar Maker or read the guide for it.

The paper setting changes the label, not the count

The panel opens in the Months layout with the two selectors reading Paper size: A4 and Orientation: Landscape. The preview header above the sheet reads A4 · landscape · 12 pages, and the pager underneath reads Page 1 of 12.

Change the paper to US Letter and the header becomes US Letter · landscape · 12 pages. Change the orientation to Portrait and it becomes US Letter · portrait · 12 pages.

The number never moved. Twelve pages before, twelve pages after, in both cases.

That is not a rounding detail, it is where the page count comes from. The guide puts it plainly: "Years run from 1900 to 2200. A print holds one year page, up to 24 monthly pages or up to 53 weekly pages, with up to 200 events of up to 60 characters each." The count follows the layout and its count field, not the sheet you are going to print on. So moving to US Letter does not give you more months or fewer - it changes the paper the printer is asked for and leaves the calendar itself alone.

One note on how this was driven, because it matters for what you can conclude. The two selectors are dropdown lists, and their option list would not open under automation in this session, so I set the value through the same hidden input the control itself writes to and fired its input and change events. The app reacted to that exactly as it reacts to a click - the visible label changed to "US Letter" and then "Portrait", the preview header followed, and the export wrote the new values - but what I am reporting is what the app does with the value, not a recorded human click on an option.

What the export writes

Pressing Export setup JSON writes a file named calendar-month-2026-01.json. The browser adds a (1), (2) suffix when a file with that name is already in the download folder, so the two files I exported in this session landed as calendar-month-2026-01 (3).json and calendar-month-2026-01 (4).json. I read both back off disk. They are 331 bytes and 334 bytes, and they differ in exactly two lines:

<     "paper": "a4",
<     "orientation": "landscape",
---
>     "paper": "letter",
>     "orientation": "portrait",

The SHA-256 of the first is ddef15b47c559a2348601fc6bb1bedd63717edc9dced5764c1921597ea305d88 and of the second 9c24b5a3fc0d6d70bd3084fe5b03de8e46f9e3dbe178864b55e081253477dcb4. Three more bytes, because "letter" is longer than "a4" and "portrait" is shorter than "landscape".

Everything else in the file was the same in both: app "calendar-maker", version 1, layout "month", startYear 2026, startMonth 1, weekStart "monday", weekNumbers false, title "", notes true, monthCount 12, weekCount 52, and an empty events list.

The panel states the storage rule itself: "Nothing is saved automatically. Export the setup and events as JSON to keep them." The guide adds why that matters - "Reloading clears the calendar unless you export the setup."

Four files the import refuses

The other control is Import setup JSON, backed by a file picker that accepts .json,application/json. I wrote five files for this post and fed each one to that control. Four were refused, and every refusal named a different reason, followed by the same second line:

what was wrong with the file	the panel said
paper set to a3	"The file has an unsupported paper size."
orientation set to sideways	"The file has an unsupported orientation."
app set to word-counter	"That file is not a Calendar Maker setup."
the JSON cut off mid-word	"That file is not valid JSON."

All four then read: "Import failed. Your current calendar was kept." The calendar on screen was unchanged after each one - still Months, still January 2026, still 12 pages.

Two things are worth pulling out of that table. The paper and the orientation are checked against the values the app itself offers, so a file carrying a made-up paper size or orientation is turned away before anything else happens. And the app field is checked as an identity, not just as a container: a perfectly well-formed setup with "app": "word-counter" in it is not a Calendar Maker setup, and the app says so in those words.

The valid file is the one that did not go in

The fifth file was the app's own shape - app "calendar-maker", version 1, a full settings block with paper "letter", orientation "portrait", layout "month" and startYear 2027 - and it was the one that did not come back in.

The panel answered: "Cancelled. Your calendar was kept." No settings changed: still Months, still January, still 2026, still the 12 pages it had before.

I checked what that message was before writing a word about it. A JavaScript dialog handler was attached to the page for the whole session and never fired, so no window.confirm was involved. No dialog element and no confirmation button appeared in the DOM when I looked, and the set of visible buttons was the same before and after the import, including Export setup JSON, Import setup JSON and Print / save PDF. So whatever step declined the import, it was not a dialog I could see or answer.

Which means I did not complete the round trip and I am not claiming one. I handed the app a valid setup file and the app did not apply it.

What the app says about the cost of all this

The panel's own line about printing is the one worth keeping: "Your browser’s print dialog sets the final scale and margins. Choose “Actual size” or 100% so the page fits the paper, and Save as PDF to keep a copy." The guide says the same thing from its side - "Print scaling and margins depend on your printer and browser, so print at 100% or Actual size."

And the money line, which for this app is short: "Calendar Maker runs in your browser with no account or payment details, and it never uses OnePassApps credits."

Limits of this measurement

One build, one browser, one signed-out session, 7 November 2026.

• The Paper and Orientation values were set through the control's own hidden input because the dropdown list would not open under automation, so this reports the app's reaction to the value rather than a hand-clicked option.
• The app's own Print / save PDF button was never pressed and the browser print dialog was never opened, so nothing here claims what a printed sheet looks like at US Letter portrait.
• The import round trip was not completed - the valid file ended at "Cancelled. Your calendar was kept." and no settings changed.
• The file was set through the browser's file control from outside the picker dialog rather than by choosing it in a person's file dialog.
• No events were added, so both exported files carry an empty events list.
• The page count was compared in the Months layout only; I did not read the page count back in the Weeks layout with US Letter portrait.