tobarstep

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.

It seems like maybe you have not checked the box "Treat returned strings as tagged text" in the rule editor window.

Thanks. That's exactly the information I was looking for, and sheds some light on a recent problem job we had.

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?

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.

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?

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.

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.

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.

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)

Thanks. Has the patch been released yet, or is there any way we can get it pre-release?

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.

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.

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.

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

Your file works for me as well. Looking at your data though, I can see that whatever application you exported it from added the double-quote text qualifiers by default. This actually furthers my suspicions that FP is seeing the quotes as text qualifiers rather than simply characters in the data if the quotes appear at the start of the string. For a CSV that's fine. For a tab delimited file I don't think that is desired behavior. I guess my only recourse at this point is to add an extra logic layer prior to FP composition to reformat fields containing double quotes. It also looks like the quotes that are inside the string got converted to a "fancy" quote of some sort as the character didn't transfer well from the Mac to the PC, but that's not really an issue.

Thanks for looking at it, but CSV is not an ideal format for my purposes. Since my data frequently contains commas, CSV would necessitate the use of a text qualifier, which is typically double quotes. I suspect that is what is happening here. Even though I'm using tab delimited and not CSV (which is really just comma delimited) FP is still seeing the double quotes as text qualifiers. That sort of defeats the purpose of using a tab delimited format. Though, just out of curiosity I tried a CSV file, but got the same results anyway.

No, the data has never been in Excel. Here is a screenshot of a test I just did. I typed this directly in Notepad, hitting tab between fields. I had to chop it up some to get in the file size limits, but it should all be visible.

Thanks Mark. Unfortunately it is a bit sensitive still. I did do some experimenting though and found that if a field has a double quote in the middle, it is fine. It's only when the first character of the field is a double quote does it cause a problem. I have a date field in the data which is 5/7/2009 If I put quotes around the middle 5/"7/"2009 then that is exactly what displays. If instead I put quotes at the front "5/"7/2009 then all I get is the 5/.

I'll see if I can attach a screenshot of what I'm talking about. This is a shot of the preview record selector, which I don't believe is impacted any particular formatting rules. In the tab delimited text file, that field has the full text the double quotes around the AAA but it is not being read for some reason.

Yes, that displays correctly.

Thank you for your reply, Alex. Unfortunately the data is not being read into FP to begin with as far as I can tell. The specific record in question is for a sale sign for batteries. In the text file, the field reads "AAA", 8-ct package but when looking at the record in either the preview record selector or the Fields tab in the Show Building Blocks dialogue, all that appears for that field is AAA In my rules I am already using the normalize entities function.

Using FP 6.0P1e desktop/WinXP and server/2003 (happening on both) I'm composing from a tab-delimited text file, but when I attempt to compose a record with double quotation marks included in the data, FP seems to consider those to be further text delimiters within a field. I have my data source definition set up as a tab delimited file, and I have tried changing the option "Treat field values as tagged text". Neither way made any difference. This isn't the actual data, but for example a field containing: "A"bc is only being read into FP as A, ignoring both the quotes and the text outside the quotes. This is strictly for that field however, as the rest of the record shows fine. Is there a way around this? I don't always have control over the data that I'm sent, and though I have asked them to refrain from using double quotes in the future I'd rather find a way to make it work.