Forum Replies Created
How have you created the 2 columns? Are they 2 separate text frames?
If so, which text frame is higher? I think the Line Numbering script will always start with the text frame that is highest up on the page.
There have been several reports of this issue as far as I can tell. The answer seems to be that it is an InDesign bug, meaning that even if you apply the master pages manually in InDesign the issue with the anchored objects occurs.
See here, for example: https://www.id-extras.com/forums/topic/possible-issue-with-mastermatic-and-linked-objects/
Is that the case for you? If you apply the master page manually (without Mastermatic), do the anchored objects still shrink?
I haven’t see this happen myself, but if you could send me a document where it’s happening, I’ll be happy to take a look.
A script could be written to release the selected field from the master page, and rename all those fields on the live document pages.
But again, when you look at them in Acrobat, they will still have a different suffix: MyField#1, MyField#2, MyField#3 etc. That can’t be changed, because it’s something Acrobat does.
Ok, thanks for the screenshot.
I think what’s happening is that your form fields are on a master page in InDesign. Is that correct?
If so, again it’s InDesign that adds this suffix to the field names. To avoid this, you would need to override the master-page item, so that each field on each page actually exists on the real document page, not just the master page.
Does that make sense?
Are you sure you’re dragging them into the Scripts Panel folder of the correct version of InDesign? Perhaps you’ve got 2 versions of InDesign installed and you’re dragging them into the wrong version?
I’m not sure what you mean “so that they ‘fold up’ on their own”?
When I have indentically-named fields and export to PDF, I get, e.g., “Text Field 1#0” and “Text Field 1#1”.
This is something Acrobat does, and it’s not even possible in Acrobat to delete the #0 and #1.
But, despite the suffix, they are still considered to have the same name, and if you type something into one of the fields, the same text appears in the other field as well.
- This reply was modified 4 weeks, 1 day ago by Ariel.
What is the path to the Scripts Panel folder? There are two (Application and User), and perhaps in InDesign’s Scripts Panel you’re not looking in the correct folder?
ArielMay 26, 2022 at 7:08 pm in reply to: Field calculations working in Acrobat, but not Foxit #6761
The issue I think is actually an Acrobat issue, in my opinion. FormMaker applies calculations via scripting, but Acrobat doesn’t quite register them properly.
Foxit looks fairly robust, TBH. I’m wondering if there’s a way of running FormMaker in Foxit and avoiding Acrobat. If I figure something out, I’ll post back.
PS If anyone sees this message, and would like to see better support for FormMaker in Foxit, please leave a comment here! The more people ask, the more likely it will be done.May 15, 2022 at 2:25 am in reply to: Field calculations working in Acrobat, but not Foxit #6751
I downloaded Foxit and gave it a spin. It seems you are correct. When calculations are created with FormMaker, although they run fine in Acrobat, they do not work well with Foxit.
The workaround I’ve found is to use a custom calculation script in FormMaker. It’s not quite as easy as using the option “The value is the sum of the following fields”, and then picking the fields, but it’s not too bad.
If your document has 3 fields called Text Field 1, Text Field 2, and Text Field 3, the following custom calculation script (which you may paste into the custom calculation box in FormMaker) will display in Field 3 the sum of Fields 1 and 2:
event.value = this.getField("Text Field 1").value + this.getField("Text Field 2").value;
Custom calculations like this created with FormMaker do seem to work fine in Foxit.
I hope that helps!
- This reply was modified 1 month, 2 weeks ago by Ariel.
I do have a script that will apply a user-defined master page if a user-defined paragraph style appears twice on the same page. PM me for more details.
ArielMay 2, 2022 at 1:28 am in reply to: Tab order not updating on FM export even though correct in ID #6744
Thanks for posting back with your solution!
This is a good catch!
Indeed, any PDF export settings are still applicable even when using FormMaker. That’s why there’s an option upon export with FormMaker to show the PDF Export Options dialog.
I’m not seeing the image (I think you would need to post it on the web somewhere, and then link to it).
However, if I’ve understood correctly, it’s not possible. If you link a paragraph style to a master page in Mastermatic, that master will be applied whether there is one or more of those paragraphs on the page.
ArielMarch 9, 2022 at 1:07 pm in reply to: Fonts embedded into fillable forms only show when clicking into the form #6676
Very hard to say. It could be that your has somehow set the field to not use Calibri?
If you could send me a PDF that shows the problem, I’ll be happy to take a look.
Thanks for your kind words, and glad you’re finding it useful!
DropWord III adjusts the position of the first tab-stop in the paragraph to be flush with the beginning of the second word on the first line – in order to create the “window.”
The position of tab stops is part of a paragraph style. So if a tab stop is moved manually (or by a script), it becomes a style override (marked by a + next to the style name).
So, unfortunately, there is no way to avoid the fact that paragraphs that have a dropword show up in InDesign as having a “local override.”
ArielFebruary 10, 2022 at 7:36 pm in reply to: IBAN fillable field with required exact number of digits #6651
Glad it helped!
You have to convert the Excel list to a single line that looks like this:
var l = this.getField("ListBox"); l.setItems(["One", "Two", "Three"]);
… where, instead of “ListBox”, enter the name of your field, and instead of “One”, “Two”, “Three” replace it with your list from Excel.
As described in the post I linked to, this should be added as a Document script in FormMaker, and that Document script should be removed (in Acrobat) before you distribue the final PDF.
This is a workaround, but it makes it a lot easier than using InDesign’s UI for the task.
You can use the method described here: https://www.id-extras.com/forums/topic/formmaker-pro-combo-box-export-values/
ArielFebruary 6, 2022 at 1:46 pm in reply to: IBAN fillable field with required exact number of digits #6640
Also, check out this thread: https://community.adobe.com/t5/acrobat-discussions/convert-input-to-all-caps/m-p/11574372February 6, 2022 at 1:30 pm in reply to: IBAN fillable field with required exact number of digits #6637
There are several ways of doing this, but the simplest and most correct is to use an “arbitrary mask”.
Create a text field, and in FormMaker, click on the Format tab. From the Category dropdown, select “Special”. Then select the last item in the list there, “Arbitrary Mask”.
You can now type in the permitted format for this field. Adobe Help shows what signs are allowed and how they work: https://helpx.adobe.com/acrobat/using/pdf-form-field-properties.html#:~:text=AM%20or%20PM.-,Special,-Zip%20Code
I’m not sure what the exact structure of an IBAN number is, but if it begins with 2 letters followed by 2 digits, followed by 4 letters, followed by 24 digits, grouped in groups of 4, something like this might work:
AA99 AAAA 9999 9999 9999 9999 9999 9999 99
Does that help?
Sure. Open the Swatches panel in InDesign, right-click on a swatch and choose “Swatch Options.” There you’ll see a dropdown called “Color Mode”. Change that to RGB.
You’ll also notice that the colourful icons on the right-hand side of the Swatches panel tells you at a glance which colour mode each swatch is, so it should be easy to find that ones that aren’t RGB.
I think there must be some swatches in the document that are not set to RGB.
InDesign documents aren’t “in” a specific colour mode, any given colour can be RGB, CMYK, LAB etc.
But interactive PDFs in Acrobat are always RGB only. They can’t be anything else, and InDesign converts all colours to RGB when exporting to interactive PDF.
I was getting regular comments from users about the fact that the colours in their interactive PDFs did not look the same as in InDesign. The reason was always that they had used non-RGB colours in InDesign which were getting converted to RGB on export.
So I added this warning to make users aware that a conversion will be taking place.
Update: This issue has now been remedied, and credit card are accepted also for customers in Israel.
(You can download the latest version here: https://www.id-extras.com/shopping-cart/my-account/)
Good suggestion. I’ve updated the script to version 2.1.8 and you can now set defaults:
Run HyperlinkPro with no documents open, set your default preferences, and click Convert to exit. These preferences will now be applied to any new document you create.
Hope that helps!