DEV Community: dev truth

A floor plan is more than pixels: getting DXF exports to preserve meaning

dev truth — Sun, 13 Sep 2026 14:22:42 +0000

A wall can look right in a browser and still arrive in CAD at the wrong size. The difficult part of an export feature is preserving what the geometry means.

I’m building FloorDraft, a manual 2D floor-plan editor. These are concrete details from its current exporter, plus a small acceptance checklist you can adapt for another drawing application.

Keep three scales separate

There are three different quantities involved: the relationship between drawing coordinates and real dimensions, the viewport zoom, and the scale used to print the result. Only the first belongs in a model-to-CAD conversion. Panning or zooming the view should never change the exported length of a wall.

FloorDraft stores a millimetres-per-pixel calibration alongside the design. At the DXF boundary, it divides that calibration by 1, 10 or 1000 for millimetres, centimetres or metres. The resulting multiplier is applied to geometry, while the file’s unit setting is updated to match.

For example, a 320-coordinate-unit line with a calibration of 12.5 mm per unit represents 4000 mm. Its exported length should therefore be 4000 in a millimetre file, 400 in a centimetre file, or 4 in a metre file. Merely changing the unit metadata while leaving the coordinates unchanged does not preserve this contract.

Text height and dimension offsets need the same attention. A 100 mm annotation height becomes 0.1 units in a metre-based drawing. Geometry can be correct while annotations become enormous if they cross a different conversion path.

Treat the vertical-axis change as geometry

The exporter maps a point to (x * scale, -y * scale, 0). Negating the vertical coordinate bridges the editor’s downward axis and the CAD drawing’s upward axis.

That reflection affects more than endpoints. FloorDraft also negates furniture insertion angles. Door arcs calculate their angles using the reflected vertical difference and choose the short sweep. Reflecting a centre point but keeping an unconverted rotation can leave an object in the right place with the wrong orientation.

A plain rectangular room is a weak visual fixture for this. Use something asymmetric: a door near one end of a wall and a rotated piece of furniture. Then check hinge position, opening direction and rotation in the receiving application.

A door symbol does not necessarily cut a wall

The data relationship matters. In FloorDraft, an opening associated with a wall contributes an interval that is removed from the wall geometry during export. A free opening is exported as a symbol and produces a warning; it does not automatically cut the wall behind it.

That distinction is useful for editing, but it must survive the handoff. Otherwise a user sees a door on screen and reasonably assumes there is also an opening in the exported wall.

Before export, the current checks reject a non-positive or non-finite calibration, a missing referenced wall, linked openings outside their wall, and overlapping openings on the same wall. Estimated dimensions and free openings are warnings rather than silent claims of accuracy.

This separates two questions: can the geometry be exported coherently, and how much should the recipient trust its measurements? A calibrated reference still needs on-site verification.

Verify distance, structure and appearance separately

For a compact acceptance fixture, I would use one known-length wall, a linked door, a free opening and a rotated furniture object. Then check:

Distance: export in mm, cm and m; the known wall has the same physical length in each receiving document.
Structure: inspect wall outlines and the linked opening, rather than only checking that a door symbol exists.
Orientation: verify the hinge and rotated furniture against the source design.
Readability: inspect text and dimension sizes, not just wall coordinates.
Warnings: confirm estimated dimensions remain identified in the output.
View independence: change viewport zoom and export again; model geometry should remain equivalent even if file metadata differs.

These are suggested acceptance checks, not a claim that every CAD application has been tested. A parser can verify numbers, but opening the fixture in the application your recipient uses catches practical interoperability problems.

Make the handoff understandable to the user

A PNG shares appearance. An image-based PDF packages that appearance as a document. DXF provides geometry for continuing in CAD. Those are different deliverables, so the interface and help text should explain which job each format serves.

For the user-facing version of these checks, I put together FloorDraft’s DXF export guide, including units, layers and a sample file to try in the receiving software. Editing is free without an account; free PNG, PDF and DXF exports require Google sign-in.

The question I now use when reviewing an exporter is: which meaning can this file lose while still looking plausible? For a floor plan, units, opening relationships and measurement confidence are good places to start.

Disclosure: prepared with AI assistance and checked against the current exporter and product documentation.

A waveform is not a silence detector: building browser audio edits

dev truth — Sun, 06 Sep 2026 15:59:19 +0000

A waveform is a useful overview of a recording. It is a poor source of truth for deciding which samples to delete. A display can normalize a quiet file until it looks loud, or compress several seconds into one bar. Feeding those bars into a detector would make presentation choices affect the edit.

This is an implementation case study from my project, AudioCut. An AI agent drafted this article from the current decoding, analysis, interval-removal and export code. The numerical example below also appears in an existing unit test; the limitations are part of the implementation, not benchmark claims.

1. Keep analysis data separate from display data

