A weighted manuscript count is not the same thing as a file's raw character count. For a full-width half-width weighted character count, Rune Studio's current Mac documentation says the editor can switch between a raw count and a display that weights full-width characters as 1 and half-width characters as 0.5. The retained run did not operate that graphical display: it measured a 24-character file through the command interface and independently reconstructed 14.0 from a declared ASCII/non-ASCII rule. This article therefore does not claim that the application window showed 14.0. It separates the reproducible command-line receipt from the screen check a reader must perform on their own Mac.
Freeze the Twenty-Four Characters Before Doing Arithmetic
The measured specimen is a UTF-8 file with LF line endings and SHA-256 fc82d74efa90d066f6b7786e6a15a8f24e9e16631381e32edce67829ae0999ea. Reading its content and excluding the separators produced a raw count of 24 characters. That value is the receipt for the input. If the input is edited while the formula is being checked, a correct calculation can still answer the wrong question.
Place the original string in the left column of a calculation card. In the right column, classify each character as ASCII or non-ASCII under this particular rule. “Half-width” is shorthand for the measured classification used here; it is not a visual judgment about how narrow a glyph looks. A destination that treats half-width katakana, combining marks, emoji sequences, or tabs differently needs a different card and a separately named test.
Reconstruct 14.0 Without Borrowing a Screen Value
Let F be the number of non-ASCII characters and H the number of ASCII characters. The independent calculation is F + H × 0.5. Applied to the fixed 24-character specimen, it returned 14.0. The evidence therefore supports two statements: the source readback was 24, and the declared weighting formula produced 14.0.
Rune Studio's current Mac documentation describes the two character-count displays. This command-line run did not operate or capture the graphical weighted-count display. Consequently, the result must not be rewritten as “the Rune Studio window showed 14.0.” For the screen check, open the specimen with the same digest in the current Mac build, clear the selection, and record both raw and weighted displays. Then select a range once without a line ending and once with a line ending, confirming that no IME composition remains pending. Keep the application version, screen name, selected boundary, displayed unit, and observed value together. If the value differs from 14.0, preserve it and compare the application's classification rule with the public documentation. Until this check is performed, the graphical value remains unmeasured even though the reconstruction is reproducible.
Diagnose a Disagreement Before Cutting Prose
When another counter disagrees, do not immediately shorten the manuscript. Check three things in order. First, determine whether line separators or a final newline were included. Second, compare the ASCII boundary character by character. Third, state how fractional results are rounded. These are counting-policy questions, not editorial defects.
Keep the failed calculation sheet. Make the correction on a second sheet and change one premise at a time. If line endings caused the mismatch, leave the classification untouched. If one character was placed in the wrong bucket, correct that row but do not silently change the source. The recovery is complete only when the same 24-character input again produces the expected 14.0 under the declared rule. That preserves the evidence for the mistaken result as well as the accepted one.
Use a Challenge String Before Scaling to a Manuscript
A production check should begin with a short line that contains Japanese prose, an ASCII URL, digits, punctuation, and any characters that the recipient's rules treat specially. Write the expected weight beside every character before running a tool. This small challenge string reveals a rule mismatch much faster than a novel-length total.
After the challenge passes, take a digest of the real manuscript and run the same classification without editing it. Record raw characters, excluded separators, weighted value, and any unresolved category. If the manuscript changes, start a new receipt. Reusing yesterday's 14.0-style result for today's source would be convenient but unverifiable.
Send the Rule Alongside the Number
A handoff that says only “count: 14.0” is incomplete. It should identify the source digest, classification boundary, newline policy, equation, fractional policy, and result. It should also say that the graphical display was not observed in this run. Those fields let another editor reproduce the number and decide whether the rule matches the destination's requirement.
Acceptance is intentionally narrow: a second operator can read the same 24 characters, apply the same weights, and obtain 14.0. It does not establish retailer acceptance, every editor's counter, or visual behavior on an unoperated screen. The workflow is useful precisely because the measured arithmetic and the unmeasured interface remain separate.
Keep Selection Counts Out of the File Receipt
A graphical editor may offer both a whole-document count and a count for selected text. A later UI test should capture those as different observations. Record the document digest and full count first. Then record the selected opening and closing words, confirm any pending IME composition, and capture the selection value. If the selection changes, the old number no longer identifies the same input.
The current 24-to-14.0 evidence is a file-based reconstruction, not a selection test. It should not be reused to imply how an unoperated selection counter behaves. This distinction is especially important during composition, when temporary characters may be visible without being committed to the saved file.
Recalculate Every Revised Delivery
The proportion of ASCII text can change sharply when an editor adds URLs, ISBNs, product codes, or English headings. Do not scale the 14.0 result by manuscript length. Take the revised delivery digest, classify that exact revision, and report unresolved characters separately. Full-width Latin forms remain non-ASCII under this specimen's rule even if they resemble ordinary Latin letters.
Archive the final calculation card with the delivered source. If a recipient disputes the number, both sides can inspect the same rows instead of arguing from screenshots produced from different revisions. That traceable receipt is the real benefit of the weighted count.