REM2PS(1)

🎀 REM2PS(1) — rem2ps — VERSION 06.02.07 🎀

Bestie, welcome to the rem2ps manual page. Version is 06.02.07, the vibe is PostScript calendar realness, and we are keeping every single detail. 💖

💖 NAME 💖

rem2ps — draw a PostScript calendar from Remind output. That’s the whole gig: Remind gives you the data, rem2ps turns it into a calendar in PostScript. Slay. ✨

🦋 SYNOPSIS 🦋

rem2ps [options]

🌸 DESCRIPTION 🌸

rem2ps reads the standard input, which should be the results of running Remind with the -p or -pp option. It emits PostScript code (which draws a calendar) to the standard output. Literally the glow-up from reminder text to printable calendar. 💅

Although rem2ps will be maintained, no new features will be added to it. Instead, all new development will continue on rem2pdf. So this icon is staying cute, but it’s not getting new tricks. Periodt.

See the section "REM2PS INPUT FORMAT" for details about the -p data. This may be useful if you wish to create other Remind back-ends. Ngl, that’s kind of a serve for anyone building their own little Remind situation. 🫶

Note that rem2ps does not handle UTF-8 input. If you need to render characters outside the ASCII character set, see rem2pdf instead. This is important, bestie — outside ASCII means you need the other tool. 😭

✨ OPTIONS ✨

• --version — Print the version of rem2ps and exit. Short and iconic.
• -v — Be more verbose. This causes rem2ps to print progress messages to the standard error stream. Normally, it is silent. So -v is the “tell me what’s happening” era. 👑
• -p file — Include the contents of file in the PostScript prologue. This allows you to define procedures, variables etc. which can be used by the PS and PSFILE reminders. You should not include any document structuring comments in your prologue. Lowkey important: prologue yes, document structuring comments no. 🚫
• -l — Produce the calendar in landscape mode rather than the default portrait mode. Rotate the whole situation, bestie. 🌈
• -x — When printing the calendar, place the day numbers in the top-left of each day’s box. If this option is omitted, the day numbers appear in the top-right. Tiny placement, big energy. 💫
• -c[n] — If n is omitted, disables the small calendars for next and previous months which are normally generated. If n is supplied, it can range from 0 to 3, with the following meanings:
  • 0 — Disable small calendars.
  • 1 — Place the small calendars at the bottom-right if there is room; otherwise, place them at the top-left.
  • 2 — Place the small calendars at the top-left if there is room; otherwise, place them at the bottom-right.
  • 3 — Place the previous month’s small calendar at the top-left and the next month’s at the bottom-right if there is room; otherwise, follow n=1. A moment’s thought reveals that an option which splits the calendars if there is room and otherwise follows n=2 yields the same results as n=3.
• -i — Use ISO 8859-1 standard encoding for the PostScript fonts. If you do not use this option, the default encoding is used. If you use this option, you probably also need to convert Remind’s output (typically UTF-8) to ISO-8859-1 using iconv(1). That’s the encoding lore. 🧚
• -e — Make the calendar fill the entire page. By default, the calendar is slightly smaller than the page. This allows days with many reminders to "expand" as needed. However, if you don’t have days which expand, you can use this option to make all of the boxes slightly bigger. One caveat: If you do use the -e option and one day has many reminders, the calendar may expand off the page, losing some information. Experiment! ⚠️ This is the “go big but check your edges” option.
• -m media — Set the page size. If you use the -m option, you must specify the media type, which can be one of the following. (Sizes are approximate.)
  • Letter — 8.5 x 11 in.
  • Legal — 8.5 x 14 in.
  • Ledger — 11 x 17 in.
  • Statement — 5.5 x 8.5 in.
  • Executive — 7.5 x 10 in.
  • A3 — 29.7 x 42 cm.
  • A4 — 21 x 29.7 cm.
  • A5 — 14.8 x 21 cm.
  • B4 — 25.7 x 36.4 cm.
  • B5 — 18.3 x 25.7 cm.
  • Folio — 8.5 x 13 in.
  • Quarto — 8.5 x 10.8 in.
  • 10x14 — 10 x 14 in.
  • XxYin — X by Y inches, where X and Y can be floating-point numbers.
  • XxYcm — X by Y centimetres, where X and Y can be floating-point numbers.

