Split Wide NDT Result Tables into Readable Sections

A wide inspection spreadsheet often combines several different jobs: identifying the component, recording examination conditions, listing observations and tracking review actions. Reproducing every column in one PDF can make all of them harder to understand. Before changing the layout, identify what the recipient needs to determine from each part of the record. A result table should allow the reader to associate a finding with the correct object and evidence. A separate administrative tracker may answer a different question, such as which clarification is still awaiting a response.

This guide develops a column-grouping plan for the free digital NDT reporting workspace. The output is a set of related, readable result tables with explicit row identities and a proof checklist. It is useful when a legacy template has more columns than the editor accepts or produces a crowded PDF even though it imports successfully. Splitting a table is a presentation change, not permission to remove inconvenient observations or redefine examination scope. Preserve the original source and account for every meaningful field before deciding how the report should display it.

List each source column, its meaning, unit where relevant and intended destination. Separate identifiers from measurements, evaluation statements, comments and workflow notes. Identify repeated values that apply to the whole examination, such as a common procedure reference, while checking whether exceptions exist. A value may move into a report field only when the scope of that statement remains clear. Do not replace a column containing several different equipment references with one general reference simply because the resulting table would be narrower.

Look for meaning carried by position, color, a merged heading or an adjacent note. A cell under a broad merged heading may be unintelligible after separation unless its own column label is expanded. Mark these dependencies in the grouping worksheet. The source file can remain the detailed working record while the report presents a reviewed subset or arrangement, but describe the relationship accurately. If the report is supposed to contain all results, the grouping exercise must demonstrate that the complete required information remains present, rather than silently treating a convenient summary as the full record.

Choose a row key that identifies the same observation or object wherever it appears. A component identifier alone may be insufficient if the component has several examination locations, dates or indications. Use the combination actually needed to distinguish the records and explain it in the report. An invented sequence can serve as a local report reference, but preserve its mapping to the real source identity. Avoid relying exclusively on spreadsheet row numbers, which may change when a user sorts, filters or inserts records.

Repeat the necessary identity in each split table. That may consume a column, but it allows a recipient to reconnect the records when tables appear on different pages or are discussed separately. Check that every reference is unique at the intended level. If two observations genuinely share a component but differ by examination event, do not force them into one row to make the tables look aligned. The worksheet should state whether it represents components, locations, indications or review actions. Those units of record determine how the tables can be compared without losing meaning.

A useful division might place component and location information in one table, observed values in another, and evaluated outcomes or unresolved questions in a third. The actual grouping depends on the assignment. Keep fields together when separating them would require the reader to reconstruct an essential relationship repeatedly. A measurement and its unit, for example, should remain understandable within the same table. A finding category and its explanation may also belong together even if a different layout would produce more equal column counts.

Avoid dividing a table mechanically after every sixth column. That approach follows screen width rather than information meaning and may split the identifier away from the observation it describes. Name each resulting table for its purpose and use the same row-key convention throughout. If a separate notes table is necessary, reference the relevant observation explicitly. Do not assume that the third note automatically belongs to the third result after independent sorting. The goal is a record whose connections survive ordinary document handling, not merely a document that fits on a page during the author's first preview.

The current editor supports up to ten tables, twelve columns per table, one hundred rows per table and five hundred rows across the report. These are application limits, not recommended inspection sample sizes or reporting requirements. A complex job may need several appropriately identified reports or another agreed delivery arrangement. Establish that arrangement before entering a large dataset. Do not omit required results to remain within a software limit or change an examination record's meaning to make a table qualify for import.

Prepare the supported tables in the source document or spreadsheet where practical, then select and review each candidate during import. The editor can add a selected table or replace the current result tables; choose deliberately. Adding preserves the other tables, while replacement is a different operation with different consequences. The application does not automatically design the best column groups or verify that split tables contain matching identities. Use the grouping worksheet and the original source to perform those checks. Save an editable backup before a substantial rearrangement so the presentation work does not put existing entered material at unnecessary risk.

Write headers that identify the quantity and unit clearly. If adjacent source columns use different units, preserve that distinction when splitting them. NIST's guidance on writing with SI units provides conventions for communicating unit symbols. Use it as a reference for presentation; it does not choose the measurement basis required by an inspection procedure. A layout change should not silently convert units, add decimal places or make a rounded summary appear to be the original recorded observation.

Retain the actual meaning of blank, unavailable, not applicable and not examined states. They should not collapse into a single empty-looking cell merely because the new table has fewer explanatory columns. If the project uses abbreviations, define them where the recipient can find the legend. Do not fill an absent result with zero to make a row visually complete. A numerical zero is a result with its own meaning. Where the source state is unclear, record the question for the responsible reviewer rather than allowing a formatting decision to resolve an evidence gap.

