PostScript Debugger

The PostScript Editor lets you work with that program directly. You can write or open .ps and .eps source, run it, see what it draws, and inspect anything it writes to %stdout or %stderr.

The editor is also a full debugger. You can set breakpoints, step into, over, or out of procedures, inspect PostScript's operand, call, and dictionary stacks, and evaluate expressions against a paused program from the console.

Opening It

Press PostScript… on the home screen. The editor is a page, not a document window — it replaces the whole app frame the way the home screen does, and the < button at the left of the menu bar goes back. Documents you had open are untouched and are still there when you return.

Layout

The page is three resizable columns:

Preview (left) — what the program has drawn so far, redrawn after every step. It is a real image view, so zoom, hand, and color management work here exactly as they do on a document.
Source and Output (center) — the editor tabs above, and beneath them the Output pane carrying everything the program writes to %stdout and %stderr, with the console entry line along its bottom edge.
Transport and Stacks (right) — the run buttons on top, and under them the operand stack, call stack, scope (the dictionary stack) and the breakpoint list. The transport sits with the stacks because that is what it acts on: pressing Step changes what the stacks show.

A status line runs along the foot of the page.

Files, Buffers and Tabs

These are three separate things here, which explains most of the editor's behavior:

Thing	What it is
File	Bytes on disk. This is what `run` reads — always.
Buffer	One file as you are editing it: its text, its unsaved changes and its breakpoints.
Tab	A view of a buffer, opened on demand.

A buffer can exist, hold breakpoints and be executed with no tab at all — running a library is not a reason to look at it. Closing a tab drops the view and keeps the buffer, which is why breakpoints survive closing a tab.

File ▸ New File… asks for a name up front, so there is never an untitled file to name later — which is why Run can save your work without stopping to ask.

Programs Are Files

Pressing Run saves every changed buffer and then executes the active one from disk. So (lib.ps) run means here what it means in Ghostscript, and one tab can call another. The console is the exception — see below.

Where the Files Live

Programs go in the app's own storage under user/postscript. That is the folder run searches, and it is where the first Open or Save As in the in-app files browser starts. The shipped samples live one level down, in user/postscript/examples, so the library root stays yours:

Sample	What it shows
`hello.ps`	The smallest useful program — it computes, prints with `=`, and draws.
`stepping.ps`	Written to be stepped: put a breakpoint on the `fill` inside `/bar` and the preview gains one bar per stop.
`lib.ps`	A small procedure library, meant to be pulled in with `run`.
`uses-lib.ps`	The other half of the pair — step into the `run` and `lib.ps` opens as its own tab.

You can open a .ps file from anywhere with File ▸ Open… (either the in-app files browser or the native picker — the split menu remembers which you prefer). A file opened from an arbitrary folder runs fine as the active program, but it cannot be reached by run from another program: (name) run resolves bare filenames under user/postscript only — beside the asking file first, then at the library root, which is how examples/uses-lib.ps finds examples/lib.ps. No ../, no absolute paths.

Running and Debugging

Control	Does
▶ Run / Continue	Runs until the next breakpoint, or to the end. With no breakpoints set, continuing is running — it is one verb.
Step Into	One operation, entering procedures and `run` files.
Over	Runs a called procedure to completion and stops after it.
Out	Finishes the current procedure and stops in its caller.
Restart	Back to before the program ran: the drawing, the printed output, the stacks and the paused position all go.

One step is one operation, not one line. A push or an operator call — bx w add by lineto is five of them. The current line gets a band and the exact operation being executed gets a tighter highlight inside it, so stepping across a line visibly advances.

Editing discards a run in progress — the program you were stepping no longer exists. Breakpoints are not discarded: they move with the text, so typing a line at the top of a file renumbers every breakpoint in it.

Breakpoints

Click the gutter to set or clear one. The interpreter tests it before executing each value, so the operation you marked has not run yet when you stop.
The Breakpoints section lists them grouped per file, active file first. Click a row to open that tab on the line; right-click for Delete Breakpoint / Delete All Breakpoints.
They live on the buffer, so closing a tab keeps them, and they are saved across sessions.

The Stacks

PostScript has three stacks and all three are shown, operand stack first — in a stack language that is the program state. Values are written the way the language writes them (-dict-, {proc}, (str), /name). Clicking a call-stack row reveals that frame's call site, opening its tab if it is not already showing.

The Console

The line under the Output pane. Type PostScript and press Enter: it is evaluated against the live interpreter, so it sees the paused program's dictionaries and leaves its results on the real operand stack. w = prints the value of w as the program sees it right now, and the program's own position does not move.

The console is the one thing here that is not a file: paste-and-try needs no file.

See also: PostScript for the language and file format itself, Debugger for the document-embedded VMs (Flash and DVD), and File Locations for where app storage lives.