Type rem2ps -m help for a list of available media. Note that the media type (and all rem2ps options) are case-sensitive. If you don’t use the -m option, the media defaults to a compiled-in default — this is usually Letter for North America and A4 for Europe. The -m help option will display the compiled-in default. 🎀

• -f[tshed] font — Set the font for the calendar title, the small calendars, the day-of-week headings, the calendar entries, and the day numbers, respectively. Font must be the name of a valid PostScript font. The default fonts are equivalent to specifying:

-ftshe Helvetica -fd Helvetica-BoldOblique

In other words, the heading, entry and small-calendar fonts are set to Helvetica, and the font for the day numbers is set to Helvetica-BoldOblique. Font choices are a whole personality, fr fr. 💅

• -s[thed] size — Set the size (in points) of the text for the calendar title, day-of-week headings, the calendar entries, and the day numbers, respectively. Size must be a decimal number. The default sizes are equivalent to specifying:

-sthd 14 -se 8

In other words, the heading and day numbers are 14-point fonts, and the calendar entries are printed in 8-point text. Tiny entries, big heading energy. ✨

• -b size — Set the size of the blank white border in each calendar box to size points. The default border size is 6 points, or 1/12 in. That’s the breathing room between the grid and the content. 🫧
• -t size — Set the thickness of the black calendar grid lines. The default is 1, for a line thickness of one point (1/72 in.). Grid lines stay iconic. 🖤
• -o[lrtb] size — Set the left, right, top, and/or bottom margins to size points. For this option only, size must be an integer. It represents the margin size in units of 1/72 in. The default margin sizes are 36, for half-inch margins. If you wish to punch holes in the calendar page to insert it into a binder, you may wish to increase the left margin to one inch. In that case, you should also decrease the heading font size to 12 points for good output:

# This gives good results for putting into a binder
rem2ps -ol 72 -sh 12

🌈 USAGE 🌈

To use rem2ps, you should pipe the output of Remind with the -p option to rem2ps, and then send the result to a printer. This is most easily illustrated with examples:

remind -p12 /dev/null 1 jan 1994 | rem2ps | lpr -Plaser

That example creates a blank calendar for the entire year of 1994, and sends it to the printer named "laser."

remind -p ~/.reminders | rem2ps -l -sd 18 > cal.ps

This reminder creates a calendar for the current month, filling in entries from the reminder file "~/.reminders." The calendar is produced in landscape mode, with a font size of 18 for the day numbers. The result is put in the PostScript file "cal.ps." Cute, functional, and printer-ready. 🖨️💖

🧚 VARIABLES AVAILABLE TO USER-SUPPLIED POSTSCRIPT CODE 🧚

The following variables are available to PS and PSFILE-type reminders. (This material is duplicated in the Remind manual page.)

• LineWidth — The width of the black grid lines making up the calendar.
• Border — The border between the center of the grid lines and the space used to print calendar entries. This border is normally blank space.
• BoxWidth and BoxHeight — The width and height of the calendar box, from center-to-center of the black grid lines.
• InBoxHeight — The height from the center of the bottom black grid line to the top of the regular calendar entry area. The space from here to the top of the box is used only to draw the day number.
• /DayFont, /TitleFont, /EntryFont, /SmallFont and /HeadFont — The fonts used to draw the day numbers, the month and year title, the calendar entries, the small calendars, and the day-of-week headings, respectively.
• DaySize, TitleSize, EntrySize and HeadSize — The sizes of the above fonts. (The size of the small calendar font is not defined here.) For example, if you wanted to print the Hebrew date next to the regular day number in the calendar, use:

REM PS Border BoxHeight Border sub DaySize sub moveto \
   /DayFont findfont DaySize scalefont setfont \
   ([hebday(today())] [hebmon(today())]) show

Note how /DayFont and DaySize are used. That’s the little detail that makes it work, bestie. 🔥

Note that if you supply PostScript code, it is possible to produce invalid PostScript files. Always test your PostScript thoroughly with a PostScript viewer before sending it to the printer. You should not use any document structuring comments in your PostScript code. ⚠️ This is the “test before you print” warning, and it is not a drill.

