New Member

Question

Find/Change preset loses numeric precision and behaves differently from manual Find

Forum|Forum|5 months ago
December 15, 2025
4 replies
321 views

When using numeric paragraph attributes in Find/Change (for example, Left Indent in millimeters), manual Find works correctly, but the same query saved as a Find/Change preset fails to match identical paragraphs.

This is not a unit conversion issue (mm to pt).
The problem is caused by floating point precision loss when the preset is saved, followed by strict numeric comparison when the preset is executed.

Steps to reproduce:

Create a new document.
Set document measurement units to millimeters.
Create a paragraph with Left Indent set to 5 mm.
Open Find/Change.
Search for paragraphs with Left Indent equal to 5 mm. The paragraph is found correctly.
Save this Find/Change query as a preset.
Run the saved preset.

Expected result:
The saved Find/Change preset should behave identically to the manual Find using the same numeric value.

Actual result:
The saved preset does not find the paragraph with Left Indent equal to 5 mm.

Technical notes:

Manual Find appears to use high precision internal numeric values with tolerance.

When a Find/Change query is saved, numeric values are serialized with reduced floating point precision, truncated rather than rounded. Unit context and numeric tolerance are not preserved.

When the preset is executed, a strict floating point comparison is performed against a numerically different value.

For example, 5 mm corresponds to approximately 14.1732283464567 pt internally, while the saved preset stores a truncated value around 14.17323 pt. As a result, the values are no longer equal and the match fails.

This issue reproduces consistently and affects any numeric paragraph attribute that involves unit conversion. It breaks the expectation that saved Find/Change presets are equivalent to manual Find operations.

Abhishek Rao

Community Manager

Hi everyone,

Thanks so much for bringing this up and for sharing all the detailed observations. I've checked the behavior on my side as well and can confirm that I'm seeing the same issue. Therefore, I've reached out to the product team for clarification and to have this issue investigated further. I'll update the thread as soon as I hear back from them with more information.

Thank you again for taking the time to report this and for your patience while we investigate it.

Abhishek

Willi Adelberger

Community Expert

I agree, never work without paragraph and character styles. If you do so, manyfind and replace tasks will be obsolete.

N

NonparelAuthor

New Member

I absolutely agree that paragraph and character styles are fundamental — I’ve been relying on them professionally for nearly 30 years, starting with PageMaker long before InDesign existed.

However, the issue described here isn’t about replacing styles with Find/Change, but about precision loss when numeric values are persisted in saved queries. The same document behaves differently depending on whether the value is entered manually or restored from a preset, which points to a rounding/storage bug rather than a workflow choice.

m1b

Community Expert

Hi @Nonparel Well done for finding this and analysing the details! This is a bad bug. I can confirm this exact bug on ID 21.0.2 on MacOS 26.2.

Via the scripting API I get this:

Directly entering 5mm left indent via Find Text UI:
app.findTextPreferences.leftIndent = 14.1732283464567  (successfully finds the 5mm text)

After re-loading the saved query:
app.findTextPreferences.leftIndent = 14.17322834   (fails to find the 5mm indented text)

However this isn't the right place to lodge bugs as it is a user-to-user forum. The best place would be at uservoice. If you create a bug report there, please post a link back on this thread and we can vote on it.

- Mark

N

NonparelAuthor

New Member

This issue has been independently confirmed on the Adobe InDesign forum, including via the scripting API.

Manual entry of an indent value via the Find/Change UI uses higher numeric precision than the same value restored from a saved Find/Change query, which results in different behavior.

This is not a workflow issue and is not related to avoiding paragraph or character styles. The problem appears to be precision loss when numeric values are persisted and reloaded in saved queries.

Forum thread with confirmation and numeric details:
post

m1b

Community Expert

Thanks for lodging the bug. I voted.

brian_p_dts

Community Expert

Interesting observation. Reason #782 to use well-defined paragraph and character styles.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded