Menü
MathType book page: format DOCX math and verify PDF.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Review loop: run parallel reviews on a fix design.
Lead: coordinate approved delivery, artifacts, and gates.
Keyboard, focus, screen-reader, contrast, WCAG A/AA.
Architecture/maintainability gate: coupling, cohesion, layering, debt.
Performance gate: latency, throughput, memory, CPU, benchmarks, budgets.
Auth, secrets, injection, exposure: merge gate.
| name | mathtype-book-page |
| description | MathType book page: format DOCX math and verify PDF. |
Use this skill to bring translated technical-book DOCX pages to an accepted MathType-based format. The skill is repo-independent: discover local paths and scripts from the current repository instead of hardcoding drive letters, document segment names, UIDs, or machine-specific locations.
Use the currently accepted page in the active repo as an exemplar, but express every rule as a reusable pattern for other pages. Do not encode page numbers, formula numbers, formula identifiers, source document names, or one repository's directory layout into the skill body.
Applying this skill means closing the visual/template defects in the document, not merely reviewing them. A raw OMML/MathML-to-MathType conversion, an OLE count report, or a worker report that says formulas were converted is not skill application. If the rendered document still shows old defects such as small/clipped integrals, loose or wrong braces, short determinant bars, detached hats, artificial alignment cells, wide gaps before =, or text/formula numbers inside MathType, mark the chunk REVISE and route it to template/source repair before final review.
Applying this skill also means preserving the full translated source coverage. A formula-complete or figure-complete chunk that omits ordinary prose, section introductions, derivations, problem statements, footnotes, captions, table titles, listings, output blocks, references, or continuation text is REVISE even when every visible formula is editable MathType OLE.
Treat the original source PDF as the mathematical and layout authority for every final DOCX/PDF candidate. An accepted exemplar controls reusable formatting patterns, but it never overrides the current source PDF's formula content, indices, accents, inline math, equation references, captions, page numbering, or source-specific layout.
No chunk may receive final PASS until the current rendered candidate has been compared against the corresponding source PDF pages after the latest edit. This comparison must cover every changed display formula, every meaningful inline MathType object or styled Word math run, nearby punctuation, equation-number references in prose, figure captions, code/listing/output blocks, and any formula/table/layout region touched by the repair.
Before repairing a local formula/table/figure defect, verify the source-flow order on the rendered source page, not only the extracted paragraph order. A caption, figure crop, display formula, or prose connector can be extracted in the wrong stream order. If the candidate has a loose caption, a missing figure, or formulas appearing after later-numbered displays, compare the whole source spread visually and repair the Word flow so figures, captions, formulas, prose connectors, and equation numbers appear in source order. Do not move a grouped figure merely to the paragraph that first references it when the rendered source page visibly floats the figure after intervening formulas or connector prose; in that case preserve the visual source flow and keep the figure/caption grouped at that position.
When repairing a local formula template such as cases/braces, inspect the immediately preceding and following prose against the source PDF before promotion. A formula can have correct MathType OLE content but still be in the wrong Word flow order, for example sitting before the paragraph that introduces it. Repair that neighboring source-flow defect in the same targeted lane, without rebuilding unrelated formulas.
Correct XML order is not sufficient for source-flow acceptance. After moving connector prose, conditions, or labels around a display formula, render the exact candidate and check whether Word pagination or column flow visually separates the connector from its formula or places the formula before its introduction. If the connector and display no longer read in source order on the rendered page, treat it as a layout/page-flow blocker: fit or group the affected block with stable Word paragraph/table settings, or record the remaining visual-flow defect explicitly. Do not claim visual pass from paragraph/table indices alone.
After repairing a figure/caption block, inspect the immediately following prose and any numbered/bulleted list against the same source spread. A broken extraction can swallow the first body paragraph into the caption table, split one source paragraph across the wrong containers, or drop/merge list items. Captions must contain caption text only; explanatory prose and list items must be ordinary Word body/list paragraphs in source order, with their inline MathType/styled math preserved or rebuilt at the exact source positions.
Figure grouping is not enough to prove figure correctness. For each touched figure, compare the rendered candidate image against the rendered source PDF: all axes, tick labels, titles, legends, frames, curve endpoints, and source-visible labels must be present and inside the page/column. If the DOCX media part is already cropped, replace that media part from a source-backed crop; if the media is complete but the render clips it, reduce the drawing/table extent to fit the column. Do not rebuild MathType formulas for pure figure crop/extent defects.
After inserting, moving, or recropping a missing figure, inspect the next figure block on the same source spread before accepting the lane. A newly repaired float can expose an older cropped media part or stale wp:extent on the following figure; repair that figure by replacing only its image media and proportional display extent from a source-backed crop, keeping the editable Word caption, and do not rebuild unrelated MathType objects.
Rendered figure text is part of the translation gate even when it lives inside a bitmap and cannot be found by DOCX/PDF text extraction. Visually scan touched figures for accidental source-prose bands, OCR residue, and source-language legend labels. Repair only the affected media part when possible, preserving mathematical/node labels that are source symbols. If the original drawing dimensions control nearby column flow, prefer same-size whiteout/label replacement over cropping; any change to bitmap dimensions or wp:extent must be followed by a render check of the whole affected page because display formulas can migrate across columns. When a replaced image becomes clipped or too small, adjust the containing table/cell width and the drawing extents (wp:extent plus the matching drawing transform extent) together, then re-render; replacing the bitmap bytes alone is not sufficient evidence.
When inserting a new bitmap crop into an existing DOCX, prefer cloning a rendered image paragraph/table from the same current candidate and retargeting only its relationship, extents, and docPr/picture names. Handcrafted minimal DrawingML can parse and reserve page space in Word while exporting blank pages or missing image XObjects. After insertion, verify both visually and with a PDF image-object probe such as pdfimages -list; file existence, relationship validity, and ZIP/XML success are not enough. If the rendered page is blank or the expected image object is absent from the exported PDF, revise the insertion template before changing crop geometry or promoting the candidate.
When localizing bitmap labels, verify both translation and drawing integrity after render. Replacement labels must be scaled to the original figure, not to body text, and whiteout boxes must cover the old words without erasing meaningful geometry, axes, arrows, hatching, or curve data. If a rendered check shows either residual source-language fragments or oversized/truncated replacement labels, revise the media-part repair and render again before acceptance.
When text extraction from the PDF is noisy, render or crop the source page and compare visually. If the source PDF is ambiguous, record the ambiguity in the repo QA artifact and keep the chunk at REVISE or CANDIDATE; do not infer the formula from neighboring patterns or from the generated DOCX.
When old QA notes conflict with the current source render or a newer accepted chunk ledger, treat the old note as stale until revalidated. Do not "correct" OCR-like labels or references by visual similarity or inference (4g versus 49, 80b, and similar); verify the exact source glyph on the current rendered page and record contradictory stale artifacts instead of applying them.
Nearby source surfaces can intentionally disagree. Body prose, captions, legends, table headers, and neighboring paragraphs must each be checked against their own source line/crop; do not normalize a body value from a caption value, or a caption value from nearby prose, unless the source or user explicitly marks one as erroneous.
Translated prose is part of the source check. Do not leave accidental source-language technical terms inside target-language body text merely because formulas are correct; classify whether the term is a code token, bibliography title, figure-label text, or ordinary prose, then translate ordinary prose terms consistently. When a sentence contains paired inline substitutions, coordinate relations, or variable changes, verify the pair as one source unit; do not preserve one inline object if its sibling relation was dropped.
Body-font outliers can be source-flow defects, not only style defects. If one line of ordinary explanatory prose is rendered in code/listing size or monospaced style while the following line continues the same source sentence, compare the source page, merge the split text back into one body paragraph, and preserve any inline MathType OLE objects or styled math runs from the continuation. Do not merely enlarge the code-style paragraph if the source sentence was accidentally split; repair the paragraph flow and render the affected page.
Source tables must not be flattened into code/listing paragraphs. If a source-visible table is rendered as one or two monospaced lines, compare the source page visually, rebuild the area as a real Word table with source-faithful columns/rows, restore the table title/source note and any explanatory prose immediately before or after the table, and delete stray tail fragments created by the flattening. Keep table numeric text as ordinary Word text unless the source cell contains mathematical notation requiring inline MathType or styled math.
Font-size audits must be render-grounded. A DOCX text run can look like a font or missing-text defect when inline MathType OLE objects are omitted from text extraction, or when a chunk-level body-size baseline is skewed by references, index text, tables, or code. Before repairing a font outlier, inspect the rendered page against the source page and compare the paragraph with its immediate neighbors. If the rendered page is visually correct, record a scoped false-positive classification instead of changing styles.
Short OCR/flow fragments near formulas are translation blockers even when they are only one or two Latin characters. Scan rendered text and DOCX text for residues such as a stray i- after a bracketed citation before a display formula, then compare the full source line visually. Remove the fragment only when the current source PDF proves it is not a source-visible symbol or connector, and update the owner repair/generator so the next build cannot reintroduce it.
Do not clean OCR/provenance leaks by deleting marker paragraphs only. For appendix/listing/output failures, compare the rendered source flow, identify the full source-equivalent range from stable surrounding anchors, and remove the entire leaked OCR range before inserting translated prose, source-faithful listing/output blocks, or recorded source-image exceptions. A successful grep for a provenance/uncertainty marker is not enough: unmarked code fragments, source captions, page headers, or output tails can remain visible and must be checked in the rendered candidate.
Source-visible headings and section numbers are prose completeness gates. Compare the rendered source spread for missing headings, wrong heading level/style, all-caps drift, and headings merged into body paragraphs. Repair headings as ordinary Word heading paragraphs and render-check neighboring figures, captions, formulas, and body paragraphs for flow changes; do not rebuild MathType objects for a heading/style defect.
If the user explicitly accepts a visible or mathematical deviation from the source PDF, record it as a named human-approved exception in the chunk QA artifact and status ledger. Preserve the exact user acceptance wording, the donor/sample path, the rendered evidence path, and the remaining source mismatch. Such an exception may unblock the next local repair lane, but it is not source-PDF proof and must not be silently upgraded to final formula PASS.
Source negation and modality are source-critical text, not style noise. During translation/font audits, explicitly compare source words such as not, not necessarily, only, except, unless, at least, and at most with the translated sentence. A visually clean paragraph is REVISE if it drops a negation or reverses a constraint, even when font size, MathType objects, and formula numbering are correct. Repair the prose only, preserve nearby inline math/OLE objects, and render the affected line after the fix.
Reference and index headings are ordinary translatable document structure. Translate headings and running labels such as REFERENCES and INDEX unless the user approved a source-language facsimile, while preserving bibliography article/book titles, journal names, author names, code strings, and file names as source-language exceptions. Compact index entries may legitimately use smaller source-like font; classify them by rendered source comparison, not by body-text size heuristics alone.
After repairing or regenerating a references/bibliography tail, compare the rendered candidate against the source PDF for heading count, first/last item, and numbering range. Multiple independent references sections can be source-correct when a chunk crosses chapter or appendix boundaries, but a duplicated references heading with the same first bibliography item, a duplicated first item, or numbering shifted by one is a text-flow blocker even when formulas, OLE counts, and publication-token scans are clean. Repair the reference-tail owner so it removes stale existing references from the section heading, not from the second item or another mid-list anchor.
Formula-adjacent Word text is still translation text. Source-visible connectors or conditions between/next to MathType objects, such as and, or, where, for TE modes, and for TM modes, must be translated as ordinary Word text when they are outside the mathematical expression. Keep them out of MathType unless the source formula template requires the condition inside the equation object, and render-check that the translated connector does not shift or overlap the neighboring OLE previews.
Merged multi-number display blocks are REVISE when the source PDF has ordinary prose between the numbered displays. Source-visible connector phrases such as where, with, in explicit form, in matrix form, therefore, provided that, and their translated equivalents must appear in the same visual source-flow position as ordinary Word text outside MathType. A single MathType/table block with right-cell text (N)(N+1) is acceptable only after rendered source-PDF comparison proves the source itself is one aligned multi-line display with no intervening prose connector; otherwise split the display tables or move the connector before promotion.
Author-list connectors inside otherwise translated captions or body attribution are ordinary prose connectors. Translate an English and between two author surnames (a source caption form such as <Surname1> and <Surname2>) into the target-language conjunction unless the whole line is a bibliography entry, a source title, a journal name, or a user-approved facsimile. Preserve author names as source-visible Latin names when that is the document convention; translate the connector, not the names.
Caption copyright and attribution boilerplate should not remain as source-language prose in an otherwise translated caption. Convert caption forms such as <Author> et al. [N], copyright © YYYY by <Publisher> to source-faithful target-language attribution such as <Author> и др. [N], © YYYY <Publisher> (or the repository's equivalent localized style), unless the user explicitly requests a verbatim source facsimile. Do not apply this rule blindly to bibliography entries or source titles; captions are the primary target.
Never collapse stage-specific success into final acceptance.
| Stage | Allowed result | Not allowed |
|---|---|---|
| Source-map or no-Word repair | PASS only for the scoped source-map subset, with final chunk still REVISE | Claiming final MathType/layout/source-PDF acceptance |
| XML-only layout/table/figure repair | CANDIDATE only, until the exact scratch DOCX is rendered and compared with the source PDF | Treating clean DOCX XML, grouped figures, or fixed table counts as visual acceptance |
| Writer/OLE insertion | PASS only for mechanical conversion counts, exported DOCX/PDF, and zero placeholders | Treating OLE count, validation JSON, or exported PDF existence as skill PASS |
| Skill review | PASS only after full source-text coverage review, rendered visual review, source-PDF formula proofread, inline proofread, layout review, and figure/caption review | Accepting spot checks, formula-only checks, stale reports, or worker summaries |
Before any worker starts a chunk, require a quick anti-false-pass scan:
REVISE.PASS or REVISE rows are evidence to recheck against the current rendered DOCX/PDF.REVISE and write a repair/spec artifact instead of advancing the queue.Workers must state the scope of their verdict. Use phrases such as PASS for no-Word source-map repair only or PASS for mechanical writer conversion only. Do not write bare PASS unless the full skill review gate has passed.
Before final PASS, prove that the candidate represents the whole source chunk, not just formulas and figures. This is the quantitative omission check; it is complementary to the Translation Completeness Gate (which checks that each visible unit is translated and in source flow) and does not replace it.
Required coverage checks:
0.85 is a hard REVISE unless the QA artifact explains a source-specific reason such as OCR garbage, mostly-image pages, very dense formulas, or intentional scope exclusion approved by the user. A high ratio is not a PASS by itself.Do not advance to the next chunk when the current chunk is missing ordinary text. Freeze the pipeline, mark the affected chunk REVISE, and repair the coverage defect before producing more chunks unless the user explicitly parks the repair.
For sequential chunk production, treat the previous chunk's full-coverage closure as a prerequisite for the next chunk. Do not start the next chunk from formula/OLE success alone: the current chunk's QA or status artifact must contain fresh evidence for rendered-PDF/source text coverage, source-map/source coverage or an equivalent source-page ledger, visual source comparison, and any source-specific exception. If a low-ratio repair required adding ordinary prose, update the reusable source-map or builder pattern before continuing so the omission does not propagate.
Treat this skill as a quality gate, not a generator prompt. A worker may produce only a repair candidate while any hard blocker remains. It must not advance a chunk, start a batch, or claim final acceptance.
Hard blockers:
{24|, {15}, |24], |3-5]), missing punctuation inside multi-reference citations ([1 2] when the source shows [1, 2]), interval delimiters misread as pipes/angle text (|a,<] instead of a source interval), or source line-break hyphenation preserved as separate translated paragraphs (preобра- / continuation-word style splits);≪ becoming <, ≤ becoming <, ≈ becoming =, etc.). Treat these prose operators as mathematical content, not typography, and verify them against the source render before accepting the neighboring formula;1. or 2. away from the item text; use stable left alignment for the list item paragraphs while preserving surrounding book-style body justification;=, wrong bold/italic/upright math style, wrong indices, text inside MathType, formula numbers inside MathType, loose figure/caption blocks, merged formula tables, or plain-text formula markers;sin, cos, cosh, exp, etc.) renders as glued italic variable letters or loses the source spacing around neighboring variables; use native MathType/operator templates or explicit MathML operator/function structure, then render-check the affected line;10^{-6}, 10^-6, O(r^{-2}), etc.) is rendered as OCR-like punctuation/text, loses its exponent, or is separated from the source sentence; repair the prose completeness first, then represent the expression as inline MathType or stable styled math in the source position;e^{-α Δl}, e^{-jβz}, e^{jωt}, etc.) is split into raw text plus one-letter OLE objects, loses Greek/spacing/script placement, or makes the translated sentence semantically wrong. Repair the whole source sentence and the whole inline expression together; do not patch only the visible letter or exponent fragment. If a temporary styled Word fallback is used, record it as scoped CANDIDATE, remove superseded OLE/media parts, and do not call it final MathType PASS;R cos alpha, R sin alpha, dR d alpha, etc.) is flattened into OCR-like glued text (Rcosa, Rsin a, dR da) or loses Greek symbols/spaces/operator styling; repair the Word prose and inline math at the source position before accepting the page;The agent that generated or converted a chunk must not issue final PASS for that same artifact. It may report CANDIDATE, REVISE, or a scoped stage result. Final PASS requires a separate current-render review by the main/integration gate or an explicitly assigned reviewer.
If a defect is systematic in one chunk, freeze the same pipeline for later chunks until the rule/script is updated and the failing example has a rendered repair candidate. Do not multiply known-bad output.
For any defective chunk, read and execute references/defective_chunk_repair.md before changing files. That reference is mandatory when the task is to fix a bad chunk, not optional background reading.
Minimum repair loop:
If the worker cannot complete these steps, it must return REVISE with a defect ledger instead of producing more converted output.
Do not run a full Word/MathType writer pass when the active defects are layout, figure/caption grouping, typography, grammar, punctuation, source-map review, or one-to-few formula/template defects. For local formula defects, replace only the defective formulas or inline objects and leave accepted formulas untouched. A full rebuild is the last step for broad source-map changes or stale OLE state, not the default repair tool.
Use this order:
If a no-Word text or inline repair corrects prose emitted by a source-map owner, generator, or targeted repair script, update that owner as well as the current scratch candidate. A candidate-only XML replacement is not durable when the next reproducible run can regenerate the same bad sentence, label, punctuation, or connector. The repair must identify the owning source, constrain text replacements to the exact expected occurrence count, render the affected line/page, and record both the current candidate and owner-script change in the artifact.
When multiple scratch candidates exist for one chunk, always identify and continue from the newest verified candidate lineage that contains the accepted formula/OLE repairs. Do not run a layout/style normalizer against an older final release if later scratch OLE candidates corrected formula content. Rebase layout-only repairs onto the latest accepted OLE candidate, or explicitly prove that the final release already contains those OLE changes before promotion. A visually neat candidate based on stale formulas remains REVISE.
Apply the same lineage check to targeted repair scripts. Before running a one-off formula, inline, table, or figure repair, inspect the script's default input candidate and compare it with the newest status ledger or current handoff. If the default is stale, pass the current candidate explicitly or update the script default before accepting output. The repair artifact must record the actual base DOCX used; a clean render from a stale base is REVISE because it can silently discard later accepted repairs.
If a stale-base run has already produced later candidates, repair the lineage before continuing review. Find the newest verified base that still contains all previously accepted repairs, then reapply only the missing later targeted patches in dependency order. After rendering, probe at least one marker from every repair that could have been dropped, such as a prior formula-template fix, figure/caption move, heading insertion, inline-math repair, and the newest repaired formula. Do not patch only the visible symptom on the stale candidate; that preserves the regression. Update the one-off script defaults or invocation notes so the next run starts from the cumulative candidate.
After a source-map repair changes any formula payload, split, order, or inline object, any older MathType OLE output for that changed object is stale even if the previous writer run was mechanically clean. Route it to targeted OLE replacement or a justified chunk-local writer only after non-Word blockers are closed.
An existing MathType OLE object can also be stale or visually partial even when package counts, validation JSON, and source-map identifiers look clean. If a rendered formula shows only a tail fragment, missing left side, wrong row order, missing display number, or source-inconsistent residue, treat that object as defective current evidence. Replace only the affected object or source-flow block from a source-backed donor; do not use clean OLE counts as acceptance evidence for the visible formula.
Preserving inline OLE objects by ordinal is not source proof. When rebuilding a mixed prose/inline-math paragraph, verify every preserved inline object or styled math run against the rendered source PDF for symbol identity, script/accent placement, and style. This includes visually similar source variables (u/v, ν/v, μ/u), repeated inline functions such as v(s) around a display equation, and indexed one-symbol references such as v_i; a paragraph can have correct punctuation while still carrying the wrong preserved OLE or a flattened plain-text index. If a preserved object is the wrong symbol or index, replace only that object with a source-backed donor or stable styled Word math, remove the superseded OLE/media relationships when they become unused, and update the owner script so the next assembly cannot reintroduce the stale object.
Treat lost inline superscript signs and star substitutions as high-risk OCR defects. If the source sentence has symbols such as a^-, b^+, d^+, or R_m'' and the translation shows plain a, b*, detached punctuation, or a wrong prime/star, repair the inline object as source-faithful styled math or editable MathType at the exact text position. Verify the rendered baseline and the source sentence before accepting the prose.
Reject prose/OLE residue blocks where inline symbols from one source sentence have been split into separate blank-looking MathType paragraphs between the prose and the following display formula. Compare the source sentence visually, rebuild the whole sentence with inline MathType or styled inline math at the correct positions, remove the orphan residue paragraphs and their package parts, then render-check that the following display formula still starts immediately after the source-equivalent prose.
Inline lists of indexed variables are source-critical as a group, not as independent glyphs. When the source enumerates paired or repeated indexed terms such as (l_{1a}, l_{2a}), (l_{1b}, l_{2b}), (l_{1c}, l_{2c}), verify the whole sequence against the rendered source PDF: all pairs, suffixes, commas, parentheses, and continuation prose must be present. A candidate that collapses the group to one pair plus an ellipsis, loses pair suffixes, swaps indices, or leaves punctuation before the inline objects is REVISE even if the remaining objects are editable MathType. Repair with targeted inline MathType donors when practical; for tiny scalar/index sequences, a source-backed styled Word math fallback is allowed only when recorded in the QA artifact and rendered against the source.
When an existing inline MathType OLE has correct mathematical content but leaves a visible gap before punctuation, do not downgrade it to styled Word math as the first fix. Move punctuation into ordinary Word text at the source-correct side of the object, then try tightening only the inline preview geometry (v:shape width or equivalent render-box metadata) while preserving the OLE/media bytes. Render the affected line to prove the comma/period/semicolon is visually attached and the formula is not clipped. Replace the OLE only if the source formula itself is wrong or the preview geometry cannot be made source-faithful.
If the punctuation is source-correct but Word still wraps a comma/period away from a very short inline OLE, treat it as a typography defect. Prefer tightening the preview box or a styled Word math replacement for simple symbols; when preserving the OLE is required and the visual result is otherwise correct, a local no-break punctuation grouping may be used, but it must be recorded in the QA artifact and visually checked because PDF text extraction may expose the invisible joiner.
Inline punctuation repairs must include a full-sentence source check. A comma or period defect around an inline formula often coexists with missing source-visible continuation text after later inline objects in the same paragraph. Compare the entire rendered paragraph with the source PDF and restore any missing prose, conditions, numeric lists, references, or natural-language formula connectors as Word text plus inline MathType or stable styled math in the source position.
For prose lists containing several inline MathType objects, verify the whole source sentence, not just the first comma. A source pattern like three ratios, i.e., L/K = 29/9, 28/10, and 27/11 must render as localized prose plus ordinary Word punctuation between inline objects: colon or introductory comma before the first object only when grammatically required, comma+space between list items, the localized conjunction before the last item, and the sentence comma/period after the completed inline object. Reject отношения:, <math> <math> и. <math>, при, <math>, выбрано, <math> что, or близко к. <math> style outputs even if each individual inline object is mathematically correct.
Plain text around formulas can carry the same source-math defects even when all OLE counts are clean. If a rendered sentence contains formula-like Latin letters, stars, region labels, indices, or OCR substitutes as ordinary prose, compare the full sentence with the source PDF before deciding it is translation. Rebuild the sentence as target-language Word prose plus source-faithful inline MathType or styled Word math for each mathematical token, including subscripts, superscripts, region letters, accents, and punctuation placement. Update the owner script; a candidate-only text replacement is not durable.
Single-letter inline variables in prose are high-risk OCR targets. Source I, l, 1, F, P, U, Greek letters, or indexed one-letter symbols can appear in the candidate as /, |, blank OLE gaps, dropped bases, or punctuation-like fragments while text extraction remains misleading. Verify the rendered source crop and candidate line visually before accepting or rejecting. For simple scalar symbols, use source-faithful styled Word math when it preserves baseline and spacing; for indexed/accented/vector forms use inline MathType unless a rendered styled fallback is explicitly recorded. Keep surrounding grammar and punctuation in ordinary Word text.
Cases and piecewise displays need the same source/translation check. Do not silently replace source-visible natural-language conditions such as "if ..." or "otherwise" with math-only inequalities, or vice versa, unless the source, accepted exemplar, or user explicitly approves that normalization. In translated chunks, translate condition words when they are part of the formula's visible meaning. Keep them inside the MathType object only when they belong to the cases layout; otherwise move connector text to stable Word runs outside MathType. Render-check the full cases block after any change.
Right-side boundary-condition braces are the same defect class as left-side cases braces. When the source groups two or more equations with a right curly brace before a condition, build it as a real delimiter/array MathType template such as an equation array with a right brace slot, not as flattened aligned text or a typed curly glyph. Keep the equation number outside MathType and render-check the brace height against the source PDF.
Do not put translated Cyrillic condition text through MathType's TeX import path (SetMTTeXData). On some MathType installs the TeX path preserves large brace/templates correctly but renders Cyrillic text as mojibake (for example CP1251-looking Latin glyphs such as äëÿ) or red raw text. For translated condition words inside cases, prefer MathML mtext via SetMTData; when MathML breaks the fragile brace layout, use the TeX path for the math-only MathType object and place the translated condition words as ordinary Word text in a stable formula-cell layout outside MathType. In both variants, render the donor and the target page before accepting the repair.
After an XML-only repair changes layout, table structure, figure/caption grouping, page markers, or number cells while preserving OLE binaries, the output is a structural candidate only. It must be exported/rendered from that exact scratch DOCX and checked against the source PDF before promotion or final review. If the render rejects the structure, update the repair rule or template instead of rerunning the same XML patch.
XML parse success and ZIP integrity are not enough for XML-only candidates. Before handing a candidate to the render gate, run a semantic OpenXML sanity check for Word-openability defects introduced by serialization: every prefix listed in mc:Ignorable must be declared in the same root scope; bookmark/comment/permission/proofing/move range starts and ends must be balanced or proven unchanged from a Word-openable base; typed attributes must not be serialized as empty strings, especially numeric spacing/indent values such as w:before="" or enum values such as w:jc w:val=""; sectPr must remain body-level and final; table cells must have terminal block content; object/image relationships must resolve to existing parts; OLE/VML shape IDs and drawing IDs must remain coherent. A candidate with missing mc:Ignorable namespace declarations, invalid empty typed attributes, orphaned range markers, dangling relationship targets, or malformed object anchors is REVISE even if every XML part parses.
For every newly inserted MathType donor object, explicitly verify both relationship and shape identity: the o:OLEObject relationship must point to the inserted embedding part, the preview image relationship must point to the inserted media part, and o:OLEObject/@ShapeID must match the sibling v:shape/@id. If mismatches already exist in the base, record them as inherited for a scoped donor/intermediate candidate; do not add new mismatches. Before promoting a cumulative candidate to the next review gate, either synchronize inherited ShapeID mismatches with an XML-only package-coherence repair that preserves OLE/media bytes, or keep the candidate at REVISE with the mismatch count and affected objects recorded. Do not let "inherited" mean "acceptable in the current gate" when a reviewer blocks on package identity coherence.
When inserting the same donor MathType object more than once, treat donor XML runs as single-use. Retargeting helpers normally mutate r:id, r:embed, and shape identifiers in the run being inserted, so each insertion must start from a fresh deep copy of the original donor run. Reusing an already retargeted run can point the next insertion at release-document relationships that do not exist in the donor package, or duplicate shape/relationship identity.
When a defective formula is one row of a shared multi-number display table, replace only that row's formula OLE and its relationships/media. Preserve the sibling rows, sibling equation numbers, and accepted OLE objects in the same table. Do not collapse the shared table into a single object or rebuild neighboring formulas just because the number cell text contains several labels.
When replacing a numbered display with a full source-backed donor, inspect immediately adjacent textless unnumbered tables. A stale unnumbered table with one MathType OLE can render as a duplicate first or last fragment of the same formula after the numbered donor is replaced. If the source PDF has no separate display there and the new donor contains the duplicated fragment, remove only the stale unnumbered table plus its OLE/media relationships, then render the affected page.
Before any bounded or full Word/MathType writer uses a prepared placeholder/source DOCX, run a direct Word-openability probe on that exact DOCX. If Word refuses to open it before any placeholder replacement or SetMTData call, classify the lane as REVISE: source package openability defect, not as a formula-import or MathType defect. Do not rerun the same writer slice until the package owner is repaired or a Word-openable base is selected. For one-to-few targeted formula fixes, a standalone one-object MathType donor may still be built in a fresh Word document and inserted into the current Word-openable release candidate, with the source-package openability defect recorded separately.
Run a full chunk writer only when at least one of these is true:
Before starting such a full writer, record the reason, the non-Word blockers already closed, the affected chunk only, the expected formula count, and the cleanup plan for Word/MathType processes.
Treat each Word/MathType writer or render lane as owned by the session that started it. No-Word, source-map, review, or layout workers must not stop, kill, restart, or "clean up" a Word, MathType, LibreOffice, Python, or PowerShell process that belongs to another active lane.
Before any cleanup:
REVISE/BLOCKED; do not interfere with it;If a writer exits with a negative code or no traceback while another worker had cleanup rights nearby, treat the evidence as contaminated until a clean bounded probe is rerun with no competing cleanup worker.
Any call to Word COM ExportAsFixedFormat (or equivalent render/export API) must specify an explicit, absolute OutputFileName argument pointing to a path under .scratch/<worker_topic>_<date>/. Never rely on the default path: Word saves the PDF next to the source DOCX when no output path is given, which contaminates the release folder boundary.
Required form:
doc.ExportAsFixedFormat(
OutputFileName=str(scratch_dir / "chunk_NN_post_<op>_render.pdf"),
ExportFormat=17, # wdExportFormatPDF
...
)
Release folder rule: the repo's accepted release DOCX folder must contain only its canonical release files (the chunk DOCX set and, where the variant produces them, a rendered-PDF subfolder) per the project's own naming convention. Any .pdf, .tmp, ~$*, .bak, or other non-canonical file produced by a render/export run is a stray and must be moved to the repo's scratch area or deleted. Keep the concrete release-folder path and canonical filename pattern in the repo pipeline/runbook, not in this skill.
Clean prepare-only output and clean MathML payload audits prove only that the source-map XML is well formed. They do not prove that Word/MathType can import one very large dense mtable, rotated matrix, or broad multi-row display as one editable MathType object.
Before marking a chunk READY_FOR_WRITER, inspect the first high-risk display payloads for dense matrices, many columns, rotated displays, nested bracketed arrays, and prior stall history. If a prior writer attempt stopped at before_set_mathml for a UID and never wrote a matching saved event, that UID is not writer-ready in the same one-object form even when audits are clean.
Required handling for dense display payloads:
Do not blind-rerun the full writer on a known stalled dense matrix. Do not let a worker report READY_FOR_WRITER if its only evidence is 0 payload issues and it has not addressed the import-size/template risk.
For very large source-backed display templates such as dense matrices, do not keep retrying a hung MathType SetMTData MathML import. First prove the source payload order and dimensions from the current source-map or existing OLE payloads; if a one-object MathML import stalls, record the progress point and process cleanup, then try a compact MathType TeX donor (SetMTTeXData) built from the same verified rows/cells before falling back to layout-only strategies. The donor must render as one editable Equation.DSMT4 object with a continuous delimiter/template, and the target repair must replace only the defective formula object's OLE/media parts while preserving unrelated protected parts byte-identically. Do not accept VML/XML rotation of MathType OLE previews unless the exact donor and target DOCX render proves the formula is visible, scaled, and source-faithful; a rotation property that exports blank or clipped output is a failed lane, not a candidate.
Before using Word/MathType automation to create donor OLE objects for a targeted repair, run or reuse a bounded one-object smoke that imports a simple inline symbol and reaches a saved DOCX/PDF artifact. The smoke must use the same initialization path as the accepted writer: configure MathType/MathPage library discovery, call the MathType API initialization macro such as IsDLLVersionOK, record the result, insert a blank MathType object, then call the import macro such as SetMTData. A smoke that skips the initialization macro is not valid evidence of a global MathType import failure.
A progress log that records successful API initialization, then stops at before_set_mathml and never records an after_set_mathml or saved-object event is a MathType import failure, even when the source MathML/TeX is trivial.
Every donor must pass a rendered donor gate before it can be transplanted into a chunk. MathType SetMTTeXData may accept a payload but render raw control text such as \begin{aligned}, &, or \end{...} as visible red text. If the donor PDF shows raw TeX/MathML residue, reject that donor and switch to an explicit MathML template, a simpler source-faithful split, or a manual MathType sample. Do not let a clean Equation.DSMT4 count override the visible donor render.
If a simple inline donor stalls in the same MathType import path:
REVISE: MathType import environment blocked unless a visually verified existing editable MathType OLE donor can be reused;A fallback made from styled Word text, split inline runs, or a hybrid of existing OLE plus Word superscript/subscript may be used only as an explicitly recorded temporary candidate when it visually matches the source and no editable one-object donor can currently be generated. Do not call such a fallback final MathType PASS.
Treat this skill as a portable operating procedure.
FINAL_DOCX, SOURCE_PDF, SAMPLE_DIR, and SCRATCH_DIR.Before editing:
REPO_ROOT to the Git root when available; otherwise use the current workspace root.Use repo-relative variables in notes and scripts:
FINAL_DOCX: final translated DOCX for the page or document segment.FINAL_PREVIEW_PDF: rendered PDF preview for FINAL_DOCX.SOURCE_PDF: original PDF page source.SAMPLE_DIR: repo-local directory containing editable MathType sample DOCX files.SCRATCH_DIR: repo-local scratch directory for candidates and rendered page images.VALIDATION_JSON: repo-local validation summary.Do not bake absolute workstation paths, usernames, drive letters, or installed MathType paths into shared scripts or docs. Discover MathType from the local installation or accept a documented environment variable override.
Repo-local repair scripts must accept repo-relative scratch/candidate output paths and resolve them to absolute paths before writing files or formatting relative_to reports. A script that writes a valid candidate and then fails only because a relative output path is not under an absolute repository root is a pipeline defect; fix the path handling before handing the script to workers.
If a repository has no runbook, no exemplar, no sample directory, no validation JSON, or no scratch convention, create only the minimum repo-local working area needed for the current task, document the new convention in the repo pipeline, and keep this skill free of those local names.
A translated technical-book chunk cannot pass on formulas, MathType counts, or layout alone. The worker must prove that the visible source text was translated and preserved in source flow.
Before final review, build or inspect a prose ledger for the current chunk:
where, or, for, if, with, respectively, and their localized equivalents;For each source-visible unit, the candidate must contain a target-language equivalent at the source-equivalent position. Missing prose, untranslated source-language body text, duplicated source plus translation, machine-OCR residue, invented explanatory text, and semantic reversal are all REVISE, even when every formula is editable MathType.
Do not mechanically translate mathematical notation, program source code, file names, command lines, numeric output, author names, standard acronyms, or source-language bibliography titles when the repo convention preserves them. Those are exceptions only when the surrounding prose/caption is translated and the QA artifact records why the source-language token remains.
Author names remain as names, but affiliation/organization/location lines in title blocks are ordinary source-visible prose. Translate the role/location words into the target language, preserve official institution/company names when that is the repo convention, and record any intentionally preserved source-language institution name as a translation exception. A chapter title block with translated title and untranslated affiliation prose is REVISE.
Translation repair is normally a no-Word XML/source-owner lane: update the generator/source-map/translation block that produced the bad text, not only the final DOCX. Render the affected pages after the repair and compare the source PDF visually. A worker report must explicitly state whether the translation-completeness gate was checked; if it only says formulas were converted or visually repaired, the chunk remains REVISE.
Every chunk handoff must include a short translation ledger, even when the assigned repair was formula-heavy. The ledger must name the source pages or rendered source crops checked, list the visible text regions covered, state any intentionally preserved source-language tokens as exceptions, and list remaining unchecked or suspect text regions. A report with no translation ledger is not a complete skill result. Do not infer that text is acceptable from clean formula/OLE counts, page counts, or a formula-only visual review.
If the worker was asked to fix only formulas, it may return CANDIDATE for formula repair only, but it must still mark translation/text coverage as unchecked unless it actually performed the ledger pass. Such a candidate cannot be promoted to final chunk PASS until a later gate completes the translation ledger and repairs missing, untranslated, OCR-like, duplicated, or semantically reversed prose.
3.1. as a local 1.. If autonumbering drifts, replace it with source-backed explicit heading text plus the correct Word heading style/outline level, then render-check that the heading is black/source-like and not accidentally inherited as hyperlink-colored or italic text.2.1 is absent, insert it as a standalone Word heading with explicit source numbering and render-check the page.following coupled separated from homogeneous equations by a misplaced figure/caption), repair the whole source paragraph or list block in source order. Keep real headings, list items, figures/captions, and display formulas as separate structures, but do not let a figure/caption table interrupt the middle of one grammatical sentence unless the source page visibly does so.2. renders as an unnumbered body paragraph, restarts at the wrong number, or inherits a hidden/bullet style while neighboring items look correct. Compare source and candidate labels visually, inspect w:numPr/style inheritance for the affected paragraphs, and repair the smallest list block that restores the visible source numbering. For a pure list-numbering defect, preserve all formula OLE/media bytes and render-check the affected page before promotion.Z Matrix, S-parameters, field components, or similar symbol-bearing labels, the translated Word text must keep the symbol as editable text or styled inline math. A fragment such as и -матрицы, -матрица, or -параметры is a source-math omission when no immediately adjacent inline math/styled symbol supplies the missing label. If an inline MathType/styled symbol already renders the label, do not add a duplicate text symbol; render-check the spacing, style, punctuation, and run order instead. Repair any case where the rendered label drifts after a comma or prose token (for example, матрицы, Z соответствующий) by moving the inline symbol/run to the source-faithful position. Scan for known math-label nouns that begin with a bare hyphen after OCR/translation cleanup and verify each against the source PDF before release.keepNext, cantSplit, or an explicit source-faithful page break to keep the table/caption block readable before promotion.w:lineRule="exact" and a line value smaller than normal single spacing is a layout defect even when XML rows/columns are correct. Widen the table to the effective page or column width, set stable column widths, use normal single spacing, preserve source-like horizontal rules, and render-check the whole table plus the following paragraph._, -, •, restarted list numbers, and merged multi-reference paragraphs when they replace source reference numbers.Литература) unless the source-language heading is intentionally preserved. A correct numbered reference list is still REVISE if the heading is absent or glued into the first reference item.sectPr first on a scratch candidate and render that exact file before changing formula sizes, figure crops, or writer output. Use an adjacent accepted page setup only as a template after verifying it matches the current source geometry. After page setup changes, re-normalize display-formula and figure/caption tables to the effective column width; old full-body widths can remain in table XML and still cause page-flow defects.REVISE; repair the source-map/OLE so the text exists only in the source-faithful Word position.|x| < w/2 y = d+t after adding a Word label При |x| < w/2 и y = d+t:; that is duplicate condition content and a source-map/template defect.where, if, region labels, or connector text; inspect the rendered source page and place the text on the same side of the formula, before any following heading or paragraph that the source places later.or, where, for, if, source, Green's function, or localized equivalents between formulas, split the display into separate MathType placeholders and put the connector/condition as Word text in the formula cell; do not bury it inside one opaque MathType OLE. Preserve true mathematical operators and conventional symbols such as sin, cos, exp, grad, curl, div, TE, TM, and variable names when the source uses them as notation rather than prose.where/где definition row, do not attach the next equation number to the definition row. Split the block into source-order rows: each numbered equation gets its own MathType display and right-cell Word number, the connector word stays ordinary localized Word text, and the definition row has an empty number cell. A visually plausible definitions row labelled as (N) is a hard source-numbering defect even if the following formula numbers remain sequential.if, l = n ,, or W_i ,. Use source-faithful styled Word math for simple relations and symbols (l = n, W_i, x_>, x_<) when that preserves typography and keeps punctuation tight; remove the superseded OLE/media relationships and render-check the exact line.let, with, where, or, or an equivalent localized word visually belongs between rows of one multi-row display table, keep it as ordinary Word text in the display/formula cell at that source position. Do not move that connector into MathType, drop it into a detached body paragraph, or rebuild unrelated formula OLE objects when an XML-only insertion can preserve the current MathType binaries.<mtext>; reject any donor that mojibakes non-ASCII text or turns the brace into a small typed curly symbol instead of a stretched cases template.keepNext from each label row/paragraph to the following formula row and cantSplit on the comparison rows so a label such as DN, ND, DD, or NN cannot orphan at the bottom of a page. Render the exact candidate pages after the keep-together change, because XML table validity does not prove the label/formula block stayed readable.from (N) or where (N) does not satisfy the display requirement. If a numbered formula is missing from the candidate, insert a MathType display table at the source-flow point and keep the equation number as ordinary Word text....x\cos\theta v=... or otherwise joins the last symbol of the first equality to the first variable of the second equality is REVISE even when it is a valid editable MathType object.requiring, where, for, or, if, respectively, source, or function remains REVISE.for all x / for all i is not the same as the trailing variable x / i. If a text-payload cleanup strips the words and leaves only the variable inside MathType, the formula is still defective. Split the affected block into math-only MathType objects and place the localized condition as ordinary Word text in the same visible row/column of the formula cell, or use another rendered-proven Word-text structure that preserves the source alignment. Do not delete detached condition paragraphs until the rendered candidate proves the condition has been reattached at the source-equivalent row.ith element, on S, or at nodes as high-risk. Prefer a source-defined symbolic domain (s \in S, S_i, \Gamma_i, etc.) when it preserves the source meaning. If no source-defined symbol exists and the text is genuinely part of the integral limit, it may remain inside the MathType template only as localized target-language text, with the exception recorded in QA; never leave the source-language prose label inside the OLE of a translated document.<mtext> inserted through MathType's MathML import path, or a manually verified one-object MathType sample. Always render the donor and final candidate and scan for mojibake, replacement glyphs, or clipped text. If localized text cannot be imported stably, use a source-backed symbolic condition instead and record the substitution in QA.Рис. N показывает..., Рис. N дает..., or Рис. N представляет... is usually a prose reference and may remain ordinary body text when the source uses it that way. A caption-like paragraph such as Рис. N. ... or Fig. N ... must either live inside the grouped figure/caption structure or be repaired.