A family emoji can look like one pictograph while its stored text contains several emoji scalars joined by U+200D ZERO WIDTH JOINER values. UnicodeLens deliberately reports the scalar sequence rather than a visible-character claim. Fonts and platforms decide whether the sequence appears as one family glyph, several people, missing boxes or another supported presentation.
Read all seven scalar rows in order
The exact sequence is U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F466. Four supplementary person values alternate with three BMP joiners. The joiner may occupy no visible width, but it is still one scalar, three UTF-8 bytes and one UTF-16 unit. UnicodeLens keeps each occurrence as its own row and does not replace a blank-looking cell with a category claim.
Verify seven, eleven and twenty-five
There are seven scalar rows. Each of the four supplementary emoji occupies two UTF-16 units, while each joiner occupies one, producing eleven units. Each emoji occupies four UTF-8 bytes and each joiner occupies three, producing twenty-five bytes. These totals are deterministic representation facts. They do not state how many glyphs, cursor stops, user-perceived characters or display columns another application will use.
Do not turn this into a grapheme or support claim
Unicode Standard Annex 29 defines grapheme-cluster segmentation, and emoji presentation also depends on data versions and platform support. UnicodeLens ships neither a versioned segmentation engine nor an emoji database, so it does not call the family one grapheme or promise a particular picture. Use this example to inspect storage and transport units. Use a version-pinned library and real target-platform tests when a product needs editing boundaries or rendering support.