In addition, prior to drawing a calendar page, rem2ps emits the following PostScript code:

save (mon) (yr) PreCal restore

where mon and yr are the month and year of the calendar page. The default PreCal procedure simply pops the arguments and does nothing. However, you can define a PreCal function in your prologue file to do whatever you want — it can draw a background for the entire calendar, for instance. Main character energy for your calendar background. 👑

In the context of the PreCal procedure, the following conditions hold:

• The PostScript origin is at the bottom left-hand corner of the page, and PostScript units of 1/72 inch are in effect.
• The variables MinX, MinY, MaxX and MaxY define the bounding box within which the calendar will be drawn.
• The font and font-size variables, as well as Border and LineWidth described previously, are valid.

For an example, create a file called "myprolog" whose contents are:

/PreCal {
 /yr exch def
 /mon exch def
 /xsiz1 MaxX MinX sub def
 /ysiz1 MaxY MinY sub def
 /xsiz xsiz1 MinX sub MinX sub def
 /ysiz ysiz1 MinY sub MinY sub def
 xsiz
 ysiz
 lt
 {/len xsiz 1.41 mul def
  MinX MinX add ysiz1 xsiz1 sub 2 div MinY add MinY add moveto}
 {/len ysiz 1.41 mul def
  xsiz1 ysiz1 sub 2 div MinX add MinX add MinY MinY add moveto}
 ifelse
 /Helvetica-Bold findfont 1 scalefont setfont
 mon stringwidth pop
 ( ) stringwidth pop add
 yr stringwidth pop add
 len exch div /len exch def
 /Helvetica-Bold findfont len scalefont setfont
 0.95 setgray
 45 rotate
 mon show
 ( ) show
 yr show
} bind def

Use that file with the rem2ps -p option to create calendars with the year and month in large gray letters in the background of the calendar. 🦋

💅 REM2PS INPUT FORMAT (-P OPTION) 💅

Okay bestie, so the -p option is the older, simpler interchange format Remind uses to communicate with back-ends. New back-ends are encouraged to support the new -pp format preferably, though they’re also encouraged to support the older -p format if the older format contains enough information for them to work properly. ✨

Remind -p sends the following lines to standard output. The info is designed to be easily parsed by back-end programs:

• # translations — this line signifies that the next line will be the translation table. The line following # translations is a JSON object (on a single line) containing all of the entries of the translation table. Back-ends that aren’t interested in the translation table can simply read and discard the next line. If Remind sends data for multiple months, then only the first month will include the translation table.
• # rem2ps begin — this line signifies the start of calendar data. Back-ends can search for it to verify they’re being fed correct information.
• month_name year num_days first_day monday_first — on this line, month_name is the name of the month whose calendar information is about to follow. num_days is the number of days in this month. first_day is the weekday of the first day of the month (0 = Sunday, 1 = Monday, 6 = Saturday.) And monday_first is 1 if the -m flag was supplied to Remind, or 0 if it was not. All this information is supplied so back-ends don’t need any date calculation facilities.

Note that all spaces in month_name will be replaced with underscores. Back-ends should undo this replacement. 🫶

• sun mon tue wed thu fri sat — this line consists of space-separated names of days in whatever language Remind was compiled for. This information can be used by back-ends to annotate calendars, and means they don’t have to be created for a specific language.

Note that all spaces in day names will be replaced with underscores. Back-ends should undo this replacement. 🌸

• next_mon next_days — the name of the next month and the number of days in it.
• prev_mon prev_days — the name of the previous month and the number of days in it. The next_mon and prev_mon lines could be used to generate small inset calendars for the next and previous months. 🎀

The remaining data consists of calendar entries, in the following format:

yyyy/mm/dd special tag dur time body

Here, yyyy is the year, mm is the month (01-12) and dd is the day of the month. Note that the date components are always separated by / even if the date separator in Remind has been set to -. The consistent use of / is designed to ease parsing. 💅

special is a string used for “out-of-band” communication with back-ends. If the reminder is a normal reminder, special is *. The rem2ps back-end understands the specials PostScript and PSFile. Other back-ends may understand other specials. A back end should silently ignore a reminder with a special it doesn’t understand.

