Himetric¶
Represent physical length in device-independent units of one hundredth of a millimetre, especially for OLE object extents and Windows mapping between logical and device coordinates.
Core Idea¶
HIMETRIC is a resolution-independent logical unit used in Windows and OLE in which one unit represents 0.01 millimetre, so there are 2,540 HIMETRIC units in one inch.[1] An application records an object's natural physical extent in a fixed metric scale and converts that extent to device pixels or another logical mapping only at a rendering boundary using resolution and mapping-mode information.
Its autonomous residual is the fixed 0.01-millimetre logical unit and its OLE or Windows interoperability role, rather than metric length generally, high resolution, or an arbitrary integer coordinate. The identity fails when the value is treated as pixels, twips, points, or millimetres without conversion, an axis convention changes silently, integer rounding is ignored, or the unit name is inferred solely from a variable prefix.
Recognition requires an analyst to identify the API field or mapping mode, confirm the HIMETRIC scale, preserve width, height, sign, and axis conventions, perform conversion with declared device resolution and rounding, and distinguish stored physical extent from rendered pixel count. Once established, it supports exchanging OLE object sizes, preserving physical dimensions across displays and printers, interpreting legacy ActiveX and Windows structures, and separating device-independent extents from device-dependent coordinates without turning those uses into the definition.
Structural Signature¶
- Carrier: a logical length or two-dimensional extent exchanged by Windows or OLE interfaces under the HIMETRIC unit convention
- Inputs or antecedent state: a signed coordinate or size value, the scale of 0.01 millimetre per unit, coordinate orientation, device resolution, logical-to-device mapping, rounding convention, and API contract
- Constitutive operation: An application records an object's natural physical extent in a fixed metric scale and converts that extent to device pixels or another logical mapping only at a rendering boundary using resolution and mapping-mode information
- Invariant: length is represented in integer or API-defined coordinates whose declared scale is one hundredth of a millimetre and whose conversion is governed by the relevant Windows or OLE contract
- Recognition test: identify the API field or mapping mode, confirm the HIMETRIC scale, preserve width, height, sign, and axis conventions, perform conversion with declared device resolution and rounding, and distinguish stored physical extent from rendered pixel count
- Output or consequence: exchanging OLE object sizes, preserving physical dimensions across displays and printers, interpreting legacy ActiveX and Windows structures, and separating device-independent extents from device-dependent coordinates
- Failure boundary: the value is treated as pixels, twips, points, or millimetres without conversion, an axis convention changes silently, integer rounding is ignored, or the unit name is inferred solely from a variable prefix
What It Is Not¶
- It is not the whole field of computer graphics and interoperability; many objects in that field do not satisfy its constitutive rule.
- It is not its canonical example. An OLE object reporting an extent of 2,540 HIMETRIC units along one dimension represents one inch of physical length before device conversion. That is an instance, not a definition.
- It is not Resolution Matching. Resolution matching coordinates representations across devices or scales; HIMETRIC is one fixed physical-length unit used as an input to such conversion rather than the matching process itself.
- It is not an unrestricted metaphor. Windows mapping modes can invert the logical vertical axis relative to device coordinates, and API helpers may use logical rather than physical pixels, so numeric scale alone does not determine direction or rounding
Scope of Application¶
Himetric applies when the analyst can specify a logical length or two-dimensional extent exchanged by Windows or OLE interfaces under the HIMETRIC unit convention and establish that length is represented in integer or API-defined coordinates whose declared scale is one hundredth of a millimetre and whose conversion is governed by the relevant Windows or OLE contract. The entry documents a coordinate-unit abstraction; it is not programming advice for a specific API version, and implementations must consult the current contract for types, axes, overflow, and conversion behavior.[2]
- Recognition. identify the API field or mapping mode, confirm the HIMETRIC scale, preserve width, height, sign, and axis conventions, perform conversion with declared device resolution and rounding, and distinguish stored physical extent from rendered pixel count
- Comparison. Compare legitimate instances through logical scale, physical unit, axis direction, signedness, integer range, display resolution, printer resolution, DPI virtualization, mapping mode, conversion rounding, and API version.
- Boundary. Windows mapping modes can invert the logical vertical axis relative to device coordinates, and API helpers may use logical rather than physical pixels, so numeric scale alone does not determine direction or rounding
- Use. Preserve every assumption when using the identity for exchanging OLE object sizes, preserving physical dimensions across displays and printers, interpreting legacy ActiveX and Windows structures, and separating device-independent extents from device-dependent coordinates.
Clarity¶
A clear claim names the carrier, governing rule, assumptions, and recognition test. This matters because hi can be misread as merely high resolution, while the technical identity fixes a metric scale and historical Windows interoperability convention. The disciplined statement is that the object counts as Himetric exactly when length is represented in integer or API-defined coordinates whose declared scale is one hundredth of a millimetre and whose conversion is governed by the relevant Windows or OLE contract
Identity and measurement remain separate. The unit supplies a nominal physical length, but actual displayed size can differ because of device calibration, operating-system scaling, application transforms, and rounding. Approximation or noisy evidence may weaken a classification without changing its definition.
Manages Complexity¶
The abstraction compresses OLE extents, ActiveX controls, RichEdit text services, MFC conversions, metafile presentation dimensions, and legacy Visual Basic coordinate interchange into a stable carrier, rule, invariant, and failure boundary. It makes comparison tractable while retaining the variables that control validity.
Compression can hide assumptions. A responsible use therefore declares logical scale, physical unit, axis direction, signedness, integer range, display resolution, printer resolution, DPI virtualization, mapping mode, conversion rounding, and API version and returns to the full diagnostic whenever a convention or boundary case changes.
Abstract Reasoning¶
- Type the carrier. Establish a logical length or two-dimensional extent exchanged by Windows or OLE interfaces under the HIMETRIC unit convention and reject examples from a different problem.
- Lock the rule. Express that length is represented in integer or API-defined coordinates whose declared scale is one hundredth of a millimetre and whose conversion is governed by the relevant Windows or OLE contract independently of one notation or implementation.
- Derive carefully. Infer exchanging OLE object sizes, preserving physical dimensions across displays and printers, interpreting legacy ActiveX and Windows structures, and separating device-independent extents from device-dependent coordinates only under the stated assumptions.
- Stress-test. Contrast the legitimate boundary case—Windows mapping modes can invert the logical vertical axis relative to device coordinates, and API helpers may use logical rather than physical pixels, so numeric scale alone does not determine direction or rounding—with this counterexample: a size of 2,540 pixels is not one inch merely because the number matches HIMETRIC-per-inch; pixels require a device resolution and are a different unit.
Knowledge Transfer¶
Transfer within computer graphics and interoperability is strong when new cases preserve the same carrier, mechanism, and diagnostic. The move from An OLE object reporting an extent of 2,540 HIMETRIC units along one dimension represents one inch of physical length before device conversion. to A Windows container converts an embedded object's HIMETRIC extent to device coordinates when laying it out on a particular display or printer. demonstrates that continuity.[3]
Outside the domain, only the skeleton—store a physical dimension in a fixed abstract scale and postpone device-specific discretization until presentation—travels automatically. The terms HIMETRIC, logical unit, device coordinate, mapping mode, extent, OLE, ActiveX, pixel, DPI, conversion, and rounding retain domain-specific meanings, so every role and inference must be revalidated.
Examples¶
Canonical¶
An OLE object reporting an extent of 2,540 HIMETRIC units along one dimension represents one inch of physical length before device conversion. The stored length is resolution-independent; the number of pixels used to display it depends on the target device and mapping calculation. It is canonical because the carrier, rule, invariant, and consequence are all inspectable.[1]
Mapped back: a logical length or two-dimensional extent exchanged by Windows or OLE interfaces under the HIMETRIC unit convention → An application records an object's natural physical extent in a fixed metric scale and converts that extent to device pixels or another logical mapping only at a rendering boundary using resolution and mapping-mode information → length is represented in integer or API-defined coordinates whose declared scale is one hundredth of a millimetre and whose conversion is governed by the relevant Windows or OLE contract → exchanging OLE object sizes, preserving physical dimensions across displays and printers, interpreting legacy ActiveX and Windows structures, and separating device-independent extents from device-dependent coordinates
Applied / In Practice¶
A Windows container converts an embedded object's HIMETRIC extent to device coordinates when laying it out on a particular display or printer. The same logical extent can map to different pixel counts while preserving its intended physical size, subject to scaling, rounding, and application behavior. It qualifies only after the same diagnostic and failure boundary are checked.[2]
Mapped back: declared instance → recognition test → boundary check → qualified use
Structural Tensions¶
- T1: Exact identity vs. practical recognition. The constitutive condition may be exact while evidence is indirect. Diagnostic: Can the reviewer state both the condition and the warrant?
- T2: Canonical form vs. variants. OLE extents, ActiveX controls, RichEdit text services, MFC conversions, metafile presentation dimensions, and legacy Visual Basic coordinate interchange can preserve or change the identity. Diagnostic: Which named role is invariant across the variants?
- T3: Compression vs. hidden assumptions. The label is useful only while prerequisites remain visible. Diagnostic: Can each downstream inference be traced to a declared assumption?
- T4: Autonomy vs. reduction. The candidate uses broader structures but claims the fixed 0.01-millimetre logical unit and its OLE or Windows interoperability role, rather than metric length generally, high resolution, or an arbitrary integer coordinate. Diagnostic: Does that residual still support independent recognition after the parent and neighbors are subtracted?
Structural–Framed Character¶
The entry is structurally mixed but domain-framed. Its portable skeleton is store a physical dimension in a fixed abstract scale and postpone device-specific discretization until presentation; its identity-bearing terms are HIMETRIC, logical unit, device coordinate, mapping mode, extent, OLE, ActiveX, pixel, DPI, conversion, and rounding. Those terms determine admissible objects, evidence, and consequences inside computer graphics and interoperability.
Structural Core vs. Domain Accent¶
The structural core is a carrier governed by An application records an object's natural physical extent in a fixed metric scale and converts that extent to device pixels or another logical mapping only at a rendering boundary using resolution and mapping-mode information and tested by identify the API field or mapping mode, confirm the HIMETRIC scale, preserve width, height, sign, and axis conventions, perform conversion with declared device resolution and rounding, and distinguish stored physical extent from rendered pixel count. The domain accent is constitutive rather than decorative, so an analogy that preserves only the skeleton is not another instance of Himetric.
Instantiates / Related Primes¶
The proposed strict upward parent is prime:measurement. HIMETRIC literally assigns numerical magnitudes to physical lengths under a fixed unit scale; its Windows and OLE interchange role provides the domain-specific residual. The edge is proposal-only and points to a frozen prior-baseline Prime.
The entry does not collapse into the parent because the fixed 0.01-millimetre logical unit and its OLE or Windows interoperability role, rather than metric length generally, high resolution, or an arbitrary integer coordinate A thematic neighbor is declined whenever it does not literally subsume that rule.
The prospective workspace queue contains one strict upward edge to prime:measurement. No live DAG mutation is authorized.
Relationships to Other Abstractions¶
Current abstraction Himetric Domain-specific
Parents (1) — more general patterns this builds on
-
Himetric is a kind of Measurement Prime
The proposed strict upward parent is
prime:measurement.HIMETRIC literally assigns numerical magnitudes to physical lengths under a fixed unit scale; its Windows and OLE interchange role provides the domain-specific residual. The edge is proposal-only and points to a frozen prior-baseline Prime. The entry does not collapse into the parent because the fixed 0.01-millimetre logical unit and its OLE or Windows interoperability role, rather than metric length generally, high resolution, or an arbitrary integer coordinate A thematic neighbor is declined whenever it does not literally subsume that rule. The prospective workspace queue contains one strict upward edge toprime:measurement. No live DAG mutation is authorized.
Hierarchy path (1) — routes to 1 parentless root
- Himetric → Measurement
Neighborhood in Abstraction Space¶
Himetric sits in a moderately populated region (60th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.
Family — Ambient Structures & Local Geometry (9 abstractions)
Nearest neighbors
- Length — 0.89
- Significant figures — 0.87
- Convenient number — 0.87
- Doubling space — 0.86
- Metrication — 0.86
Computed from structural-signature embeddings · 2026-09-08
Not to Be Confused With¶
- Twip. A typography-derived unit equal to one twentieth of a point, not 0.01 millimetre.
- Pixel. A device or raster coordinate whose physical size depends on resolution and scaling.
- MM_HIMETRIC. A Windows mapping mode that uses HIMETRIC logical units and also defines coordinate orientation.
- HIMETRIC_PER_INCH. A conversion constant, conventionally 2,540, rather than the unit-bearing coordinate itself.
References¶
[1] Microsoft, 'ITextHost::TxGetExtent,' Windows App SDK / Win32 documentation, stating that each HIMETRIC unit corresponds to 0.01 millimetre, current Microsoft Learn documentation. registry ↩a ↩b
[2] Microsoft, 'CDC Class: MM_HIMETRIC, DPtoHIMETRIC, and HIMETRICtoDP,' Microsoft Foundation Class Library reference, current Microsoft Learn documentation. registry ↩a ↩b
[3] Microsoft, [MS-OLEDS]: Object Linking and Embedding (OLE) Data Structures, sections 2.1.9–2.1.12 on presentation extents and MM_HIMETRIC, current Open Specifications release. registry ↩