Dan Korn

You would have to provide the job, or a minimal sample that reproduces the problem, in order for this to be analyzed further.

Did you try "Suppress if Containing Empty Variables"?

Thanks. As noted in this thread, this is a known bug in Acrobat, and we are waiting for a fix from Adobe. Sorry for the trouble.

Sorry for the trouble. This is an issue with later versions of Acrobat and how it handles drawing by plug-ins on Mac. We've been talking to Adobe; they say they are working on a fix for a patch release of Acrobat in June. I don't yet know whether we will also need to make changes to our plug-in to work with whatever change they're making in Acrobat. There is no known workaround to avoid this issue completely. That said, it can be avoided by either lowering the zoom factor or making the Acrobat document window larger. If you keep enough of the active page(s) within the Acrobat window, Preview will work fine. The other thing you can do is just turn Preview off and move the frames. Note that this doesn't affect composition, just the Preview in Acrobat on Mac. Sorry again for the trouble. I'll post back if there are any updates from Adobe.

Are you asking how to accomplish this? You can just make a Graphic rule, either JavaScript, Drag-and-Drop, or Switch Wizard, that returns a different PDF based on the data, and use that in a graphic frame that completely covers the back page.

Yes, of course, there's a limit to everything. The nominal limit is 7,089 characters, though it depends on the encoding mode, symbol size, and error correction level. The spec is here: https://www.qrcode.com/en/about/version.html Also, there are practical limitations on how much data various scanners and applications can scan. If you actually make a QR barcode with 7000 characters, it's going to either be huge, or have pixels so small that any phone will have trouble reading them. So my advice is: keep the QR codes small. If you have to encode a large amount of data, consider encoding a URL to a webpage or a PDF with the information instead.

So, searching for "FusionPro bingo card job" on Google returns this as the top hit, which is a sample job that seems to do exactly what you want. Though there is a more efficient way to accomplish this, especially with newer versions of FusionPro. As to the more general question in the title of this thread, again, if you Google something like "JavaScript non repeating random numbers", there are a lot of threads on Stack Overflow and different sites with various solutions. I would just do this: var result = []; while (result.length < 24) { var num = Math.floor(Math.random() * 75) + 1; if (result.indexOf(num) < 0) result.push(num); } return result; And in FP 13, you could modify this slightly as a table data rule: var nums = []; while (nums.length < 24) { var num = Math.floor(Math.random() * 75) + 1; if (nums.indexOf(num) < 0) nums.push(num); } nums.splice(12, 0, "FREE"); var result = []; for (var i = 0; i < nums.length; i += 5) result.push(nums.slice(i, i + 5)); return result; Then you can the "Table Style" rule, and then create the "Table - from data rule" rule, with the rule above as the data rule and the Table Style rule as the style, and add columns to get five of them. Then you can just tweak the properties in the style rule to get the output you want.

What version of FusionPro? What operating system?

Are you running Acrobat version 2024? If so, we will have a release that installs to that available shortly. In the meantime, you will need to install Acrobat 2023 or older. If not, then what specific version of Acrobat are you running? Also, Windows or Mac?

Please email FusionProSupport@marcom.com. You'll need to include your serial number.

I don't know any reason why that would happen, but I can't analyze this without any more information. Is this a multi-line record job? And what data format (tab-delimited, Excel, etc.)? If you can collect up a minimal sample that reproduces this, please post it here or send it to Support.

