HMI map zoom and rotation are separate tasks

Match the change to the visible problem

Start by looking at what is wrong, not by choosing a rendering feature. A sideways interface needs a different correction from a correctly oriented map with unreadable detail.

These problems can occur together. A portrait interface may also need a closer map view, but that still calls for two decisions. Set the interface direction, then decide what area the map should show.

Whole-screen orientation changes the coordinate frame

A whole-screen orientation setting changes the direction in which the interface is presented. A quarter-turn exchanges the horizontal and vertical directions. The application may also need to rearrange its layout to use the resulting space.

Do not assume that a display setting, application setting and image rotation are interchangeable. Depending on the system, orientation may be handled by the display controller, operating system or application. The applicable documentation should explain which layer owns it and how the application receives the resulting dimensions.

A rotated layout can affect more than its background image:

• Text and scrolling regions must face the intended direction.
• Objects near the edges must remain inside the visible area.
• Overlays must stay aligned with the features they describe.
• Touch locations must match the visible controls.

A visually correct background is not enough to establish that an interactive interface is correct. Check input mapping separately using the platform's documented facilities.

If the project already contains pre-rotated images, adding whole-screen rotation can turn those images again. Record the existing rotation choices before changing the screen-level setting. For the asset-preparation part of that work, use the guidance on portrait signage images. That is separate from deciding how a map view behaves.

Map zoom changes the area inside a window

A map view has both a source area and a destination window. The source area identifies the part of the map you want to see. The destination window is where that area appears in the interface.

Zooming in usually means showing a smaller source area within the same destination window. Panning changes the position of that source area. Rotating the map changes its direction within the window. None of these operations inherently requires rotating the rest of the interface.

For example, doubling the linear zoom while keeping the window fixed shows half the previous map width and half its height. The visible area is therefore one quarter of the previous area, assuming the same proportions and no clipping changes. The map appears larger because less of it fills the window.

Simply stretching a complete overview image to a larger object is different. If the interface still fits the entire image into view, the mapped coverage has not changed. If the larger image is clipped, you also need a way to choose which portion remains visible.

For an interactive map, define what stays fixed during zoom. It might be the window centre, a selected asset or a touched location. Without that rule, a zoom action can enlarge the map but move the location of interest out of view.

Nine-slice resizing preserves interface decoration

Nine-slice rendering divides an image into corners, edge regions and a centre. A typical implementation preserves the corners while stretching or repeating other regions to fit a new rectangle. Exact behaviour depends on the rendering system.

That is useful for a framed panel or a button background. It lets the container change shape without stretching every decorative feature in the same way.

It is not a substitute for map zoom. A map relies on consistent spatial relationships. If some parts remain fixed while other parts stretch, distances and shapes can become misleading. Nine-slice rendering also does not define a selected map region, a pan position or a zoom centre.

Keep decorative framing separate from map content. A resizable frame can surround a map window, while the map itself uses a uniform scale and a defined crop. This keeps the interface border adaptable without treating the mapped area as decoration.

Choose runtime zoom or prepared detail views

Use runtime zoom when the application supports the required crop, scaling, pan controls and overlay behaviour. Confirm those capabilities in its documentation rather than assuming that bitmap resizing includes them.

A prepared detail view is often simpler when the required locations are fixed. The interface can offer an overview and a small set of named detail views instead of arbitrary zoom. Each detail view can have labels placed specifically for that area.

The distinction is especially important with raster images. Enlarging pixels does not create additional source detail. If small labels were unreadable in the original overview, magnifying that same image may only produce larger blurred labels. Prepare the detail image from a sufficiently detailed source, not merely from an enlarged copy of the overview.

Vector rendering can redraw geometry at the selected scale, but label placement still needs attention. More visible geometry does not automatically produce a readable interface.

Choose prepared views when repeatable framing and simple navigation matter most. Choose interactive zoom when the application must support locations that cannot be covered sensibly by a few predefined views.

Keep position and meaning consistent between views

A detail view should make its relationship to the overview clear. Show which area was selected, name the location consistently and provide an obvious route back to the overview.

Useful design checks include:

• Keep map direction consistent, or clearly indicate when it changes.
• Use the same asset identifiers across overview and detail views.
• Keep status colours and symbols consistent.
• Avoid leaving an overview scale label on a differently scaled detail image.
• Reposition labels deliberately rather than letting them obscure important features.
• Keep live status overlays aligned with the correct mapped locations.

For overlays, use one documented coordinate relationship between the map and its markers. A background image that zooms while its markers remain fixed can show status against the wrong location.

Also distinguish navigation from control. Selecting a detail view need not select equipment for an action. If the interface includes machine commands, preserve the existing permissions and safety functions. The distinction between a factory status display and an operator HMI helps define that boundary.

Check the combined result before deployment

Evaluate orientation and map behaviour separately before checking them together. Use an asymmetric reference graphic with clear direction labels to reveal rotation errors. Then inspect the map at its overview and detail states.

Check the actual viewing window, not only the source files. Look for clipped edges, stretched geometry, unreadable labels and mismatched overlays. Where touch navigation is supported, check selections near the window edges as well as its centre.

Finally, check the documented startup behaviour. Confirm which orientation, view and selected area appear after the normal restart sequence. A temporary configuration change does not establish what the interface will restore later.

The practical decision is straightforward: use orientation to face the interface correctly, image preparation to correct individual assets, and a defined map viewport or prepared detail view to reveal a smaller area. Treating those as separate responsibilities makes both diagnosis and future changes easier.

Questions