Rasterexthe drawing layer, running inside a host system
ENGINEread from the drawing by Rasterex HOSTthe host system's own records
Canvas not connected

Asset Drawing Explorer

Asset hierarchy

ENGINE

Drawing

No document open Canvas not connected
Everything inside this frame is the package. Everything outside it is your application.
@rasterex/viewer

Under the hood

Engine

Everything under an ENGINE chip

Block list, the hasAttribute flag, attribute names and values, block insert points, markup guids and markup inventory. Each one is the return value of a call you can see in the trace, timed and counted.

Real — or absent. There is no substitute value.
Host

Everything under a HOST chip

The asset register, work orders and the stored tag→asset links. Here they live in memory behind one HostAdapter interface; in your product they are your own tables. Load your own register from CSV under Link Setup.

Stand-in — and labelled everywhere it appears.
Not here

What this build does not claim

No pre-computed counts and no drawn-in illustration: the sample is a real DXF, opened through documents.openFile() exactly like a file you upload. Revision compare is not wired here, so it is not shown. If the Canvas is unreachable the page says so and stays empty rather than falling back to anything.

Absent on purpose.
Hop 1

Your page → the package

The shell around the drawing is a stand-in. In your product this is your own page, importing @rasterex/viewer like any other npm dependency and calling it from a single file.

Hop 2

the package → Canvas

@rasterex/viewer creates the iframe and speaks a documented PostMessage protocol to the Canvas at —. The version handshake and a compatibility verdict come back from getInfo().

Hop 3

Canvas → your engine

This demo points at our evaluation sandbox. In production the Canvas and the engine run on your own host, inside your customer's network — only viewerUrl changes. Nothing here assumes the sandbox.