A long explanation repeated in every result row can dominate a PDF. Determine whether a concise, accurate reference can point to a separately stated explanation. Keep exceptions visible and preserve enough text in the result table for the reader to understand why the reference matters. A common note should describe the rows to which it applies. Do not make a broad statement about the entire examination when the original note concerned only one inaccessible location or a limited portion of the recorded work.

When using a notes table, give each note a stable reference and identify the affected result keys. Review references in both directions: every cited note should exist, and every retained note should have a clear subject. Avoid creating an orphan paragraph that no longer identifies the observation it qualifies. The reporting editor supports ordinary text and tables; it does not maintain a relational link between them. If you rename a result key or note label, update and verify all affected references manually. The lack of an automatic relationship makes deliberate cross-checking particularly useful before a final PDF is issued.

Use short, descriptive column headings instead of stacked abbreviations that only the original spreadsheet author understands. Microsoft's Word accessibility guidance recommends simple table structures and clear header information. That source concerns Word documents, not certification of this application's PDF output. The relevant editorial principle is to make each table's organization understandable without relying on complex merged cells or visual positioning alone. A clean grouping can help readers even when the original workbook remains available separately.

The current PDF renderer selects landscape orientation when a result table has more than six columns; otherwise it uses portrait orientation. It wraps table text and repeats table headers when content continues. These behaviors help with layout but do not guarantee that every dense table will be comfortable to read. Generate a draft and inspect the actual output at ordinary viewing size. A twelve-column table may meet the software limit while still needing a clearer division. Choose the arrangement for the reader's task, then verify it rather than treating automatic page orientation as a substitute for presentation review.

Imagine a fictional fabrication record with sixteen columns covering weld identity, drawing location, examination conditions, observations and review comments. The author cannot place that complete grid in one supported result table. Instead of dropping four fields, the author maps every source column to three groups: examination identity, observed results and review notes. A stable practice observation key appears in each table, together with the minimum component reference needed to recognize the record. The original workbook is retained to support the mapping and comparison.

During the cross-check, the author discovers that two rows share a weld identifier but concern different examination events. The first grouping would have treated them as one observation. The key is revised to distinguish the events, and all three tables are checked again. A long comment about restricted access is placed in a note with an explicit reference to the affected event. This invented example establishes no inspection requirements or acceptance criteria. It shows why the most important part of splitting a grid is preserving identity and qualifications, rather than finding enough empty space to display every column.

Compare the source inventory with the finished report, field by field. Confirm that every required source field has a destination and that each move preserves its scope. Count rows using the defined record unit; a notes table need not have the same row count as an observation table. Explain that relationship instead of forcing identical counts. Select several records that include ordinary results, exceptions and repeated component identifiers, then trace them through the full set. Exceptional cases often reveal a missing key or overbroad common note that a simple first-row check misses.

Check the source ordering and the final ordering separately. Two tables can contain all the correct values yet pair them incorrectly if one was sorted independently. Use keys to verify the association, not the apparent row position. Check numeric text, leading zeros and any symbols after import, then compare the PDF with the editor. The application does not calculate technical acceptance from the entered cells. A successful grouping review therefore confirms faithful presentation and relationships; any evaluation or approval still needs the appropriate technical evidence and responsible decision.

Review repeated identifiers as a specific failure case. Suppose an observation table contains the local key W-14 twice because two source rows were copied during preparation. A separate notes table may now point to either one, and the reader cannot resolve that ambiguity from the PDF. Search the prepared keys for duplicates before import, then confirm whether the duplication is an error or reflects a legitimate difference that the key failed to express. Do not simply remove the second row. It may contain distinct examination evidence. Resolve the underlying identity and update every related table consistently. Also check for a key present only in a notes or review table: that can reveal a missing result, a superseded reference or an intentionally separate action that needs a clearer label. These checks do not require the software to infer a relationship. They require the author to state the intended relationship explicitly and prove that the displayed records follow it.

Inspect a result row that continues near a page boundary, the start of each new table and the last page of the report. Confirm that repeated headings remain understandable and that the report number and revision identify the output. Read the longest note and the narrowest column rather than judging only a sparse first page. If the document is difficult to use, return to the grouping plan. Shorten a heading only when its meaning remains clear; do not delete a qualifying statement just to avoid another page.

Keep the editable backup and the column map with the appropriate private project records. The PDF is the rendered output, while the backup preserves the entered report structure for later work. For an already issued report, use the revision workflow and describe the actual presentation change through the project's process. The data-file manifest guide can help identify the supporting source package, and the procedure draft workspace can organize reporting requirements for review. Finish with a report whose tables are readable individually and explainable together, with no result lost between the original grid and the delivered pages.