After translation, the word count increases; first examine the text before and after the paragraph

This paper uses synthetic samples to demonstrate the processing method. The code has been verified using examples in an isolated environment; this does not guarantee effectiveness for all real files or products. Before processing important files, please retain the original copies and verify them against the boundaries and acceptance criteria specified in the text. Which problem does this paper address first An empty paragraph does not have spacing explicitly set, nor can it be assumed to be harmless; style inheritance, section breaks, and drawing objects may all affect the layout. Below, only direct attributes are recorded—empty paragraphs are neither automatically removed nor converted from None to zero. self-contained synthetic example dependencies are listed in the import section. The code constructs inputs in memory; runtime logs are provided separately and do not constitute a guarantee for all real-world files. from docx import Document from docx.shared import Pt doc = Document() title = doc.add_paragraph("Title") title.paragraph_format.space_after = Pt(12) explicit = doc.add_paragraph("") explicit.paragraph_format.space_after = Pt(24) inherited = doc.add_paragraph("") def inspect(p): return {"empty_text": not p.text.strip(), "space_after_direct": p.paragraph_format.space_after, "needs_style_review": p.paragraph_format.space_after is None} assert inspect(title)["space_after_direct"] == Pt(12) assert inspect(explicit)["empty_text"] assert inspect(explicit)["space_after_direct"] == Pt(24) assert inspect(inherited)["needs_style_review"] assert len(doc.paragraphs) == 3 After translating a Word document, if you notice large, persistent blank spaces on the translated pages, or inconsistent spacing between paragraphs, the issue usually lies not in the translation itself, but in the paragraph formatting attributes of the source document. Many users, when editing the original text, habitually use consecutive carriage returns to adjust the layout; this “empty-paragraph formatting” is retained—and sometimes even amplified—during processing by the translation engine. The real solution is to inspect and standardize paragraph_format in space_before 、 space_after and line_spacing attribute, rather than manually deleting visible blank lines. Distinguishes semantic spacing from physical blank lines In Word’s object model, a paragraph is a block-level element, and its position is determined by ParagraphFormat object control. Valid paragraph spacing should be achieved via space_before (space before paragraph) and space_after (post-segment distance) and these two attributes are used to define it; they accept Pt 、 Cm Equal length units. According to the manufacturer’s documentation, when two adjacent paragraphs both have spacing settings, Word’s rendering engine applies a “collapse” logic: it takes the spacing from the preceding paragraph… space_after and the subsequent space_before The maximum value among them is taken as the actual spacing, rather than a simple sum. This mechanism means that merely deleting empty paragraphs may not alter the visual spacing; one must also examine the attribute values of adjacent paragraphs. In contrast, if a user creates visual whitespace by inserting a paragraph with no textual content, this empty paragraph remains an independent block-level object. It has its own line height, paragraph spacing before and after, and may inherit styles. During translation, CAT tools or machine translation interfaces might treat this empty paragraph as a valid unit, or language expansion could cause reordering of the surrounding text, leading to recalculation of the originally fixed empty-line height and ultimately resulting in uncontrollable layout misalignment. The key to resolving such issues is to convert all empty paragraphs used for layout into part of the preceding paragraph. space_after attribute, and ensure that this value has taken folding rules into account. Implicit pitfalls of line-spacing rules If the code or template incorrectly places line_spacing is set as a floating-point number, but the rule is set as EXACTLY , or conversely, Word may revert to the default single line spacing or produce excessively large line heights. Furthermore, None The value in these properties indicates “inherited from the style,” which is easily overlooked during batch processing. If the parent style defines a very large paragraph-after-spacing and the current paragraph does not explicitly override this property, directly reading paragraph_format.space_after may return None , causing the validation script to incorrectly detect zero spacing, when in fact there is substantial whitespace during rendering. When writing the check logic, it is essential to clearly distinguish between “explicitly set to 0” and “None inherited from the style.” synthesis example: spacing attribute validation logic The following Python example demonstrates how to construct a document object containing proper spacing, erroneous blank lines, and edge cases, and shows the expected validation output. Note that this code is a synthetic example intended to illustrate property reading and judgment logic, and is not a complete document repair tool. Before running this code, please ensure that you have installed python-docx library (recommended version >= 0.8.11), and prepare the Word document to be analyzed; if using the built-in test data below, no additional files are required. In the code above, inspect_paragraph_spacing The function does not modify the document; it performs only diagnostics. For SUSPECT_LAYOUT_EMPTY_PARA paragraphs of this type, the subsequent remediation strategy should be to space_after The value is merged into the preceding non-empty paragraph (taking folding rules into account), and then that empty paragraph is deleted. For line_spacing is None but rule In cases where values are present, be cautious of the renderer potentially generating unexpected line heights. Acceptance Criteria and Manual Review Boundary automation scripts can address inconsistencies at the attribute level, but they cannot replace an understanding of the layout’s intended meaning. The table below lists the discrepancies between code-based testing and actual document validation, as well as the scenarios that must be escalated to manual review. This table is based on python-docx The summary of attribute behavior does not reflect the built-in detection capabilities of any specific software. Observation of the phenomenon code-layer representation processing decision Manual review trigger condition Excessive whitespace between paragraphs space_after > 24pt or there exists a consecutive empty paragraph automatically merges spacing or deletes empty segments The original text indeed requires substantial whitespace (such as in poetry or forms) line spacing visual anomaly line_spacing_rule is EXACTLY but the value is too small warns and recommends changing to AT_LEAST contains lines with embedded formulas and images attribute returns None Not directly assigned; inherited from the style Keep as is, do not force writing the default value style chain broken or merged across documents Translation results in pagination errors keep_with_next or page_break_before is True retains its attributes; only the content length is checked The title and the body text are forcibly separated uneven spacing between list items list style overrides the direct format prioritizes respecting the style definition combines manual numbering with automatic lists uses this checklist for document translation Word translations often conflate content issues with formatting problems. Leave checks for styles, headers, tables, and other elements to the delivery checklist, so reviewers know where to look. OmniDoc (Product Entry) provides an entry point for translating multi-format documents, and the official website highlights its OCR, terminology database, and bilingual alignment features. For teams that wish to start processing directly from files, this is a path worth evaluating with real-world samples. Please use de-identified files that you are authorized to upload, and verify the results against the checklist provided in this document; we do not claim that OmniDoc utilizes the open-source libraries or internal algorithms referenced herein, nor do we substitute examples for product performance testing. Original manufacturer interface based on: python-docx documentation 。 - 1 -