AudioCut analyzes decoded audio in 20 ms windows. Each window gets an RMS value: square the samples, average them, then take the square root. The implementation accumulates the squared samples across all channels before taking that average.

The interface has a different job. It reduces the analysis to 180 display bars, takes the maximum window level within each bar, normalizes the bars against their visual peak, and applies a small minimum height so the waveform remains visible.

Those transformations are useful for a chart. They discard information that the detector needs. Normalization removes the absolute level relationship, and aggregation reduces time resolution. The detector therefore consumes the original window-level array, not the displayed waveform.

This also makes a useful architectural boundary: changing the chart's bar count should not change the removal intervals.

2. Define quietness and duration independently

The detector converts the selected dB threshold to linear amplitude with 10 ** (thresholdDb / 20). At -40 dB, that threshold is 0.01. A window qualifies when its RMS is at or below that value.

Duration is a separate rule. The minimum number of consecutive windows is ceil(minimumSilence / windowSeconds), with a lower bound of one. A 0.5-second minimum therefore requires 25 consecutive 20 ms windows. A 0.2-second quiet run should not qualify just because it is very quiet.

The implementation tracks the start of each quiet run and commits it when a louder window arrives. It also flushes the pending run at the end of the array. Without that final step, trailing silence would disappear from the detector's results.

There is a stereo tradeoff here. Combining squared samples avoids cancellation between opposite-polarity channels, which can happen if channels are summed first. But a silent channel still lowers the combined RMS relative to measuring the active channel alone. A detector that must protect speech present in any channel may need a different aggregation rule, such as the maximum of per-channel RMS values. That would be a design change, not the current behavior.

3. Padding changes the deletion interval

A detected quiet run is not yet the range that should be removed. AudioCut moves its start forward by the padding and its end backward by the same amount. Both endpoints are clamped to the media duration. The remaining deletion must span at least one analysis window.

An existing regression fixture makes this concrete:

50 windows at amplitude 0.001, followed by 10 windows at 0.5.
Window duration: 0.02 seconds; total duration: 1.2 seconds.
Threshold: -40 dB; minimum quiet duration: 0.5 seconds.
Padding: 0.1 seconds at each end.
Expected deletion: 0.1 to 0.9 seconds, or 0.8 seconds removed.

Notice the order: the minimum-duration check applies to the quiet run before padding. Padding then decides how much of that run survives around the join. These settings answer different questions and should not be collapsed into one vaguely named sensitivity slider.

4. Keep a removal plan before copying samples

The detector returns ordered time ranges. The processing stage derives the complementary ranges to keep, converts their boundaries to sample frames, and copies each channel into a new audio buffer in sequence.

That separation makes the math easier to inspect than deleting samples during detection. The original decoded buffer remains available, and the output can be encoded independently. In this implementation, the result is a newly encoded MP3.

There are practical limits. Detection has window-level resolution; rounding an endpoint to a sample frame does not recover information that the analysis never measured. The copy path also concatenates the retained ranges without a crossfade. Padding can preserve some breathing room, but it does not guarantee an inaudible join. Listening around cuts remains necessary.

5. Budget for decoded audio, not the compressed file

A small compressed input can expand into a large PCM buffer. Before allocating that buffer, the code estimates duration × sampleRate × channels × 4 bytes for Float32 samples.

For example, ten minutes of stereo audio at 48 kHz requires 230,400,000 bytes, about 220 MiB, for one decoded buffer alone. That is an arithmetic example, not a supported-duration promise. Decoder chunks, the edited buffer and encoding also consume memory. A check on the first buffer is a guardrail, not a measurement of peak memory use.

Likewise, recognizing an MP4 container does not establish that its audio track can be decoded. The input path checks the available audio tracks and the selected track's decoding support before processing it. Video input produces audio output; this pipeline does not edit the picture.

A small regression checklist

The existing audio-math test file passes five tests, including the padding fixture and rejection of a short quiet run. Those tests establish specific cases, not complete audio quality or browser compatibility.

Useful additional cases for an audio-editing pipeline include:

Quiet runs at the beginning and end of a recording.
Padding that consumes the entire candidate interval.
Speech in only one stereo channel.
A silent file and a file with no qualifying gaps.
Changing waveform display resolution without changing detected intervals.
Listening to the exported file around every join, alongside numerical duration checks.

For a concrete interface to the controls discussed here, AudioCut's Silence Remover exposes threshold, minimum duration and padding, then creates a separate MP3 for preview and download. Start with a short recording you have permission to edit.

The broader lesson is to keep three things distinct: measurements of the source, the plan for changing it, and the picture used to explain that plan. Each layer can then be checked against its own requirements.

A PDF preview is a rendering contract: lessons from a Japanese worksheet tool

dev truth — Sun, 06 Sep 2026 14:19:52 +0000

