Jump to content

Dan Korn

Administrators
  • Posts

    4,869
  • Joined

  • Days Won

    16

Dan Korn last won the day on February 2

Dan Korn had the most liked content!

4 Followers

Converted

  • Location
    Chicago, IL

Converted

  • Occupation
    Senior Development Engineer

Converted

  • FusionPro Products
    Yes

Converted

  • FusionPro VDP software version
    12

Converted

  • OS
    Mainly Windows 10 Pro and macOS 13

Converted

  • Acrobat Version
    Acrobat DC
  • Homepage
    http://fusionpro.com
  • User Title
    FusionPro Senior Engineer / <b>Forum Moderator</b>

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Dan Korn's Achievements

Grand Master

Grand Master (14/14)

  • Reacting Well Rare
  • Dedicated Rare
  • Conversation Starter Rare
  • First Post Rare
  • Collaborator Rare

Recent Badges

5k

Reputation

  1. 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.
  2. 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.
  3. 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.
  4. 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);
  5. 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).
  6. 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.
  7. 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.
  8. 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.
  9. Thanks, I see the problem. I'll make a bug report and we'll analyze this.
  10. 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.
  11. 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.
  12. 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.)
  13. Thanks for asking. As someone who's worked on FusionPro for a long time, knowing that there's interest like this in the future of the product is heartening. We don't tend to release public roadmaps. Probably the main reason is that plans and timelines can change, based on a myriad of factors, some of which are beyond our control, such as changes that Apple, Microsoft, Adobe, and various standards organizations make that we have to keep up with. I can say that we are actively working on support for native Silicon chips (M1, M2, M3, etc.) on Mac, and that we have several enhancements planned for FusionPro 14 which I think people will be excited about, things that will make template-building easier. Beyond that, we have a lot of longer-term plans and ideas on several fronts, from architectural improvements to new areas of functionality. Sorry I can't be more specific. But just to give a bit of insight, we do get pulled in a lot of different directions. Some of this is the nature of the digital printing/publishing industry. On the one hand, print is far from dead, and printing technology continues to improve and advance, and there is a huge demand for improvements to things like imposition, for finer control over barcodes, charts, and tables, color correction, and other things that go into putting toner on paper or other substrates and fulfilling print orders, including postal sorting and barcodes in different countries, as well as an ever-growing market for label and package printing. On the other hand, there's rapidly increasing demand for digital delivery PDFs, which are primarily viewed online, and which, according to various regulations in different countries (and just because things should be this way), need to be accessible to people with visual impairments, which means they need to conform to accessibility specifications for tagging and reading order, which, when you're merging in variable content with static content from the background PDF, can get complicated. We've also been working for a long with partners around the world, mainly through Ricoh, including our friends in Ricoh Japan, to add typesetting features specific to Japanese, Hindi, Arabic and Hebrew, and many other languages, which have a lot of complex requirements. And we work with many partners on integrations, including with MarcomPortal, EFI DSF, Avanti, RSA's WebCRD, and others. So, there's a lot on our plate, and just prioritizing all of those backlist items is a challenge. The other thing I can say is that feedback here on this forum is definitely taken into account in our planning. Your ideas, suggestions, and even problems you report here do inform our priorities. So... what do you want to see on the roadmap?
  14. ... from what version? What were you running previously? Can you be more specific? What is the failure mode? Does it not recognize any new records at all? Or does it think every line is a record? Can you post a minimal sample job that reproduces the problem?
  15. FusionPro VDP version 13.1.4, which fixes this, is now available at our Downloads page, and is supported in MarcomPortal. Thanks for you patience and sorry again for the trouble.
×
×
  • Create New...