Yes, it does print to paper with those conditions described. The way you have displayed my file in acrobat is not correct; attached is a screengrab of how it should appear and does appear in Preview - note the solid hatch fills in the figure and the solid white behind the pattern hatch:
Screenshot 2023-07-25 at 7.44.17 am13381920 260 KB
I am trying to do a questionnaire in InDesign, with multiple choice questions. I want the user to be able to see if the answer they selected is correct or not once they clicked, and so I want to use the check sign and the X sign as such:
Is there any way that checkbox will not appear? I have been trying everything! a button wouldn't work because I need the appearance to stay. The radio button also does not work because there are several correct answers.
Can I put a button on top of the other? I guess my best option will be to have the red mark or green to appear at the end of the question with a show/hide field. It is so much easier to do this if I was exporting to Epub
You can turn it off in Acrobat, but be aware this is an application setting, not a document one. So, even if the PDF is displayed fine for you, this feature might be turned on in any other user application.
I am talking about the appearance of the checkbox. Acrobat has a set look for the checkbox, that thick black check mark. Even if I change the appearance of the checkbox in InDesign to be i.e a red cross, once it is exported and I select the box it will come back to the black check mark.
This has NOT been "solved." While you can turn off "Highlight existing fields" locally on your own computer, it will not correct it for other users who are sent a form and are opening it on their own computer where this feature is on by default and your checkboxes are back to behaving weirdly and displaying the default appearance rather than the custom appearances created in InDesign. In addition to this, it's helpful to highlight the form fields (not buttons or checkboxes) where you enter text, yet all interactive elements lumped together in this feature. Because of this, the javascript some people have shared as a solution (which also changes the Acrobat setting on the computer belonging to the user opening the file, which may upset people) is not an option for everyone (myself included).
As an example, I am repurposing the radio buttons from my first answer since they most closely resemble yours. Both are now changed to buttons, and I removed the rollover and/or click states. I put one under the other to demonstrate, but you would need to put them on top of each other to get the desired effect, after you get them working.
The X icon has a show/hide action assigned to On Release or Tap to hide button 1 when it is clicked on, and show button 2. The visibility icons show that when you Release the mouse or Tap the screen, button 1 will hide and button 2 will show.
This has NOT been "solved." While you can turn off "Highlight existing fields" locally on YOUR OWN computer, it will not correct it for other users who are sent a form and are opening it on their own computer where this feature is on by default and your checkboxes are back to behaving weirdly and displaying the default appearance rather than the custom appearances created in InDesign. In addition to this, it's helpful to highlight the form fields (not buttons or checkboxes) where you enter text, yet all interactive elements lumped together in this feature. Because of this, the javascript some people have shared as a solution (which also changes the Acrobat setting on the computer belonging to the user opening the file, which may upset people) is not an option for everyone (myself included).
One cannot know the PDF reader app that will open the PDF with the form fields and if Forms preferences are on or off, also if JavaScript is enabled or not, if Adobe Reader is used or not. If on desktop machines or not. So I think, this problem cannot be solved. There is no way I can see with Acrobat's form field technology.
Not solved-no one should tell every user of their form to change their prefernces. I just downloaded latest Apr 2020 version of acrobat reader to check on this issue (default check mark overriding indesign choice) and it is still this way. Adobe needs to fix this otherwise what is the point of selecting another choice. They own both pieces of software (indesign and acrobat) they can get them to not undo each other.
An update on this one, the September 16th release brings a new capability for the Flexera agent to recognize the activated edition (for all users who have logged in the last 90 days on a computer) of Acrobat by reading the "ActivationLevel" registry entry.
Make sure that your inventory settings let the "InventorySettings.xml" to automatically take the latest version (66) and you will take advantage of this new data collection. More information on: -6/RN-chg-AgentAdobeExtension.html
Done some more research and it seams that a registry value needs to be read to set the correct product to reader. It might be possible to have a workaround in the agent to add the registry key and evidences, but will go for a ticket to the content team.
Our plan is to stop using the ambiguous add/remove program evidence from Acrobat DC, add it to Acrobat Reader, and enhance the WMI evidences we use for Acrobat DC (Created from the SWIDTags that have not been systematically managed in the last versions), with the patterns below.
I would prefer we use the existing WMI evidences collected from the SWIDTags than change the agent to collect a new registry entry (by the way, thanks for your investigation, I had found the IsAcrInstalledInRdrMode in the same node but the key you provide looks good!).
@nrousseau1 It seams that I do not have any newer Acrobat WMI evidences in the FLX_Adobe class. Could that relate to this issue since we are running the onpremise 2021r1?
Known Issue: Adobe Acrobat 2020 edition does not get recognized based on inventory gathered by the F... - Community (flexera.com)
You can run the query below (you can uncomment to get only the computers where 2021 Continuous Pro exists but performance is poor) and hopefully will see many records. Can you confirm this? I can verify this with other customers.
You are right Acrobat reader as a common add / remove program evidence, but no WMI. So, you could theoretically ignore the add / remove evidence and add the WMI... The issue is that you can't make WMI evidences clever (for instance 21.%.20%), unless inserting them in the database.
We have a few sites which has the Adobe Cloud products and can see very few results and I can also see a lot of leftovers from earlier versions. For our major sites we run FRL-Offline 64 bit package and they do not show up in the query with/without the uncomment rows.
Hello Nicolas! Based on your comment Our plan is to stop using the ambiguous add/remove program evidence from Acrobat DC, add it to Acrobat Reader, and enhance the WMI evidences we use for Acrobat DC (Created from the SWIDTags that have not been systematically managed in the last versions), with the patterns below. When do you think you'll be getting something in place?
Hello @JenMaier , please check also on your side. We are looking for confirmation that data is here and consistent to extend the ARL (and remove the link to the add remove program)... your help will be useful confirming this. Then, this is a matter of a week to wait for the next ARL build. Thanks for sharing your observations.
The fact older versons appear, related to swidtag files that stay after upgrade (unless the WMI evidences are here even when applications have been installed) should not be a big issue as consomption will not be augmented...
@mag00_75 , could you please share by email nrou...@flexera.com the extracts of a computer deployed with FRL-Offline 64 for installer, file and WMI evidences tabs. We need to find and accurate evidence...
@nrousseau1 After the new ARL it looks better, however still need to be extended for the 22.xx releases of Acrobat DC Reader, Standard and Pro.
I have mailed you some screenshots and Swid from our FRL-Offline installations, and the NDI files are included in the support case.
So, what happens if you are not using the FlexNet agent and are getting inventory from JAMF and SCCM? WMI does not really come in. Why can't Flexera use a combination of Distiller and Acrobat to determine if it is not Reader. That would seem to be a pretty direct way of identifying at least free versions from paid versions.
I tested the swidtag by uninstalling the Pro version, rebooting, reinstalling from CC Desktop and the swidtag did not get updated, so no, i don't trust those entirely. Once I reinstalled, I show one entry for Adobe Acrobat Reader DC and then another for Adobe Acrobat DC (the Pro version - see attached). I am working with our packaging team to add Pro to our deployed packages.
I'd be careful on the suite, unless you do one massive piece of file evidence that can be applied against different versions (for example, Adobe DC shows up as 22.x but Distiller is 21.x - so the required could kill that idea, but Distiller is the best way of determining Pro/Standard from Reader.
see attached for file evidence. I think one of the real problems is that AcroRd32.exe appears in both versions. However, acrobat.exe is unique to the Pro Install, as is AcroBroker and AcroDist. But the distiller version can differ from the executable. The Pro version executable has no file size, so not sure why that is not being distinguished from the Reader Version
Greetings to everyone on this thread. Just wanted to share my personal experience on this topic.
Yesterday my local install of Acrobat Reader on my Windows 10 machine self-upgraded to version 2022. After the upgrade:
1 - My Add/Remove Program Name simply says "Adobe Acrobat DC".
2 - My Start Menu now says "Adobe Acrobat DC"
3 - The Start Menu shortcut launches ACROBAT.EXE
So, looking at my Installer and File Evidence, it is now the same as if the full version of Acrobat DC is installed.
And, when I launch Acrobat DC from my Start menu, it does in fact launch Acrobat Reader. When I go to Help