Module device 

Device presets.

Why output pixels come first

Apple and Google state their requirements in output pixels — “1320 x 2868”, “1024 x 500”. A browser, however, is driven in CSS pixels plus a device pixel ratio. Storing the CSS size and multiplying is the obvious design and it is the wrong one: it lets a preset exist that cannot produce a required size, and the failure only shows up as a rejected upload.

So a Device stores the required output size and derives the viewport as output / scale. A preset whose output does not divide evenly by its scale is rejected at parse time, which makes “the size we emit is a size the store accepts” a structural property rather than arithmetic somebody has to get right by hand.

Why this is data

Stores change these numbers without warning. The table lives in crates/proofsheet-core/presets/devices.json so it can be corrected without cutting a release, and --presets overrides it at runtime.

It lives INSIDE the crate deliberately. include_str! reaching outside the crate directory compiles locally and then fails for everyone who installs from crates.io, because cargo package only ships files under the crate root. That shipped once as a crate that could not compile.

Structs

Device

One capture target.

PresetFile

The on-disk preset file.

Enums

Platform

What kind of device is being emulated.

Requirement

How strongly the store asks for this size.

Store

Which store a preset targets.

Functions

builtin

The compiled-in fallback table.

by_id

Look a device up by id.

for_store

Every device targeting a given store.

parse_presets

Parse and validate a preset file.