Jump to content

strido

Registered Users - Approved
  • Posts

    83
  • Joined

Posts posted by strido

  1. Good afternoon -

    I require two rules to be applied to only one field. Field is "Title".

     

    One rule I have forces it to UPPER CASE.

    The 2nd Rule I have changes a "2" to a SuperScript "2".

     

     

    How do I combine those two rules to force it to output the "Title" field with both rules applied?

  2. Good day folks!

     

    I'm getting an error when collecting my data. The zipped file is missing the CFG and DAT files, and I'm not sure why. Something must be wrong with the PDF because I've successfully collected many files today. The log says:

     

    ==================== SUMMARY ====================

    Collection Directory:

    C:\Users\PrePess\Desktop\6-14\

    ------------------

    Composition files:

    C:\Users\PrePess\Desktop\6-14\FT-FP-WELLNESS.pdf

    C:\Users\PrePess\Desktop\WRF Fusion Pro\WRF_TESTDATA.csv

    Graphics resource files copied: 0

    ------------------

    Text resource files copied: 0

    ------------------

    Page media files copied: 0

    ------------------

    Imposition files copied: 0

    ------------------

    ------------------

    ------------------

    ------------------

    ------------------

    ------------------

    Files not copied because other types of errors occurred: 1

    C:\Users\PrePess\Desktop\6-14\FT-FP-WELLNESS.pdf

    ------------------

     

     

    Not extremely helpful, I know. The zipped file (or at least what's in it) is provided. You'll notice that one field isn't in the actual .csv file but that's OK as it's ultimately getting populated on the server here. That rule works as is should for at least a dozen other templates.

     

    I'd like to tell the client to provide a new file if they can, but I'd at least like to figure out what they did wrong to begin with...

    FT-FP-WELLNESS.zip

  3. So this code wound up working courtesy of the guy who knows way more than me:

     

    lcFieldContent = Field("Left_Content")

    var rval = ReplaceSubstring(lcFieldContent,"®","<f name=\"Arial\"><superscript>®</superscript></f>");

    rval = rval.replace( new RegExp("\u00C2","gm"),"");

    return rval;

     

    The newest trick is now on a different job, it's giving me multiple bad characters when trying to populate a simple apostrophe. I've been trying to modify that code above to accommodate a few (specifically the euro symbol, the "TM" symbol and a lower case version of the "A" character above, as well as the capitalized version.

     

    Now, the above code replaces the ® with one in Arial, so it'll populate. I don't need that, I just need to eliminate these guys - € (\u20AC) â (\u00E2) ™(\u2122)...

     

     

    Remember when Prepress was cutting orange paper with an exacto knife?

  4. I have a rule that changes the font of the ® character from Minion Pro to Arial, because the superscript ® isn't a character in Minion Pro:

     

    lcFieldContent = Field("AgentContactName")

    return ReplaceSubstring(lcFieldContent,"®","<f name=\"Arial\"><superscript>®</superscript></f>")

     

    A simple rule that works great, for the client weekly feed. However, there is another process that allows the client 1-offs, they go to their website and populate the data in form fields, and that process isn't going so well.

     

    It is populating the ® as Â, AND correctly populating the ® symbol as superscripted. So the output is as such:

     

    Generic Testname, CIPP®

    The  is Minion Pro, the original font, and the ® is the correct Arial Font, superscripted as it should be.

     

    I've tried a few different rules for replacing substrings and whatnot, but I'm at an impasse. Any thoughts?

  5. The rule

    var result = Field("Mission_Statement").replace(/~/g,"<br />");

    if (Field("AgencyCode") == "TJ" || Field("AgencyCode") == "UW")

    result = result.replace(/-/g, Chr(8211));

    return result;

     

    Results in a blank space where the en dash should be. Is &ndash a better option?

     

    http://i136.photobucket.com/albums/q195/strido527/our_why_zpsfe41cbef.jpg

  6. I think I see it now -

    var c = dbname

    var s = mission statement

    var m = '' (blank space)

     

    So if the dbname is populated, it should read as follows:

    http://i136.photobucket.com/albums/q195/strido527/Capture-13_zpsb186988b.jpg

     

    The DBA Name, then the words "Mission Statement" and underneath, the actual mission statement.

     

    if there's no mission statement it's blank (var m?)

  7. What a strange rule. Most of the lines in it have no effect on the return value at all. It seems to go to a lot of trouble to set the variable "m", which then gets thrown away, since the rule returns something else first.

     

    Could it be a holdover from a previous version of that rule? I guess if it's not doing anything it shouldn't be there....

     

    That's probably because the en dash is a Unicode character, so you would need to save the file as Unicode. Most versions of Excel offer "Unicode Text" as an option in the "Save as Type" drop-down in the Save As dialog. Note that this will make the file tab-delimited instead of comma-delimited, which is better anyway as it's less ambiguous. The Unicode file should work just fine in FusionPro.

     

     

    I can't really articulate what happens to the client's data as I'm not very technical (can you tell?) - but I do know the .csv file ultimately does work. We run a process to (for lack of a better term) unzip the .csv file - that's when it breaks. So I thought I'd make this rule to change the hyphen to the en-dash.

     

    Well, I think you're being a little bit too specific. Presumably you don't want to hard-code that exact text in your rule. I also presume that you don't want to actually put "(ALT+0150)" verbatim into the output; you want the actual en dash character, which can be called out by its Unicode character code point (8211 decimal, from the Wikipedia article in my previous post) using the Chr function.

     

     

    My thoughts on that were to make it as specific as possible to avoid any problems with a hyphen they'd actually want to use, should that arise. However, only keying in on the specific the agency codes should be ok, too.

     

    ...(ALT+0150 - I was just specifying what keyboard combination creates the en dash sorry for the confusion!)

     

    Thanks for your help guys! I'm going to try out this newest code.

  8. Are you only wanting to replace the hyphens with en-dashes in the specific strings you added above, or anywhere they are used in the Mission Statement of the two specific agency codes?

     

    Only when the two specific strings appear. If any other hyphen is populated in "Mission Statement" they should remain.

     

    Are you further implying that you don't want to replace hyphens with en-dashes if they are used in the Mission Statement of any other agency?

     

    Correct. Just those two.

     

    Per my understanding (you want to replace hyphens with en-dashes anywhere they occur in the Mission Statement of two agencies only), I would insert a SWITCH to assign your 's' variable. You could get by with an IF/ELSE since you only have two scenarios (one where the hyphen is replaced and one where it is not), but I have a hunch you may need to add more adjustments in the future.

    switch (Field("Agency Code") {
       case "TJ":
       case "UW":
           var s = Field("Mission_Statement").replace(/-/g,"(ALT+0150)");
           break;
       default:
           var s = Field("Mission_Statement");
    }

     

    The other thing I see that may be an issue for you is that you have two return statements in the code above. Perhaps you just entered your actual code wrong in your post, but if not, the 2nd return will never execute.

     

     

    Where in your code is that added to the code I provided?

    (Not sure what the 2nd return does to be honest, so I'll leave it there...

  9. We have a rule called "mission statement" - it takes the mission statement from the data stream and outputs text based on various parameters. For instance, if the agency populated is "A" - it returns "X" and if it's else, it returns "Y".

     

    Here it is:

    (it also uses the tilde to denote a hard break)

    var c = Field("dbaname");
    var s = Field("Mission_Statement");
    var m = '';
    if (s != ''){
    m = '<b>' + c + ", Mission Statement </b><br>" + s;
    }
    return Field("Mission_Statement").replace(/~/g,"<br />");
    return m;

    So here's the thing. In the same data stream there is an "Agency Code".

     

    Two of the 90 or so agency codes are using the en-dash in their mission statement, presumably to annoy the person doing the template. :( That would be me. We've tried every permutation of converting from the excel spreadsheet to the .csv file I can think of and the encoding isn't working it's changing the en-dash to a question mark, so we're at the stage now where I'd like to modify the above rule to replace a regular hyphen with an en-dash, but ONLY in the Mission Statement Field, and ONLY if agency code is either "TJ" or "UW".

     

    To get real specific, perhaps a rule that says if you see this specific string of text:

     

    Our philosophy - our "Why" - has been

    and for the other agency code:

    Your success is our success - and

     

    while the agency code is TJ or UW, change those hyphens to an en-dash

    (ALT+0150)

     

    This needs to be added to the existing mission statement rule. I'm thinking adding to the "var" statements could do it, but not sure of the syntax. I didn't write the existing rule.

  10. So my client is asking to update a PDF, called "XYZ.PDF" -

     

    I open the new file, and select the data definition wizard, and choose to import a data source from another document. I select the old data definition from last month's version.

     

    Then I go to "Advanced>>Import Files" and select the old PDF, because none of the actual fusion pro data is any different, and then make sure the three options are checked

     

    1) Paragraph Styles

    2) Layout

    3) Colors

     

    Since the actual variable data doesn't change, only some cosmetics on the PDF, I would think this would work. But when I compose it, the resulting PDF shows the old one, not the new updated version that I was working on.

     

    Any ideas on what I'm doing wrong?

  11. http://i136.photobucket.com/albums/q195/strido527/Capture-5.jpg

     

     

    I've got this little issue here with fonts. I'd like to put that bullet / diamond thing in between these fields. All three fields are different variable fields. But if I just put them in the text box, should one of those three variables be empty, it'll put two diamonds back-to-back.

     

    The diamonds are wingdings letter "s".

     

    So the rule would have to basically just return the field with the letter s changed to wingdings, that way I can just choose to supress when empty.

     

    Does that make sense?

  12. I have a rule for the recipient's name that is inserted at the beginning of a sentence, to make it proper case:

     

    var Var1 = "RecipientFirstName";

    return ToTitleCase(Field(Var1))+",";

     

    However, it seems that field is empty from time to time, causing the sentence to begin with a comma, then the word "space".

     

    I'd like to add to that rule above, with another rule that says if RecipientFirstName is empty, return only the word "Space"

     

    I should know this by now....

  13. Sorry to resurrect the thread -

     

    I'm having a bit of an issue here, using the typical ProperCase rule:

     

    var Var1 = "AgencyName";

    return ToTitleCase(Field(Var1));

     

    Now, we have two clients that have capital letters in their name - ABC Corporation for instance. What's the syntax so it doesn't come out Abc Corporation? I tried the exceptions listed above but couldn't get that to work.

     

    My client only has the two companies that this is affected by, so it's really not a matter of listing out every possible permutation. We'll be notified if any new ones arise, so it'll just be a matter of plugging them in.

     

    Long story short, I'd like the ProperCase to continue, just not when the letters ABC are involved....

×
×
  • Create New...