Data Model & Units
TonCut Desktop exposes a rich shared kernel model. Plugins do not need to know every implementation detail, but they do need to respect host units, rotation conventions, shape types, and object naming so imported or exported data stays consistent.
Units
Important shared conventions from uICommon:
| Item | Meaning |
|---|---|
| User-facing length system: millimeters, centimeters, or inches. | |
cLengthMultiplier = 100 | Internal integer length scaling used by many dimensions. |
TRotation | Rotation unit stored in tenths of a degree. |
cRotation90, cRotation180, cRotation270, cRotation360 | Precomputed rotation constants based on that unit. |
TField | Area-like value in internal squared units. |
Use ITonCut helpers such as FormatLength, HumanReadableLength, FormatField, HumanReadableField, FormatDegrees, and FormatRadians whenever you need host-consistent display text in plugin UI.
Geometry
Desktop plugins mainly encounter geometry in four places:
- IFormat
Shape, IBanding, and IGrinds when importing piece definitions. - ISheet
Edgingand ISheetDefects when importing or exporting stock. - ISolutionSheet coordinate helpers when exporting results.
- ISolutionCut, ISolutionWaste, and ISolutionFormat when reading optimization output.
The shared shape model supports rectangles, linear shapes, arbitrary paths, and more specialized enumerated shape types. Result exporters should not assume that every piece or waste area is a plain rectangle, even when many importers start with rectangular data.
Terminology map
TonCut Engine docs describe many of the same concepts under Engine-oriented names. When you move between the two documentation sets, use this mapping:
| Engine term | Desktop interface |
|---|---|
| Device | IDevice |
| Material / material group | IMaterial |
| Veneer / band | IBand / IBanding |
| Piece | IFormat |
| Stock / stock item | ISheet / IStandardSheet |
| Cutting / output sheet | ISolutionSheet |
| Output piece | ISolutionFormat |
| Waste | ISolutionWaste |
| Cut | ISolutionCut |
The Engine docs are useful for conceptual descriptions, but the Desktop code in this repository defines the actual plugin contract. Prefer the local source whenever a detail such as file matching, capability flags, or result-code behavior is Desktop-specific.