OCT2HEX in Collabora Office: Translate Octal Quantities Without Moving Field Boundaries

• Introduced: the original Collabora release and launch date are not established by the reviewed sources.
• Availability: documented in Collabora Office 26.04 desktop help.
• Platform scope: online and mobile deployment support is not inferred from the desktop documentation.
• Checked: October 14, 2026. Function-specific documentation and independent controls; no native Collabora execution.

=OCT2HEX(Number [; Places])

Number is an octal string with at most ten characters. The source documents a sign bit and two’s-complement input for negative values. Places is the optional number of output positions.

The short reference does not establish an omitted-width default, negative-output width, every conversion limit, fractional handling or exact native errors. These examples use small positive strings and sufficient explicit integer widths.

Octal groups three binary bits per digit; hexadecimal groups four. Their digit boundaries do not automatically align. Converting a complete quantity is therefore different from independently converting its component digits and concatenating the results.

Enter the following strings in Text-formatted A2:A6. Put =OCT2HEX(A2;4) in B2 and fill down.

The decimal column is explanatory. Use =OCT2DEC(A2) in C2 and fill down for independently expected numeric values 3, 10, 42, 100 and 342.

For 526, octal positional arithmetic gives 5×64+2×8+6=342. Hex 156 gives 1×256+5×16+6=342. Padding to 0156 leaves that value unchanged.

For the input 52:

=OCT2HEX("52";2)
=OCT2HEX("52";4)
=OCT2HEX("52";6)

Independently expected outputs are 2A, 002A and 00002A. Each represents 42. The width belongs to the output layout; the numeric value does not record how many leading zeros were requested.

The source’s 144-to-0064 example confirms this kind of positive padding. It does not establish the handling of a width that is too small or an omitted argument; those remain unverified.

Put octal text 526 in E2. The whole conversion =OCT2HEX(E2;3) has expected text 156, or decimal 342.

Now consider a different operation: convert each separate octal digit to one hex digit and concatenate:

=OCT2HEX(LEFT(E2;1);1)&OCT2HEX(MID(E2;2;1);1)&OCT2HEX(RIGHT(E2;1);1)

This produces independently expected text 526. Interpreted as hexadecimal, it represents 5×256+2×16+6=1318, not 342.

The function calls correctly converted the three independent small values, but concatenation placed them at new positional weights. If the fields are meant to remain independent, retain their separators and definitions. If one complete numeric quantity is intended, convert the whole source string.

LEFT, MID and RIGHT select fields; they do not decide whether those fields should become one number.

For the first table, enter =HEX2DEC(B2) in D2 and fill down. Expected results match C2:C6. A comparison of the two decoded columns therefore has independently expected TRUE for each row.

For the shortcut counterexample, compare:

=OCT2DEC("526")
=HEX2DEC("156")
=HEX2DEC("526")

Expected numbers are 342, 342 and 1318. The first two preserve the quantity; the third describes the separately concatenated hex digits.

HEX2DEC interprets a hexadecimal string, while OCT2DEC interprets an octal string. The base must remain explicit even when every character looks like an ordinary decimal digit.

Keep source codes as text when leading zeros are significant. Octal digits 8 or 9 are outside the input notation, but exact native invalid-input errors are not established by this section.

The guide does not certify negative cross-conversion output width, overflow, omitted Places, fractional arguments or coercion. All examples remain explicit positive fixtures with sufficient width. HEX2OCT offers the reverse representation under its own documented input contract, not an automatically identical parser or error policy.

• Collabora Office 26.04: OCT2HEX.
• Editorial testing standards.

Complete function-specific documentation reviewed. Outputs are independently calculated positional, equality or arithmetic models, not captured native application results. Formulas use English names and semicolon separators; optional-argument brackets describe syntax and are not typed into a working formula.