tag is whatever tag the user provided with the TAG clause, or * if no tag was provided. If there is more than one TAG clause, the tags appear in a comma-separated list. For example, the command REM TAG foo TAG bar TAG quux would result in foo,bar,quux in the tag field.

dur is the DURATION value in minutes, or * if no duration was provided.

time is the time of the reminder in minutes past midnight, or * if the reminder was not a timed reminder.

body is the body of the reminder.

Future versions of Remind may add additional keys to the JSON object. Back-ends must ignore keys they don’t recognize.

After a month’s worth of reminders have been emitted, Remind emits the line:

# rem2ps end

However, back-ends should keep reading until EOF in case more data for subsequent months is forthcoming. 😭

If you supply the -l option to remind, then reminders may be preceded by a line that looks like this:

# fileinfo lineno filename

The word fileinfo is literal; lineno and filename specify the line number and file name of the file containing the reminder. Back-ends that don’t care about this information should ignore lines starting with # (except, of course, for the # rem2ps lines.) 🦋

💅 REM2PS PARTIAL JSON INPUT FORMAT (-PP OPTION) 💅

okay so bestie, when you hit up remind -pp, it sends the following lines to standard output. And like — they're designed to be easily parsed, but plot twist: they carry so much more info than the old-style remind -p output. The extra info contains a whole representation of the parsed REM statement, which lowkey means converters can actually preserve the semantics of a reminder properly. For example (and this is genuinely iconic), this format passes enough info that a back-end can — in many cases, no promises — figure out a reminder's recurrence instead of treating every single reminder like some one-off event. 💖

The lines emitted by remind -pp are as follows, bestie:

• # translations — this line is basically a heads-up that the next line is gonna be the translation table. And the line right after it? A JSON object (all on a single line, yes) containing every entry of the translation table. Back-ends that aren't interested in the translation table can simply read and discard. Also important: if Remind is sending data for multiple months, then only the first month will include the translation table. 🫶
• # rem2ps2 begin — this line signifies the start of calendar data. Back-ends can search for it to verify they're being fed correct information. And note the "2" after "rem2ps" — that's what distinguishes this format from the older -p format. iykyk.
• month_name year num_days first_day monday_first — Same as the -p format.
• sun mon tue wed thu fri sat — Same as the -p format.
• next_mon next_days — Same as the -p format.
• prev_mon prev_days — Same as the -p format.

---

🎀 CALENDAR ENTRIES 🎀

