CHAR Function (OpenOffice Calc)

• Introduced: First release not established; documented by OpenOffice.org 3.3.
• Supported in: Apache OpenOffice 4.1.16; no final supported release is established.
• Scope: English desktop Calc with semicolon-separated formulas. The observed locale was English (USA), default currency USD.
• Checked: October 14, 2026. Eight ordinary examples were recalculated in 4.1.16 on Linux x86-64, Build 9816. Saved types, strings or numeric values, and both controls were checked.

CHAR converts a byte-sized number through the application’s system text encoding. It is not an unrestricted Unicode-code-point function. The ordinary ASCII examples below are unambiguous within the tested environment. Release implementation.

=CHAR(Number)

• Number: code to convert.

The inspected source accepts values from 0 up to but not including 256, then casts to a byte before conversion. The tested inputs are exact ASCII integers; neither arbitrary Unicode values nor fractional conversion was exercised.

All eight formulas were recalculated. Stored string values and ODF text markup were decoded exactly, including the space and line feed, which can look empty in a displayed cell. Code-point labels describe those saved characters; they do not change CHAR into a general Unicode function.

CHAR(65) gives the capital letter A, while CHAR(97) gives lowercase a. CHAR(48) gives the character “0”, not numeric zero. The saved value type is a string even when its appearance resembles a digit.

CHAR(32) produces one space. A space can be hard to see in a cell, so the table identifies it by U+0020 rather than displaying an apparently empty answer. CHAR(10) produces a line-feed character; its stored code point is inspected separately from how a particular cell displays or wraps it.

A useful string construction is "Item"&CHAR(32)&"A", whose independently expected text is “Item A”. Similarly, "A"&CHAR(10)&"B" contains three code points, with a line feed between the letters. The visual rendering of that line break depends on the cell’s layout settings.

Do not infer a universal mapping for codes above the ASCII range from these examples. The source explicitly calls the system-encoding conversion routine. A code that denotes one character on a particular legacy encoding can denote something else, or be unsuitable, under a different environment.

The source rejects a negative value or a value at least 256; those boundaries were source-reviewed rather than executed here. The accepted zero-code path is also outside the eight examples and should not be mistaken for an ordinary visible character.

For Unicode work, use a function whose documented contract is Unicode rather than assuming CHAR accepts any code point. Keep text and numeric results distinct: changing a cell’s number format cannot turn the string “0” into a verified numeric input. Other locales, system encodings, fonts and workbook exports were not tested by this ASCII set.

CODE, UNICHAR, LEN.

• Function-specific release implementation

The generated ODF was opened in the native application, hard-recalculated and saved separately. Its informational “Not all attributes could be read” load warning was retained. Both stale and uncached SUM controls refreshed correctly. The original XLSX was not executed, and this generated-ODF test does not establish manual entry or execution in another release or locale.