A browser preview can look correct while the downloaded PDF breaks a word across pages, changes a glyph, or exports an older edit. For a handwriting worksheet, those are functional bugs: the spacing and character shapes are the product.

This is an implementation case study from my project, 漢字ドリル (Kanji Drill), a Japanese handwriting worksheet generator. This article was drafted by an AI agent from the project's implementation; the concrete design choices below come from its layout, preview, export and storage code.

1. Give both renderers the same document

The app first turns a draft into a layout document. Each page contains positioned cells, text baselines and optional vector paths. The document also records its revision and the font version used to build it.

The screen renders that model as SVG with a 210 × 297 viewBox. The PDF renderer consumes the same page objects and converts millimetres to points using 72 / 25.4. It does not ask the browser to wrap the text again.

This makes a 20 mm writing cell a physical measurement. Resizing the preview changes its screen scale, not the PDF geometry. With 12 mm margins on each side of A4, the available width is 186 mm: nine complete 20 mm cells fit, while a tenth does not.

The useful separation is between deciding where content belongs and drawing it. Once pagination is part of the shared model, a renderer should not invent another line break.

2. Define what must stay together

A single-character exercise and a name exercise have different pagination rules.

For individual characters, a row is a useful unit. For a name or word, the indivisible unit is one complete repetition, which may occupy several rows. At 24 mm per cell, seven characters fit across the 186 mm content width. A 20-character sequence therefore needs three rows for each complete repetition.

If the remaining page space cannot hold those three rows, move the entire repetition to the next page. Otherwise the learner gets the beginning of a name on one sheet and its ending on another.

That rule belongs in the layout builder. It should not depend on which PDF viewer or browser happens to print the document.

3. Treat old output as a different version

Font loading and PDF generation are asynchronous. Editing can continue while either operation is running.

The draft carries a revision number that changes with edits. The preview is eligible for export only when its revision matches the current draft and validation succeeds. During an update, the previous preview may remain visible, but it is marked as previous output and cannot be downloaded as though it were current.

The PDF export also checks whether its revision is still current while processing pages and around the final save. A stale export is discarded. Merely disabling the download button after it is clicked would not handle an edit made during generation.

Japanese input adds another boundary: do not validate half-finished IME composition as final text. The preview hook waits until composition finishes and the text settles before rebuilding.

4. A font family name is not enough

The regular preview draws glyph outlines from the actual font asset, and PDF export embeds that asset. This avoids relying on a fallback font that looks acceptable on screen but has a different shape or width in the file.

This implementation embeds the full Klee One font rather than a subset because its export path encountered missing composite glyphs with subsetting. That is a project-specific tradeoff, not a claim that all Japanese fonts require full embedding. The cost is a larger font payload; the benefit is preserving the checked glyph mapping.

Font checks should inspect the final asset. The project's tests check real glyphs for the 1,026 grade-listed kanji and inspect the embedded font stream in a generated PDF. Those checks complement visual review; they cannot establish whether a worksheet is pedagogically appropriate.

5. Make persistence a separate decision

A reusable layout does not necessarily need reusable personal text. Saving settings defaults to excluding the practice text, title and instruction. Including those fields is an explicit choice.

Storage errors are surfaced without disabling worksheet generation. Restored content is validated again against the current settings and font. Local storage is useful for repeat work, but it is neither cross-device sync nor permanent backup.

The same boundary applies to export names: the filename uses a timestamp instead of a learner's name. Keeping PDF creation local also does not mean the whole website makes no network requests; static assets and visit analytics are separate concerns.

A small regression checklist

Change the text while export is running: the old file must not be offered as the current result.
Use a multirow sequence near a page boundary: one repetition must remain intact.
Resize the preview: physical PDF cell sizes must stay constant.
Restore an old template: validate it against current rules.
Deny local storage: generation must still work.
Compare the downloaded PDF with the preview using the same input and font asset.

For a concrete example, the Kanji Drill worksheet editor exposes the cell size, tracing and preview controls discussed here. Start with 山川日月, then change one setting at a time. The interface is in Japanese.

The design question I would carry to another document tool is simple: which layer owns geometry, and how do you prove that every output belongs to the user's current edit?

What Actually Happens When Whisper Runs in Your Browser?

dev truth — Wed, 02 Sep 2026 01:57:23 +0000

A “browser-based transcription tool” can mean two very different things.

In one version, the browser is only an upload form. Your recording travels to a server, the server runs a speech model, and the browser receives the result.

In the other version, the browser does the actual inference. The media is decoded on the device, a speech model runs locally, and the transcript remains in browser storage until the user exports it.

Those two architectures may look similar on the surface, but their privacy boundaries, performance constraints, and failure modes are very different. Here is the practical pipeline behind the second approach.

1. The application still has to arrive over the network

“Local processing” does not mean “nothing uses the network.”

