BitFont Part 3 - Decode Run-Length-Encoded Rows

In the BitFont exercise, IBM Plex Serif 14 glyph rows are stored with run-length encoding. Decode every supplied row into its full bitmap representation as a string of 0 and 1 pixels.

Each character in an encoded row gives one run length:

• 0-9 represent lengths 0-9.
• a-z represent lengths 10-35, so a is 10, b is 11, and so on.

Decode each row from left to right. The first run contains white pixels, represented by 0. After every encoded character, alternate between white (0) and black (1) for the next run.

A zero-length run appends no pixels, but it still changes the pixel value used by the next run. Return the decoded rows in the same order as the input.

Practice sequence

1. Part 1: Render a Character
2. Part 2: Render a Word
3. Part 3: Decode Run-Length-Encoded Rows (current)

Reversible codec follow-up

Keep the decoding behavior above for every ordinary encoded row. To practice both directions of the codec in the same function, an entry in encodedRows may instead contain one of these tagged commands. Return one string for each entry, in input order; entries do not share state.

• encode:bits: encode the binary pixel row bits using the canonical encoding below, and return the encoded row.
• decode:packed: decode packed using the original rules, and return the binary pixel row.
• render:packed: decode packed, then return the row with each 0 displayed as . and each 1 displayed as #.
• roundtrip:bits: encode bits, decode the result, and render the recovered row with the same . and # mapping.

The command prefixes are practice serialization. Their colon is not part of the original run alphabet, so an untagged row always keeps its original meaning. Payloads may be empty. All supplied entries satisfy the rules; no invalid-input error result is required.

Canonical encoding

1. Encode each maximal consecutive run of equal binary pixels. Use the same digit-and-letter count alphabet and white-first alternating states as the decoder.
2. If a nonempty row starts with 1, begin with 0 to represent its empty white run.
3. For a run longer than 35, emit z, then 0 for the opposite color, and continue the original run. Repeat while the remaining count exceeds 35, then emit its final count. For example, 36 white pixels encode as z01, and 70 white pixels encode as z0z.
4. Encode an empty pixel row as an empty string. Add no other zero runs or trailing padding.

Decoding an encoded pixel row must recover exactly the same pixels, width, and row order. Re-encoding an existing packed row may normalize its spelling; it need not reproduce redundant zero runs. Run-length encoding does not guarantee a shorter string for every bitmap.

Render the recovered glyph

A character lookup supplies its bitmap rows, as in the linked character-rendering exercise. Apply encode: to those rows, then render: to the resulting packed rows, or apply roundtrip: directly. The recovered display must match the original glyph, including background pixels. Process requested glyphs individually; this follow-up adds no word spacing, padding, clipping, kerning, inversion, or other image transformation.

What the interview report shared

The report describes looking up a character bitmap, rendering it, and then compressing and decompressing the lookup data while rendering the same letters. Its detailed outline was copied from an older report. The following reported bitmap illustrates the letter J:

000010
000010
000010
000010
000010
000010
100010
011100
000000
000000

The report also mentions a later manipulation that reuses codec code, without identifying its transformation or required result. This exercise covers the disclosed rendering and reversible-codec scope; it does not assign a rule to that unspecified phase.