/**
 * UTF-8 decoding compat for the Emscripten 6.0.2 resizable wasm heap.
 *
 * Under Emscripten 6.0.2 the browser wasm heap is exposed as a *resizable*
 * ArrayBuffer (a growable SharedArrayBuffer on the threaded build — see
 * `wasmMemory.toResizableBuffer()` in the generated glue). Strict browsers'
 * `TextDecoder.decode()` throws a TypeError when handed a view backed by such a
 * buffer ("...can't be a resizable ArrayBuffer"). Anything that decodes a heap
 * view then throws and, when that happens inside geometry extraction, the face
 * is silently dropped — producing see-through models in Chrome/Firefox, while
 * Safari (which tolerates it) and Node (whose heap is not resizable) are fine.
 *
 * Two decoders hit this:
 *   1. Our own STEP string/enum decodes — routed through `decodeUtf8` below.
 *   2. Emscripten's `UTF8ToString` / embind `std::string` returns in the wasm
 *      glue, which we do NOT own — covered by the global prototype shim, since
 *      the glue calls `TextDecoder.prototype.decode` like everyone else.
 *
 * Both copy the bytes out of a resizable/growable buffer first; plain buffers
 * (Node, Safari, pre-6 builds) keep the zero-copy fast path.
 */
/**
 * UTF-8 decode a byte view, tolerating wasm-heap-backed resizable/growable
 * buffers that `TextDecoder.decode()` would otherwise reject.
 *
 * @param view The bytes to decode.
 * @return The decoded string.
 */
export declare function decodeUtf8(view: Uint8Array): string;
/**
 * Install a global, idempotent `TextDecoder.prototype.decode` shim that copies a
 * view out of a resizable/growable buffer before decoding. This covers decodes
 * we do not own — chiefly Emscripten's `UTF8ToString` and embind `std::string`
 * returns in the wasm glue, which read straight from the resizable wasm heap and
 * would otherwise throw mid-extraction and drop geometry. A no-op where
 * `TextDecoder` is absent or the buffer is plain.
 */
export declare function installResizableTextDecoderShim(): void;
//# sourceMappingURL=decode_utf8.d.ts.map