How Many Takes Fit on a Daily Log Page and Why Text Gets Clipped
A Daily Log page does not expand freely with content length; it starts with a fixed table and places take records into the available area. How many takes a page holds depends on that page’s actual usable height: the more header content, the less height the table gets, and the number of records that fit changes with it.
Page capacity 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 hold different numbers of takes
The first page and continuation pages carry different header content, so the height available to the table differs and no single fixed count applies to every page. The first page also carries the title, the shoot-day header with call time, first shot, and wrap, and meal rows push the table further down; a continuation page has a single title line. The software calculates each page’s capacity from its actual usable height, and there is no interface setting for it.
There is therefore no one fixed count that applies across pages: more meal rows mean fewer records on the first page, and a continuation page’s capacity is likewise computed from its own layout height. How many records a given report page holds 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 have fixed widths and do not expand in response to longer content. How Chinese notes render should be checked in the generated file. The receiver should inspect the actual PDF and keep the clipping boundary in mind during acceptance.
A Daily Log PDF 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.
How a multicamera take is laid out in the Daily Log
The Daily Log also writes one row per camera: when a take has several cameras, each camera that took part gets its own row, and the camera roll, audio roll, lens and frame-rate cells carry that camera’s own reading. A take with no camera still occupies one row, with those cells left empty. The table has no camera-number column, so camera identity can only be read from the camera roll cell — the card number as transcribed when one was written down, otherwise the roll name the software derived.
The report lists fewer fields than the machine-readable files, so camera-level parameters that never made it onto this table still belong in the ALE or the CSV. 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.
How the Daily Log should be used during receiving
The Daily Log can be used to read a concise view of take records, but long text must be read with the clipping boundary in mind, and camera identity must be read knowing the row has no camera-number column — the cell you are looking at may be a transcribed card number or the roll name the software derived. Chinese text rendering should also be checked in the generated file. A tidy page cannot restore clipped text or fields that never made it onto this table.
The Daily Log 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
Is the number of takes on the first page fixed?
No, header content on the first page—meal rows included—changes the height available to the table, and each page’s capacity is computed from its actual layout. 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?
It does. Like the ALE and the CSV, the PDF writes one row per participating camera; but the table has no camera-number column, so camera identity comes from the camera roll cell and per-field camera parameters still belong to the machine-readable handoffs.
Can the Daily Log be matched to ALE and CSV by row number?
Row counts now sit at the same camera-level granularity, but each file sorts by its own keys: the report goes scene, shot name, take; the ALE goes scene, shot number, take; the CSV largely keeps the order records were created in. So a row position still does not carry across files. Verification should use record identity and camera information rather than row position.
Axiom One LLC — SlateX