I am writing to report an issue regarding the behavior of Push Button fields created within PDF-XChange Editor.
When a Push Button field includes both a label (text) and an "Up Icon" (image), clicking the button only offsets the label, while the icon remains completely static. This breaks the visual "pressed/pushed" effect.
Below are the details of my environment, reproduction steps, and a deep-dive technical analysis of the underlying PDF code. I have also attached a verification video demonstrating this issue.
Steps to Reproduce
- Open PDF-XChange Editor and create a new blank document.
- Select Form tab and click Button to create a new Button Form Field.
- Open the Push Button Properties and set the following:
- Layout: Any layout that includes an icon (e.g., "Icon only" or "Icon top, label bottom").
- Behaviour: Push
- Up Icon: Specify any image file (PNG/JPEG).
- Up Label: Input any text (e.g., "PDFXCE").
- Switch to the Hand Tool to test the button.
- Click and hold the button, and observe the visual feedback on the screen.
As seen when creating a button in Adobe Acrobat (even in older versions like Acrobat X), both the Label and the Up Icon should simultaneously shift down and to the right by 1 pt / 1 point (offset) when the button is pressed, creating a literal "pushed" visual effect.
Actual Behavior
In the button created by PDF-XChange Editor:
- The Label (text) shifts down and right correctly.
- The Up Icon (image) remains completely static and does not move at all.
Cross-Platform Verification Results
- File created in Acrobat X:
When opened in PDF-XChange Editor, the push effect works perfectly for both the label and the icon. - File created in PDF-XChange Editor:
When opened in Adobe Acrobat, the icon still fails to move (only the label moves).
Critical Omission: Visual Property Modifications Corrupt the Correct Code
Furthermore, I discovered that modifying any visual property of an Acrobat-generated button completely destroys its working code:
- Open a PDF containing a perfectly working button generated by Adobe Acrobat (where both label and icon push correctly).
- Inside PDF-XChange Editor, make any visual or appearance modification (e.g., resizing, moving, or changing the border color). Note: Modifying non-visual properties like the field name does not trigger this.
- Save the document and test the button again.
This behavior proves that whenever PDF-XChange Editor triggers a full regeneration of the Down Appearance (/D) stream due to a visual property update, its engine completely fails to recalculate or write the proper 1 0 0 1 1 -1 cm transformation matrix for the image XObject, actively replacing Acrobat's correct code with flawed logic.
Code Snippet Analysis
Below is the comparison of the Widget Annotation dictionaries generated by Acrobat and PDF-XChange Editor under identical conditions.
- Acrobat-generated (Works perfectly):
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<< /AP << /D 15 0 R /N 16 0 R >> /DA (/HeBo 12 Tf 0 g) /F 4 /FT /Btn /Ff 65536 /H /P /MK << /BG [ 0.75293 ] /CA (Acrobat) /I 17 0 R /TP 2 >> /P 4 0 R /Rect [ 104.292 538.141 282.155 704.685 ] /Subtype /Widget /T (Button1) /Type /Annot >>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- PDF-XChange Editor-generated (Problematic):
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<< /AP << /D 11 0 R /N 12 0 R /R 13 0 R >> /DA (0 g /Arial-BoldMT 12 Tf) /F 4 /FT /Btn /Ff 65536 /H /P /MK << /BG [ 0.753 ] /CA (PDFXCE) /I 14 0 R /TP 2 >> /P 8 0 R /Rect [ 85.587967 534.439026 274.249634 719.330994 ] /Subtype /Widget /T (Button1) /Type /Annot >>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Both applications correctly generate separate Form XObjects for the Down Appearance (/D). However, PDF-XChange Editor fails to apply the proper coordinate transformation matrix (offset) to the image XObject referenced by /I inside the Down Appearance stream (11 0 R).
While the PDF viewer automatically offsets the text label defined in /DA upon clicking, the image XObject in the /D stream remains statically positioned because PDF-XChange Editor writes identical layout coordinates for both /N (Normal) and /D (Down) states.
Deep-Dive Stream Analysis
Here is the exact proof from the generated PDF source code, showing the difference between Acrobat's working Down appearance and PDF-XChange Editor's problematic Down appearance streams.
1. Adobe Acrobat X (15 0 obj - Down Appearance):
- ___________________________________________________________________________________________________________________________________________________________
15 0 obj
<< /BBox [ 0.0 0.0 177.863 166.544 ] /FormType 1 /Matrix [ 1.0 0.0 0.0 1.0 0.0 0.0 ] /Resources << /Font << /HeBo 11 0 R >> /ProcSet [ /PDF /Text ] /XObject << /FRM 17 0 R >> >> /Subtype /Form /Type /XObject /Length 306 >>
stream
0.75293 g
0 0 177.8629 166.5443 re
f
1 1 m
1 165.5443 l
176.8629 165.5443 l
175.8629 164.5443 l
2 164.5443 l
2 2 l
f
q
1 1 175.8629 164.5443 re
W
n
1 0 0 1 1 -1 cm ← !!! CRITICAL: Acrobat explicitly injects an offset matrix to shift the content right and down (1, -1) upon clicking.
q
2 17.814 173.8629 146.7303 re
W
n
0.667 0 0 0.667 88.9314 91.1798 cm
0 g
/FRM Do ← The image XObject is drawn inside the shifted coordinate system.
Q
0 g
BT
/HeBo 12 Tf
0 g
66.275 5.264 Td
(Acrobat) Tj
ET
Q
endstream
endobj
___________________________________________________________________________________________________________________________________________________________
- ___________________________________________________________________________________________________________________________________________________________
11 0 obj
<< /BBox [ 0 0 188.661667 184.891968 ] /Resources << /Font << /Arial-BoldMT 6 0 R >> /XObject << /Fm0 14 0 R >> >> /Subtype /Form /Type /XObject /Length 229 >>
stream
.753 g
0 0 188.662 184.892 re f
q
2 19.184 184.662 163.708 re W n
q
.744127 0 0 .744127 12.476852 19.183998 cm ← ERROR: PDFXCE maps the image to the exact same absolute coordinates as the /N (Normal) state.
/Fm0 Do ← The image XObject is drawn WITHOUT any offset.
Q
Q
1 1 186.662 182.892 re W n
BT
0 g 0 Tc 0 Tw 100 Tz 0 Tr/Arial-BoldMT 12 Tf 70.9948 5.512 Td
(PDFXCE)Tj
ET
endstream
endobj
___________________________________________________________________________________________________________________________________________________________
PDF-XChange Editor's form generation engine completely misses the 1 0 0 1 1 -1 cm (or equivalent) transformation matrix inside the /D (Down) appearance stream for Image XObjects (/Fm0).
Please update the form creation logic so that when the behavior is set to "Push", the generated Down appearance stream properly offsets the image transformation matrix to match the visual push effect.
Hoping that the above information will be of some help to you.
Thank you for your hard work on this great software.
Best regards,
rakunavi
- PDF-XChange Editor PRO Version: 11.0.1
- Adobe Acrobat X Standard Version 10.1.16
- Adobe Acrobat Reader Continuous Release Version 2026.001.21771
- OS Version: Windows 11 Pro / Home 25H2 Build 26200.8875
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL
