Where a string is cut decides whether the leftover is still usable

What it is

The user never gets the original string. They get whatever substring still fits after the engine throws the rest away. Truncation cut position is the choice of which substring that is, and therefore whether the leftover can still identify the item. quarterly-report-final-v3.pdf cut from the tail leaves quarterly-rep… (genre survives); cut from the head leaves …final-v3.pdf (version survives). A cut in the middle of a token kills both. The ellipsis glyph carries no information; only the survivor does.

Why it happens

Most toolkits default to tail truncation: keep the first few characters from the reading start, drop what overflows. That default is a Western-script bet that word onsets carry the stem, not a general information strategy. Strings have internal structure — brand first in a product name, volume first in a path, disambiguating digits last in a ticket id. The remainder is a sample of that structure. If uniqueness lives in the tail (order ids, extensions, numeric suffixes), keeping the head discards the only useful bits. Ten photos whose names share IMG_202609 become ten identical stubs. The failure is not that ellipsis looks cheap; it is that stub recognition is recognition of the stub, and different cuts produce non-interchangeable stubs.

Studying it

Use real item names from the product, not placeholder copy. Apply three policies at the same remaining-character budget: keep-head, keep-tail, break-at-word-boundary. The task is identification from the stub alone against a set of near-neighbours. Independent variables: cut policy and string class (title, path, identifier, CJK personal name). Dependent variables: accuracy, time, confidence. Split the analysis by class: a policy that wins on English titles routinely loses on SKUs.

Where it stops holding

If the whole string fits, there is no remainder and the cut does not exist. Unstructured tokens (random strings, UUIDs) are equally uninformative from any cut; those need a different presentation, not a less-bad incision. Strings that rewrite themselves (tickers, countdowns) move the distinctive span over time, so a static policy can be right at 09:00 and wrong a minute later. Word-boundary cuts need a tokenizer; unspaced CJK and mixed scripts do not hand the engine a free boundary.

Applying it

• Tag each truncated field by where its distinguishing span lives — head, tail, or both — and pick a cut per field rather than one global ellipsis style.
• Pour fifty live records into the narrowest production width and write down the leftovers. If two different records collapse to the same stub, the cut is in the wrong place.
• When a leftover is unusable, shrinking type only postpones the same collision.

Related

• Same group: F4.10.2 Middle ellipsis keeps the distinctive start and end · F4.10.3 Truncated copy still needs a path to the full string · F4.10.4 Decision-critical text such as prices and warnings must not be truncated · F4.10.5 Assistive technology must still receive the untruncated string · F4.10.6 CJK characters pack more meaning per glyph, so the same character budget loses more · F4.10.7 Multiline clamp must recast with type size, not a fixed pixel height
• Nearby: F2.16 Extreme content and overflow · F4.03 Measure
• Search terms: truncation cut position · end ellipsis · text-overflow