Jump to content

NPN

Registered Users - Approved
  • Posts

    61
  • Joined

Converted

  • FusionPro Products
    Yes

Converted

  • FusionPro VDP software version
    8.0

Converted

  • OS
    Win 7 64-bit

Converted

  • Acrobat Version
    Acrobat 9.x

NPN's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post Rare
  • Collaborator Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

10

Reputation

  1. That did indeed work, I changed the font to ='HelveticaNeueLT std Lt' and that also worked fine. Thanks!
  2. I need to change only the '@' in a rule to a different font in an email address. The font used is DIN, which has a weird @, so the customer wants this exchanged with helvetica. The rule as it is now: lower =(Field("email").toLowerCase()) return lower I guess a .replace would work but I don't know the syntax for this case.
  3. After i have installed 9.2.30 and open old VDP's it asks me if I want to convert to Unicode(only once). If i answer yes(or no) and open the file, all the referenced fields with norwegian characters (ÆØÅ) stoppes working. Too solve I have to go through the VDP and insert the correct data field or rule each place there's a norwegian character. Some of these VDP's have been with me through several years worth of FP releases and I have never had this problem before. I now have to use FP8 instead. Edit: Heres how a placed data field(or rule) looks in the text frame: «Bel￸p» (the character replaced is an Ø).
  4. I ended up doing these cards manually, since it wasn't that many business cards. It wasn't worth the effort. Let me know if you figure out a way to do it.
  5. I'm suddenly having this problem too, for the first time. Although I usually don't use the wizard. I make a rule using the wizard and save it, suddenly all rules disappears. I use FP 8.2 (the single-composer version).
  6. Edit: After understanding that there is a another version of FP that always only have had the single-composer, I retract my statement below. Brand value increased Not a cool move to remove that functionality and force us to buy another product. The functionality to compose several records have been available as far back as I can remember in Fusion Pro. And lets face it, there's no added work for you guys in having that functionality, composing 1 is basically the same as composing a 100. This just makes you come of as greedy. And forces me to have two versions of FP installed. Brand value reduced.
  7. Thanks Dan, that works great.
  8. Hi Dan, Thanks for the reply and workaround. I really appreciate it. Today we have to manually change all the generated cards that has special characters(and generate new QR-codes). Speaking of which, I haven't been able to make this work. How would I include this workaround in my rule? var result = ["BEGIN:VCARD", "VERSION:2.1"]; for (var label in info) { if (info[label]) result.push(label + ":" + info[label]); } result.push("END:VCARD"); return MakeQRBarcodeGraphic(result.join(Chr(13) + Chr(10)));
  9. Hi, I just made a VDP. It's a very simple business card. The PDF is 61kb. It contains the usual variable text for business cards, no extra pages or graphic rules. But still the ZIP file grows to 8mb. It's usually just a bit over 1mb for these simple VDP's. I looked inside the zip file and almost the whole 8mb is inside the assets.dat file. How can this be?
  10. So what your saying is that there's nothing I can do to make this work, and there's nothing Printable can/will do to change this? I understand that Norwegian support isn't exactly prioritized, but there's a lot of other languages that uses special characters, like spanish and german. Don't they have the same problem?
  11. Hi, I guess this one is for Dan: I've made a QR-code for business cards in FP 8.0 published on DSF (DSF only supports FP 8.0) The business card sometimes contain special norwegian characters like Æ Ø Å. I've tested with two of the most downloaded and well known QR-readers in the appstore: i-nigma and QRReader. The special characters displays correctly in QRReader but not in i-nigma. However, if I generate a Vcard from an online generator i-nigma suddenly displays the special character correctly, thus eliminating that the functionality is lacking in i-nigma. Concluding (in my head) that it's the FP QR-code generator that is lacking. In FP I use a graphic rule to generate a vcard (2.1) Online I use: http://keremerkan.net/qr-code-and-2d-code-generator/ In which I am careful to specify vcard, version 2.1. Why does FP generate a 'lesser' code, or more importantly; can this be fixed somehow so that the QR-code generated from FP displays correctly on both QR-readers? I'm attaching two examples, one from Fusion Pro and one from the online generator, both vcard version 2.1. If you test using i-nigma and QRReader you should get different results. The online one working on both readers, the FusionPro generated code only displays correctly with QRReader. (The FP Code contains name: Testæøå Test, the online one only name:ÆØÅ)
  12. Hi, I've made a QR-code(vcard) on a business card that returns the resource name instead of the resource itself. The resource is an address and is located in a .txt file. So when you scan the code you get Resource("path") in the address field. The rule createResource outputs correctly on the bus card itself. It should be mentioned that this is a VDP uploaded to DSF. Is it possible to correct this, or is it a limitation?
  13. So when the ultimate goal here is to upload this VDP to Digital Storefront and let the customer fill in the data, it's not possible?
  14. Yes, I use 'Adobe Fangsong STD R'. I've enabled Japanese keyboard in windows.
  15. Is this possible? I have a business card where the customer wants one side in english and one side in Japanese. I've tested a bit, enabling asian character support, but whatever i write or paste in the data field with Japanes characters becomes a bunch of question marks when I save the data file. Anyone had any experience with this?
×
×
  • Create New...