Why a pasted Unicode symbol shows as a rectangle on an HMI

What the empty rectangle means

An empty rectangle is the standard missing-glyph stand-in. The renderer found the character in the text and found no drawing for it in the selected font, so it drew the box. Which characters a font can draw is fixed by the font's character map, the list of code points the font covers. The map decides coverage; the editor's willingness to accept a paste says nothing about the panel.

Unicode numbers 1,114,112 code points, from 0 to 10FFFF in hexadecimal, and no font covers that space. U+25B2, the black up-pointing triangle, is code point 9,650 in decimal, inside the first plane that runs from 0 to 65,535. Panel fonts cover only part of that plane, and the geometric shapes block the triangle lives in is a common gap.

The editor showed the triangle because a project file stores the character value, and the editor drew it with the fonts on the configuration PC. The panel draws with its own smaller installed set, so the same project can render two different ways.

Symptoms and what each one points to

• The symbol shows in the editor and turns into an empty rectangle on the panel. The panel's runtime font cannot draw the code point. Run the checks below.
• A plain text object with the same font shows the rectangle too. The font's coverage ends before the triangle; the button object is clean.
• Every installed font draws the rectangle while ordinary letters draw fine. No font on the panel covers the character. Skip the font hunt and go to the bitmap fix.
• Ordinary letters on that button fail too, while letters elsewhere on the panel draw fine. The fault is in the object's own text or font setting, not in glyph coverage.
• The project refuses to compile or download. One documented HMI family treats a configured font missing from the configuration computer as a compile error, and its documentation gives the cure: install that font and restart. That is the opposite fault from a rectangle on a panel that downloaded cleanly.
• A black rectangle that appears only in a screen capture has a different cause entirely, and the panel may be drawing correctly. That capture fault is covered in why an Android player screenshot shows a black rectangle.

Checks that isolate the cause

1. Copy the project and test on the copy, so the working version stays untouched.
2. Place the triangle, U+25B2, in a plain text object on a test screen, with the same default font the button uses. Download and look at the panel. A rectangle here confirms a font coverage problem and clears the button object.
3. Replace the triangle in that object with an ordinary letter or digit and download again. If the letter draws, the text pipeline works and the triangle glyph is the single fault. If the letter fails too, stop and check the object's font and text settings first.
4. Assign a second installed font to the test object and download once more. A drawn triangle gives you a font fix. A rectangle again means no installed font covers the character, and further font changes will not help.
5. Judge every result at the panel, from the distance the operator stands. The editor preview draws with the PC's fonts, so the panel is the only valid test bench for this fault.

The fix: pixels instead of font glyphs

After the checks, one of three fixes applies.

A drawn shape, for one fixed symbol. Draw a filled triangle with the editor's shape or graphic tools, leave the button text blank, and place the triangle over the button. Size it with the example below before you draw, so you do the job once.

An imported bitmap. Type the character in a word processor on the configuration PC at a large size, capture the screen, and crop tight to the glyph. Import the image into the project as a graphic and place it at exactly the pixel size it will occupy on the panel. A glyph resized after import gains jagged edges because the panel resamples it; a 1:1 import keeps the edges clean.

A bitmap text object, for a string. Many HMI editors include an object that converts text, in any installed font, into a bitmap before download. It keeps the font's own look, works for a whole string, and floats over other objects, so you can lay it across the unchanged button. In some older runtimes a placed bitmap refreshes only at runtime start, which matters if the symbol ever has to change with a tag; that behavior is covered in why a CoDeSys 2.3 bitmap only refreshes at runtime start.

Whichever route you take, leave the button object and its action configuration alone. The symbol is the only thing that changes. After the download, stand at the panel and press the button several times and confirm the alarm history still opens: a graphic placed over a button can take the touch for itself, and an alarm review that silently stops responding is the one failure you cannot leave on the floor. Keep the editable project version so the next change needs a new placement, and a new cropped image only if the symbol itself changes.

Example: sizing the symbol for a 4 ft viewing distance

The example: an operator presses the button standing 4 ft away, on a panel with an 800 x 480 pixel screen and a 7 in diagonal.

Screen height on a 16:9 panel: 7 in x 9 / sqrt(16 squared + 9 squared) = 7 x 9 / 18.358 = 3.43 in. Pixel pitch: 3.43 in / 480 px = 0.00715 in per pixel.

Capital height needed: use 20 ft of viewing distance per inch of letter height, the FHWA planning figure for fast reading (30 ft per inch is the figure for text read at leisure). At 4 ft, the minimum is 4 / 20 = 0.20 in of capital height.

In panel pixels: 0.20 in / 0.00715 in per pixel = 28 px. The triangle itself has to measure 28 px tall or more.

If a font fix had worked, the matching text size: capitals in most text fonts run about 70 percent of the point size, and a point is 1/72 in. 0.20 in x 72 = 14.4 pt of capital, so the font setting is 14.4 / 0.7, about 21 pt.

For the bitmap route, draw the triangle 32 px tall: 32 x 0.00715 = 0.23 in, which is 32 / 28 = 1.14, about 14 percent above the minimum. Import at exactly 32 x 32 px so the panel never resamples it.

Decision: on this panel at this distance, a 21 pt font would have been the minimum if a font fix existed. Since none covers the glyph, place a 32 px triangle over the button and the label meets the legibility figure with margin.

When a font change is the right fix

A second installed font that draws the glyph beats a bitmap whenever its other text stays readable, because live text stays editable. Change the object's own font first. Changing the project default moves every object that uses the default, so after a default change, walk the screen at the panel and check the rest of the text.

A font change can start a different fault: panels substitute fonts with different letter widths, and cramped or clipped dialogs are the result. That symptom has its own write-up in fix HMI dialogs clipped by legacy Windows fonts.

Recommendation: Keep letters and digits as live text. The first time a pasted symbol such as U+25B2 turns into an empty rectangle, run the two-download check: the symbol in a plain text object, then in a second installed font. If the second font draws the triangle, set that object to it and re-download. If no installed font draws it, stop cycling fonts and place the symbol as pixels: a shape drawn in the editor for a single fixed symbol, a cropped 1:1 bitmap, or a bitmap text object for a string. Size it to the capital-height minimum for the closest viewing distance, 28 px on the 800 x 480 example panel read from 4 ft, leave the button's action untouched, and prove the fix by pressing the button at the panel.

If the screen the line actually needs is a notice or status board beside the machine, fed with your own slides, that is a different product from an HMI: our shop-floor signage plays images and video offline from a memory card with no subscription.

Questions