The browser must first download the application code. A first transcription run also needs the selected Whisper model. Depending on the implementation, fonts, analytics scripts, and other static resources may be requested too.

The important distinction is not whether the network exists. It is whether the selected recording and resulting transcript are sent to a transcription backend.

A useful product should explain that boundary directly instead of reducing it to a “100% offline” badge.

2. The browser decodes the media

Speech models expect audio samples, not an MP4, MOV, WebM, or compressed audio container.

The browser therefore has to inspect the selected file, find the audio track, and decode it into a representation the model can consume. This step can fail before inference even starts. A familiar file extension does not guarantee that the codec inside the file is supported by the current browser.

That is why a robust error message should distinguish between:

a file the browser cannot decode;
a model that failed to load;
a compute backend that failed to initialize; and
an inference job that ran out of memory.

Treating every failure as “transcription failed” makes local tools much harder to debug.

3. Inference should not freeze the interface

Whisper inference is compute-heavy. Running it directly on the main JavaScript thread would compete with rendering, progress updates, buttons, and text editing.

A Web Worker provides a separate execution context for model loading and inference. The page can send the worker a transcription job, receive model-download and segment-progress events, and keep the interface responsive enough to cancel or recover.

A worker is not a performance shortcut by itself. The same CPU or GPU still does the work. Its main value is isolation: expensive model work does not have to monopolize the UI thread.

4. WebAssembly and WebGPU solve different problems

A browser-local Whisper tool commonly offers two compute paths.

WebAssembly

WebAssembly is the compatibility-first option. It runs through the browser’s CPU-oriented runtime and works across a broader range of devices. It is a sensible default when the hardware is unknown or WebGPU is unavailable.

The tradeoff is throughput. A larger model or a long recording may take significant time, especially on a low-power laptop or mobile device.

WebGPU

WebGPU lets supported browsers use compatible graphics hardware for computation. On the right desktop setup it can improve throughput, but support depends on the browser, operating system, driver, and GPU.

WebGPU is not a universal “fast mode.” Initialization can fail, memory pressure can still matter, and a larger model may still be a poor fit for the device.

A practical strategy is simple:

Start with WebAssembly when compatibility matters most.
Try WebGPU on a supported desktop when local inference is too slow.
Fall back to WebAssembly if WebGPU initialization or inference fails.
Reduce the model size before assuming the entire workflow is broken.

This WebGPU vs WebAssembly guide for local Whisper transcription includes a compact comparison and troubleshooting checklist.

5. Model size is part of the UX

Tiny, Base, and Small Whisper models do not only differ in accuracy. They also change:

the first-download size;
memory use;
initialization time;
inference speed; and
the likelihood that the job fits comfortably on the device.

The “best” model is therefore contextual. A smaller quantized model can be a better default because it gets a first-time user to a transcript with less waiting and lower memory pressure. A larger model can remain an explicit choice for devices that can handle it.

Progress reporting should separate model download from transcription. Otherwise a user cannot tell whether the system is fetching hundreds of megabytes, preparing the runtime, or actually processing audio.

6. Local history is still persistent data

Once transcription finishes, the application needs somewhere to keep the result. IndexedDB is a natural browser storage layer for transcripts, timestamps, and task metadata.

This creates a useful privacy property: the transcript can remain in the current browser rather than being attached to an online account.

It also creates responsibilities:

shared browser profiles may expose local history to other people using the profile;
clearing site data can remove the history;
device backups may copy browser data;
exported TXT, JSON, SRT, or VTT files leave the browser’s storage boundary; and
local processing does not replace recording consent or organizational policy.

“Not uploaded to the transcription service” is valuable, but it is not the same as “impossible for the data to leave the device.”

7. Long recordings need a different memory strategy

Decoding an entire long recording into memory can be wasteful or simply fail.

A large-file workflow can inspect the duration, divide the audio timeline into manageable sections, decode and transcribe them in order, and combine text and timestamps only after all sections finish.

That approach reduces peak working memory, but it introduces new UX constraints. The device must remain awake, partial progress may belong only to the current tab, and a refresh or browser shutdown may require restarting the unfinished job.

A credible local tool should disclose those constraints before the user commits an hour-long recording to the process.

What to evaluate in any browser transcription tool

Before trusting the “local” label, ask five questions:

Does the selected media go to a remote API?
Where does the speech model run?
What does the browser still download?
Where is the completed transcript stored?
What happens after a refresh, cache clear, or export?

The answers reveal more than a privacy slogan. They describe the real data path, the performance model, and the points where a user can lose work.

Browser-local transcription is not automatically the right architecture for every team. Cloud services remain useful for collaboration, server-side queues, speaker diarization, and processing that must continue after a laptop closes. But when the goal is to transcribe a recording on the current device with fewer data handoffs, modern browser APIs make that a practical option rather than a demo.