The remaining data consists of calendar entries expressed as a JSON object on a single line. Each such line will begin with { and will be a well-formed JSON object. No cap. The keys that may be present in the JSON object are as follows:

• date YYYY-MM-DD — the date key will always be present. It's the trigger date of the reminder, expressed as a string in the format YYYY-MM-DD.
• filename f — the filename in which the reminder was found.
• lineno n — the line number within the file on which the reminder was found.
• lineno_start n — okay so if a reminder spans multiple lines because of backslash line-continuation, then the lineno entry is the last line of the reminder, and the lineno_start entry is the first line. But if a reminder doesn't span multiple lines? Then only the lineno entry is present, and lineno_start is simply absent. 💅
• nonconst_expr 1 — if the reminder contained a non-constant expression that had to be evaluated to determine the trigger date, this key will be present with the value 1. And ⚠️ if this key is present, then it is unsafe for a back-end to rely on recurrence semantics or even the semantics of any part of the parsed reminder, because they may have been computed in a way that cannot be expressed in JSON.
• if_depth n — if the reminder is inside one or more IF or ELSE statements, this key will be present and the value will be the number of nested IFs from the top-level down to the reminder. Back-ends should be wary of interpreting recurrence semantics of reminders within an IF or ELSE block. 🙈
• passthru special — if the reminder was a SPECIAL reminder, the passthru key will be present and the value will be the type of SPECIAL (such as SHADE, COLOR, MOON, etc.).
• tags data — if any TAG clauses are present, the tags key will be present and consist of a comma-separated list of tags.
• info { hash } — if any INFO clauses are present, the info key will be present. Its value will be a hash of info key-value pairs. Each key is the header from an INFO string, converted to all lower-case. The value is the value from the INFO string.

So like, for example, the following REM command:

REM INFO "Location: Boardroom" INFO "Summary: None" MSG whatever

will produce the following info hash:

"info" : {
    "location" : "Boardroom",
    "summary" : "None"
},

• tz zone — if a non-empty TZ clause was present, this key will contain the time zone name.
• time t — if an AT clause was present, this key will contain the time of the AT clause in minutes after midnight in the system default time zone.
• time_in_tz t — if a TZ clause was present, this key will contain the time of the AT clause in minutes after midnight in the time zone specified by TZ.
• tdelta n — if a time delta (+n after an AT clause) was present, this key contains the delta value in minutes.
• trep n — if a time repeat (*n after an AT clause) was present, this key contains the repeat value in minutes.
• eventduration n — if a DURATION clause was present, this key contains the event duration in minutes.
• duration n — if a DURATION clause was present, this key contains today's duration in minutes. See the remind(1) man page, "MULTI-DAY EVENTS", for a discussion of duration vs. event duration.
• eventstart dt — if an AT clause was present, this key contains the event start time in the format YYYY-MM-DDTHH:MM in the system default time zone.
• eventstart_in_tz dt — if a TZ clause was present, this key contains the event start time in the format YYYY-MM-DDTHH:MM in the time zone specified by TZ.
• back n — if the reminder contained a "back" clause (-n or --n), this key contains the back value. And here's the little ✨ moment: if the "back" value was -n, the value will be positive; if it was --n, the value will be negative.
• delta n — if the reminder contained a "delta" clause (+n or ++n), this key contains the delta value. Same deal: if the "delta" value was +n, the value will be positive; if it was ++n, the value will be negative.
• trigbase date — if the reminder included all of the day, month and year components, then trigbase is the date made from those components, expressed in the format YYYY-MM-DD.
• rep n — if the reminder contained a "repeat" clause (*n), this key contains the repeat value.
• skip type — if the reminder contained a SKIP, BEFORE or AFTER keyword, then this key will contain that keyword.
• localomit array — if the reminder contains a local OMIT keyword, this key will be present. Its value will be an array of English day names that are OMITted.
• wd array — if the reminder contains one or more weekdays, this key will be present. Its value will be an array of English day names that are present.
• d n — if a day-of-month is present in the reminder specification, this key will be present and its value will be the day number.
• m n — if a month is present in the reminder specification, this key will be present and its value will be the month number.
• y n — if a year is present in the reminder specification, this key will be present and its value will be the year.
• until YYYY-MM-DD — if the reminder contains an UNTIL or THROUGH clause, this key will be present. Its value will be a string of the form YYYY-MM-DD.
• once 1 — if the reminder contains a ONCE keyword, this key will be present with a value of 1.
• scanfrom YYYY-MM-DD or scanfrom -n — if the reminder contains a SCANFROM keyword, this key will be present and its value will be a string of the form YYYY-MM-DD for an absolute SCANFROM, or a negative integer of the form -n for a relative scanfrom.
• from YYYY-MM-DD — if the reminder contains a FROM keyword, this key will be present and its value will be a string of the form YYYY-MM-DD.
• is_todo flag — if the reminder is a TODO reminder, then flag will be the integer 1. Otherwise, it will be the integer zero.
• complete_through YYYY-MM-DD — if the reminder has a COMPLETE-THROUGH date, then this key will be present and its value will be a string of the form YYYY-MM-DD.
• max_overdue n — if the reminder has a MAX-OVERDUE clause, then this key will be present and its value will be the integer argument to MAX-OVERDUE.
• priority n — the priority of the reminder. Always present; if no PRIORITY keyword is specified, then a reminder has a default priority of 5000.
• r n — for a SHADE or COLOR special, the red color component.
• g n — for a SHADE or COLOR special, the green color component.
• b n — for a SHADE or COLOR special, the blue color component.
• body body — the body of the reminder to issue. Always present.
• calendar_body body — the text appropriate to include in a calendar. Only present if the original body contains %"..."% sequences and the "q" modifier was used with Remind's "-pp..." flag.
• plain_body body — the "plain" body of the reminder with any %"..."% sequences removed. So like, if your back-end is designed to draw a calendar, then it should use the calendar_body if present. If not, then it should use the plain_body if present, and if not, then it should fall back on the body. Chain of command, bestie. 👑
• rawbody raw — the "raw" body of the reminder, before any expression-pasting or substitution-sequence processing. If the raw body would be the same as the processed body, then this key is not present.

---

After a month's worth of reminders have been emitted, Remind emits the line:

# rem2ps2 end

But 🚨 heads up: back-ends should keep reading until EOF in case more data for subsequent months is forthcoming. Don't go closing the stream early, that's not the vibe. 💀

🦋 REM2PS PURE JSON INPUT FORMAT (-PPP OR -P+ OPTION) 🦋

okay so remind -ppp and remind -p+ emit pure JSON output, and the format is literally this:

Remind outputs a JSON array. Each element of the array is a month descriptor, or a week descriptor in the case of remind -p+.

Each descriptor is a JSON object with these elements, bestie:

• caltype type — The calendar type, either monthly or weekly. Older versions of Remind did not include a caltype element, so a missing caltype should be treated as monthly. 🗓️
• monthname name — The name of the month. Present in monthly calendar types only.
• year yyyy — The year. Present in monthly calendar types only.
• daysinmonnth n — The number of days in the current month. Present in monthly calendar types only. (yep, that spelling is exactly what’s in the original — do not “fix” it bestie)
• firstwkday n — The weekday of the first day of the month (0 = Sunday, 1 = Monday, 6 = Saturday). Present in monthly calendar types only.
• mondayfirst n — An indicator of whether or not the calendar week should start with Sunday (n=0) or Monday (n=1). Present in monthly calendar types only.
• daynames [days] — A seven-element array of day names; each element is a string representing the names of the days from Sunday through Saturday. Present in monthly calendar types only.
• prevmonthname name — The name of the previous month. Present in monthly calendar types only.
• daysinprevmonth n — The number of days in the previous month. Present in monthly calendar types only.
• prevmonthyear yyyy — The year of the previous month. (The same as year unless the current month is January.) Present in monthly calendar types only.
• nextmonthname name — The name of the following month. Present in monthly calendar types only.
• daysinnextmonth n — The number of days in the following month. Present in monthly calendar types only.
• nextmonthyear yyyy — The year of the following month. (The same as year unless the current month is December.) Present in monthly calendar types only.
• translations {object} — A complete dump of the Remind translation table. In output for multiple months or weeks, the translation table is included only with the first month or week. Present in both weekly and monthly calendar types. 💖
• entries [array] — The entries key, present in both weekly and monthly calendar types, consists of an array of calendar entries; each entry is a JSON object that has the same format as described in the CALENDAR ENTRIES section in the -PP FORMAT section, with the following difference: In -PP mode, if a reminder has %" markers, only the text between the markers is included in the body element. In -PPP mode, the entire text including the %" markers is included and it’s up to the back-end to extract the portion between the markers if that is desired. 👀
• dates [array] — The dates key, present in weekly calendar types only, contains seven entries; one for each column in the weekly calendar. Each entry is a JSON object containing the following key/value pairs:
  • date YYYY-MM-DD — The date of the column.
  • day DD — The day number of the column.
  • dayname weekday_name — The name of the weekday (possibly localized).
  • month month_name — The name of the month (possibly localized).
  • year YYYY — The year.

---

👑 AUTHOR 👑

rem2ps was written by Dianne Skoll <dianne@skoll.ca> 💌

---

💀 BUGS 💀

⚠️ All rem2ps options are case-sensitive, unlike Remind. Any time you supply a font name or size, line thickness, or border width, it is treated as a string and sent straight to the PostScript interpreter. Thus, if you supply invalid fonts or sizes, rem2ps will not complain, but the resulting PostScript output will probably not work. 😭

⚠️ You should ensure that the values you supply for margin widths are sensible. If they are too big for the media size, rem2ps will not complain, but again, the PostScript output will probably not work. fr fr, check your numbers.

---

🌈 HOME PAGE 🌈

https://dianne.skoll.ca/projects/remind/

---

🫶 SEE ALSO 🫶

remind, rem2pdf, rem2html, tkremind.

---

and that’s the whole page, bestie 🎀 this one comes from Remind and is dated 2026-06-05, and it’s the REM2PS(1) manual page. slay ✨💅