Unfortunately there isn't enough information here to determine whether 11.3 or 12.2 is at fault or even if there is fault to be applied because it could be some other environmental difference that accounts for the difference.
Are you looking at PDF output or Entry/WIP?
In general, I think it is safe to say that printing is not adding a space. However, if this is PDF and depending upon settings, it is possible that you have inherited a "positioning" behavior that makes it look like there is a space there when there may not be a physical one.
On the other hand, it is possible that the space is actually on the field data now where a rule or something might have truncated it before, but doesn't now. If that is the case, that might have been considered a bug fix to some other issue.
All this is to say that there needs to be more detail to determine the difference. How is the field mapped - by rule or by Entry? If you look at the section in the tool, is there a spacing difference already between where the embedded field is located and that next word or character? What type of output are you looking at? Do you have another output type that you can physically print? If you are looking at PDF or some other print, are the fonts embedded in the print output? Are you picking up the fonts from the same location or have you inherited new fonts?
Anything you can think to help describe the details of the situation might offer clues on where to look next.
Thanks for your quick response.
It's a text area within a section. Paragraph settings are set to Left. No special formatting to static or field (Univers 16010). Hidden field is populated via a DAL rule that returns plain text with no spaces at the beginning or end, again no special formatting on the hidden field, same font as the static text.
This was a PDF output comparison between 11.3 and 12.2 unit tests (using same fxr).
The sample image I've provided is of static text, meaning there isn't any calculation or variability on those characters.
"information: " is how it's coded statically. The variable prints next to that within the text area.
Your help is greatly appreciated.
FSISYS settings for PDF were the issue.
Upgrading from previous Studio versions, the PDF PrtType settings were not adjusted with the assumption of backwards compatibility.
Cleaning up the FSISYS fixed the pdf rendering issues.