I see two pictures, but what are they? Is one the output from your "other barcode creators" and the other the output from FusionPro? If so, which is which? And what are the other barcode creators? Also, exactly what data are you encoding in each? Finally, what scanning device and app are you using? (I can't get the picture that has the text $DJX9C0FZ to scan as a code 39 in any of my scanning apps.)

Well, instead of doing something similar to superscript, you could actually use superscript. Though it may be simpler to just subscript the box, like so: var psubox = '<f name = "Wingdings 2">' + '<z newsize = "18">' + "<subscript>*</subscript>" + '<f name = "Courier New">' + '<z newsize = "6">' + '&nbsp;'+ '&nbsp;'; And you can modify the subscript ratio and offset in the Paragraph Globals dialog, or with attributes of a <p> tag, such as '<p br=false suboffset=30 subratio=200>'. Though I would have taken a different approach to this completely, such as a table. If you make the table correctly, you don't need the Wingdings character for the box; that just becomes a table cell with an outline, and the cells with the text can have their vertical alignment set to middle. Or, you could use a repeatable component, and make a separate graphic frame for the box, which again, can just be an empty square frame with a border. Even if you want to do this all as regular text, without a table or a repeatable component or anything, you can still use an inline graphic for the box. And you could use <t> tags and set tab stops instead of all those '&nbsp;' entities.

Which bleed setting do you mean? On the Imposition tab of the Composition Settings dialog? Or in FP Imposer? Or in the Export dialog in InDesign? By default, FusionPro will set the Bleed in the Composition Settings to match the difference between the Bleed and Trim boxes on the first page of the template PDF file. But you can change it in the Composition Settings, or, if you're imposing, in FP Imposer, to add more space for variable elements.

I would say that strikethrough is a character style, while uppercase is a character conversion/formatting. Also, strikethrough, like other character styles, is natively supported by the underlying rich text control on both Windows and Mac, which uppercase is not. But as I said, we're working on an easier way to implement character conversion/formatting for variables in the Text Editor without rules. The problem is that the markup generated by the Text Editor for a text flow and a Formatted Text Resource are not quite the same. A text flow uses <para> and </para> tag pairs, while resources use standalone <p> tags. You can always see the markup of a text flow in the .dif (format) file that gets generated when you compose or collect. And the markup of a Formatted Text Resource is in the .def (data definition) file. That said, we could consider a View Source button for the Text Frame mode of the Text Editor that would generate the markup as if it were a resource.

That's not a terrible idea. But let me ask you this: What about <lowercase>? Or <smallcap>? Or "Title Case"? Or any of a myriad of other markup tags? How many buttons should there be? Part of it is technical limitations in the number of attributes that can be applied to the text in underlying edit control, especially the intersection of the controls on Windows and Mac. But mostly, this is a version of a question that we often ask ourselves about the user interface. Do we add every possible option to the UI, making it look like a 747 cockpit with dozens of switches and knobs? Or do we try to keep it simple for basic operations, and, if so, what functionality is considered basic vs. advanced? How can we satisfy everyone? We've talked about making the controls configurable, or customizable, which is a big effort to get right, but it's under consideration. Maybe something like InDesign's idea of different "modes," such as Essentials and Typography. Another idea in the works for the Text Editor is to make it easier to modify the formatting of variable text without writing rules, including case changes (upper, lower, title, small caps), as well as number, currency, date, and phone number formatting. We're looking to centralize these options into a pop-up or fly-out dialog so that they don't make the main dialog more complex. Hopefully something like this will be available in a version later this year.

You can do something like in OnRecordStart to generate a random number between 1 and 10: randomNumber = Int(Math.random() * 10) + 1; Change the 10 to whatever upper range you want. Then you can use that randomNumber variable (or whatever you want to call it) in other rules for barcodes, or just return it as text. You could also do something like this in OnRecordStart to make that JavaScript variable accessible as a text variable, which you can then use in the Text Editor directly without having to make another rule: FusionPro.Composition.AddVariable("randomNumber", randomNumber);

As Fellsway noted: Or you can use the "Format Field or Rule" rule. Then you can use rule in whatever specific text frames you need the uppercase applied. If you want to apply the capitalization in every text frame, you can either do what I specified earlier here: Or you can create the "Global Replace Text" rule (from the Event tab of the New Rule dialog).

This is tough to analyze from the description. Someone from PTI will reach out to you at the email address associated with your account here on the forum. We can probably set up a call to troubleshoot this.

I think you can accomplish this in PostScript output by going to the menu FusionPro -> Advanced -> Page Media, and in the Insert Command File dialog, add a file with a stapling command to the first page. Or possibly the last page. You can also accomplish record stapling and other finishing options in JDF.

Well, yes, the template page, which you are presumably setting as the FusionPro.Composition.impositionSheetBackgroundFrontPage in OnJobStart, is named "background," and the content there is indeed in the background, that is, covered up behind the imposed pages, even behind the static background of the imposed pages. So even though you're calling BringToFront on the frame, it's only bringing it to the front of that background page, and it's still behind the imposed page content. Maybe you just need to check the "Suppress static PDF background in composition" box on the Graphics tab of the Composition Settings. Or perhaps some of your frames are filled with a White background color which you need to change to None. As usual, it's hard to be more specific without seeing the job files.

Thanks, I see the problem. I'll make a bug report and we'll analyze this.

Error 1207 is "too much recursion." This is related to a text replacement rule, either a call to FusionPro.Composition.AddTextReplacement() in a JavaScript rule, or one of the "Replace Text" or "Global Replace Text" Form rules, or more likely, a combination of multiple text replacement rules. You probably have one rule that does something like "replace A with B," and another rule that does "replace B with A," and that sets up an infinite loop, or infinite recursion, which never gets resolved. As is my usual mantra, I would have to take a look at the job to figure out exactly where the problem is.

I've been trying to reproduce this but have not been successful. I think it might depend on specifically what your rule is returning. Can you post a minimal sample job which demonstrates the problem? (A collected job WITHOUT the fonts, or, even better, a PDF template with "None" data source.) P.S. The screenshots are helpful, but are pretty downsampled. It might be better to post a cropped picture just of the part of the page in question rather than the entire Acrobat window.

Thanks mailstar. Regarding performance/speed, we do have some enhancements in the works along those lines. That said, any significant architectural changes, such as multi-threading, would likely be targeted towards FusionPro Server and Producer, which run on Windows only, and not towards Creator (on either Windows or Mac). Also, it's a very badly-kept secret that Creator already runs faster on Mac than it does on Windows (though Server and Producer are still faster, especially for high-volume jobs). So I wouldn't expect much to improve for your Mac-based Creator workflow. Things might be slightly faster under native Silicon than under Intel emulation via Rosetta, but again, I wouldn't expect anything significant. Also, in my experience, 99 percent of FusionPro templates which have "many text/graphic frames" have been painstakingly put together by copy-and-paste, and also have dozens of rules to populate all those frames, and often the logic in those rules is very repetitive, which makes FusionPro do much more work than it should to accomplish what you want. Usually these kinds of jobs can be greatly optimized, and made more maintainable, by centralizing all of that logic into just a few rules, using things like the "Re-evaluate this rule for every text flow" setting, repeatable components, on-the-fly frame creation, and other strategies to abstract out the business logic. I would bet that kind of thing could be done with your jobs. I would have to see one of them to offer suggestions, of course, and I can't commit to fully analyzing and optimizing it, but I'm sure I could point you in the right direction. Regarding feature updates, thanks for the feedback about Copyfitting and the Drag and Drop rule. Can you please elaborate about bullet points? You can use the &bull; entity to output a bullet, generally followed by a <t> for a tab. We do have an internal JIRA database of bug reports and enhancement requests. It's not public, but when issues are reported by multiple users, those do count as "votes" of a sort to inform us that they should have a higher priority. Thanks again for the feedback. Please keep it coming! (Feel free to start a new thread about any specific suggestion or issue.)