Jump to content

tobarstep

Registered Users - Approved
  • Posts

    71
  • Joined

Converted

  • Location
    Florida

Converted

  • Occupation
    Programmer / Analyst

Converted

  • FusionPro Products
    Yes

Converted

  • Acrobat Version
    Acrobat X (10)

tobarstep's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done
  • One Month Later

Recent Badges

10

Reputation

  1. What's really strange is that I haven't visited this site in many months until today, and I come across this thread. Sadly, I don't remember what became of this. We've upgraded FP quite a few times since then.
  2. It seems like maybe you have not checked the box "Treat returned strings as tagged text" in the rule editor window.
  3. Thanks. That's exactly the information I was looking for, and sheds some light on a recent problem job we had.
  4. I've looked through my documentation, and I've searched here on the forum. I can't seem to find a description of what legacy leading actually does. Clearly it changes my output, but how? What is going on there?
  5. So, I have solved my own issue by doing something that I didn't think would actually work. It seems the quad attribute of the <p> tag can actually have more than one value, so starting my text with <p br="false" quad="JC"> actually ends up both centering AND justifying. Interestingly, quad="CJ" does not work.
  6. I don't think this is necessarily a JavaScript question, but it seemed a good place to get answers. I have a problem posed to me by our design team that they've been unable to overcome. They have a block of text that needs to be fully justified in the text box, but whatever is left on the final line needs to be centered. Applying justification by itself causes the final line to be left-aligned. I've tried several combinations of the <span> and <p> tags to no avail. I can get the final line centered, but even when it's wrapped in a <span> tag it forces all of the preceding text to be centered instead of fully justified. Of course, this was done on static text, which the final product will not have, making the issue even more complex. Any ideas?
  7. One thing to note about standard Code 39 is that the asterisk (*) is used to delimit the data and can't normally be used in the data. That yours is allowing it and returning a /J seems to indicate that you're actually using an extended Code 39 as described here and here. I don't know abut the /M unless your dash is being interpreted as an en or em dash. The second link I posted also indicates that if you are using the extended ASCII Code 39 then your scanner needs to be set up for it or it will return the data as /J, etc. I'd try encoding just some standard alphanumeric data [0-9][A-Z] and see how that scans.
  8. I've never used the drag and drop before, but I whipped up a quick sample and it worked as intended. I'm attaching a jpg screenshot of what my rule looked like in the drag and drop editor window (my field name was "Qty_S" and I used 25pt font, but you get the idea). After I saved the rule I inserted it into a text frame and it worked fine. Incidentally, if you put in the rule that way and then click the button to convert the rule to JavaScript you get essentially the combination of what users FreightTrain and step posted.
  9. OK, that makes perfect sense with what we've seen. We upgraded to 9.3 from 8.7 so this was the first time we'd seen the files as Unicode. Now that we've made the adjustments to our scripts everything works just fine.
  10. I don't see it mentioned anywhere here, so I'll throw this in since we are currently using the pre-release 9.3.12 version. We haven't noticed any real issues but there are a few minor quirks that have popped up. 1) The rule editor window is displaying fonts at an unreadable size (extremely small). The problem seems to be that no font is selected in the editor window settings. Opening the settings dialog and selecting a font fixes this. This is after upgrading systems that had displayed properly previously. 2) Files like the "cfg" and "msg" now seem to be Unicode instead of ASCII. We had some users open a cfg in notepad.exe to make changes and it appeared to them as one, run-on sentence. I had them open it in another text editor (Notepad++ in this case) and it displayed fine. Maybe the line terminators have been changed from CRLF to just CR? We also have some VBscripts running externally that parse msg files looking for certain data. I had to alter the scripts to force the text streams to be read as Unicode, otherwise they were returning gibberish as I assume they were defaulting to read ASCII. Neither of these are necessarily "broken", as we've taken care of both. I just wanted to bring them up as much for clarification as reporting any issues. (I'll need to update my signature from 8.2.7 to 9.3.12)
  11. Thanks. Has the patch been released yet, or is there any way we can get it pre-release?
  12. Thanks. I was having trouble figuring out what was causing the preprocessing in one of my templates and not the other. It seems someone had incorrectly set the imposition in one of them to stack even though the data files are only 1 record each. I guess I'll have to postpone testing anyway since we do have many more jobs that do require a stacked imposition.
  13. I posted this in the VDP Producer API (server) forum but maybe that wasn't the proper place for it, so I'm linking it here. Anyone know if this is an actual issue or something that can be corrected with a change to a setting somewhere? If it can't be corrected, then it might actually stop us from upgrading as it would cause conflicts in a number of automated processes we have. http://forums.pti.com/showpost.php?p=15883&postcount=1 Thank you.
  14. The CreateResource() is returning an error since the file you're looking for doesn't exist. You could wrap it in a try/catch block. So, if you're only looking at aao_1 when aao_2 is empty, this worked for me: if (Field("aao_2") == "") { try { CreateResource(Field("aao_1") + ".pdf"); activatePage(1,2); return; } catch (e) { // Do nothing } } activatePage(3,4); Of course in my testing I didn't have your custom function so I was just using FusionPro.Composition.SetBodyPageUsage(), but the principle is the same.
  15. We are in the process of upgrading our server installs to v9.3.9 from v8.2.7. I've been running some parallel tests and have noticed an issue with the output file names. Under v9, whenever a job has some preprocessing, the resultant output file name has a "1" appended to it. We have not seen this behavior under v8. Nor do we see this under v9 when a job has no preprocessing. It seems like the output file is actually being created twice. For example, if I already have a file "Sample.pdf" residing in the output folder and I run a new job that will compose "Sample.pdf", then under v8 the file gets deleted and the new file takes its place with the same name. Under v9 the file still gets deleted but the final output file that gets created is actually "Sample1.pdf". Even if the output file does not previously exist, the "1" is still appended to the file name. We specify the output file name in the command-line invocation but it is still being altered. I'm attaching 2 "msg" files (extension changed to "txt" so I could upload) that show I'm using the same set of "cfg" and "dif" files for the preprocessing job. So, is there a setting somewhere I can change for this? I don't see anything in the "cfg" for the template. version8_preprocess_example.txt version9_preprocess_example.txt
×
×
  • Create New...