MailGuru
Well-known member
We installed the XMPie upgrade 6.0.2 to our SI XMPie server. We did encounter the font restrictions problems like everyone else, and we worked around it by replacing fonts in all our documents (a large task since we are talking 75 or so different 24 to 36 page booklets).
Now, a week later, we found out that it has been corrupting our dates by reformating them to the European format. From a CSV file, we feed the data into the uProduce server as MM/DD/YYYY and it switches it to DD/MM/YYYY. This causes many problems with regard to expiration dates, etc. For instance, give it a date of "02/05/2013" and it will change it to "05/02/2013".
The problem has been escalated to tier 2 support, and, they say they have a resolution by using nested date functions within XMPie. We haven't tried it yet, but, I don't understand the logic behind XMPie changing the data we send it. When merging from a CSV text file, we would expect uProduce to place the field on the document EXACTLY as we have it formatted in the data. Is that too much to ask?
Has anyone else run in to this problem? How did you fix it?
Now, a week later, we found out that it has been corrupting our dates by reformating them to the European format. From a CSV file, we feed the data into the uProduce server as MM/DD/YYYY and it switches it to DD/MM/YYYY. This causes many problems with regard to expiration dates, etc. For instance, give it a date of "02/05/2013" and it will change it to "05/02/2013".
The problem has been escalated to tier 2 support, and, they say they have a resolution by using nested date functions within XMPie. We haven't tried it yet, but, I don't understand the logic behind XMPie changing the data we send it. When merging from a CSV text file, we would expect uProduce to place the field on the document EXACTLY as we have it formatted in the data. Is that too much to ask?
Has anyone else run in to this problem? How did you fix it?
Last edited: