How Many Takes Fit on a Daily Report Page and Why Text Gets Clipped
A daily report page does not expand freely with content length; it starts with a fixed table and places take records into the available area. The first page can hold up to 24 takes and continuation pages up to 30, but “up to” does not mean every page will reach that count because other header content can consume vertical space on the first page.
The take limits and column widths are layout constraints; when text exceeds a column, the excess is not displayed and is not wrapped onto another line.
Why the first page and continuation pages have different limits
The first page and continuation pages use two hard-coded take limits: 24 on the first page and 30 on continuation pages, with no interface setting for changing them. The first page also has more header content, and meal rows can reduce the height available to the table. The two numbers are therefore page limits rather than a promise that each page will be filled to that count.
When header content reduces the usable height on the first page, fewer records may fit cleanly than the maximum suggests, and the software does not recount the rows to fit: the extra rows are drawn over the footer text or outside the page. Continuation pages have a single title line as a header and a hard-coded limit of 30; both numbers are layout constants rather than values derived from header height, so header length cannot be used to infer how many rows a page holds. Whether a particular report fills the page should be checked in the generated PDF.
Why text inside a cell is clipped
Each text cell draws a single line, with no wrapping and no ellipsis added at the end. When text extends beyond the width of its column, the part outside the boundary is not displayed. This matters especially for long notes because the page does not preserve the full text by increasing row height or moving the remainder onto another line.
The table columns use fixed layout widths and do not expand in response to longer content. Font settings are fixed as well, and this page names no Chinese font, so the rendering of Chinese notes is not guaranteed. The receiver should inspect the actual PDF and keep the clipping boundary in mind during acceptance.
A PDF daily report is suitable as a readable page summary; the amount of text visible in a cell should not be treated as the full length of the underlying field.
Why a multicamera take still occupies one report row
The daily report uses one row per take rather than one row per camera. When a take has several cameras, the PDF row uses the camera that sorts earliest by camera letter to fill the camera roll, audio roll, focal length, and frame rate columns. The corresponding values from the other cameras are not expanded into additional rows on this page.
The report should therefore not be described as showing the complete camera set for that take. When camera-by-camera verification is required, the receiver should return to the machine-readable handoff or the on-set record. The article What a Script Supervisor Needs to Hand Off at Wrap helps separate the role of this human-readable summary from the other deliverables.
Why rows in different handoff files do not line up directly
The same take records are expanded differently by different formats: PDF writes one row per take, while ALE and CSV write rows per camera. A multicamera take therefore remains one row in the PDF but becomes several rows in the two machine-readable files. When a take has no camera at all, each of the three files still writes one row and fills the camera-related fields with its own missing-value form. Matching by row number would incorrectly assume that the same row position refers to the same camera record.
That difference in expansion is exactly what the article Why the Same Takes Do Not Line Up Row-for-Row Across Handoff Files asks the receiver to check by identity. The daily report is designed for page reading, not as a row index for the other two files. The receiver should match scene, shot, take and camera identifier rather than forcing page or row positions to align; a camera identifier is not a PDF column of its own, where it can only be read from the leading letter of the camera roll value.
How the daily report should be used during receiving
The daily report can be used to read a concise view of take records, but long text must be read with the clipping boundary in mind, and multicamera entries must be read knowing that only the earliest camera letter is represented in the row. Font behavior for Chinese text should also be checked in the generated file. A tidy page cannot restore clipped text or camera fields that were not expanded there.
The daily report should therefore be treated as a human-readable summary, while field-level verification should use the machine-readable handoff. If a value affects media identity, timecode, camera identity, or downstream matching, the receiver should verify it against the corresponding machine-readable field and the on-set record. PDF presentation does not make the formats row-for-row equivalent.
FAQ
Will the first page always contain 24 takes?
No, 24 is the first-page limit, and meal rows or other header content can reduce the height available to the table. The generated page is the result that should be checked.
Will a long note wrap onto another line?
No, text cells do not wrap, and content beyond the column width is not displayed or marked with an ellipsis. The visible text should not be treated as the complete field value.
Does a multicamera take expand into several rows in the PDF?
No, PDF uses one row per take and fills camera-related columns from the camera whose letter sorts earliest. Camera-by-camera expansion belongs to the machine-readable handoffs.
Can the daily report be matched to ALE and CSV by row number?
Not reliably, because PDF and the machine-readable formats use different multicamera expansion rules. Verification should use record identity and camera information rather than row position.
Axiom One LLC — SlateX. Figures current as of 24 September 2026.