{"id":1311,"date":"2013-03-23T18:36:57","date_gmt":"2013-03-23T16:36:57","guid":{"rendered":"http:\/\/www.ozalto.com\/?p=1311"},"modified":"2013-11-07T15:37:10","modified_gmt":"2013-11-07T13:37:10","slug":"csv-carriage-returns-issues","status":"publish","type":"post","link":"https:\/\/www.ozalto.com\/en\/csv-carriage-returns-issues\/","title":{"rendered":"CSV & Carriage returns issues"},"content":{"rendered":"

Any datamerge user has faced this issue :<\/strong> one “cell” has\u00a0a carriage return<\/strong> (Ex: a two lines adress) but while datamerging with InDesign, everything goes wrong<\/strong> ! Informations are misused or even disappearing. But all your data is right within your table software. A single carriage return has corrupted the the data processing of the CSV\/TXT File by InDesign. Small issue but dramatic consequences.<\/strong><\/p>\n

\n

What’s wrong ?<\/h4>\n
\n

\"CSV<\/a><\/p>\n

Let’s take this simple table. For our “adress” field, we typed in three lines of text<\/strong>. Let’s drop some tags for the demo :<\/p>\n

\"CSV<\/a><\/p>\n

As we require a preview, we can see that something is definitively wrong.<\/p>\n

\"\"<\/a><\/p>\n

The “society” field doesn’t show up within our layout. Even worse, on the next input, it’s gone mad :<\/p>\n

\"\"<\/a><\/p>\n

For most of you, we are just stating the obvious. Once that said, we wanted to offer a deeper explanation of the issue. InDesign does wrong because the carriage returns hosted within the cell were considered as a jump towards the next record<\/strong>. The string next to the carriage return is now considered as the first cell of the next row.<\/p>\n

\"\"<\/a><\/p>\n

\n

A fake good idea<\/h4>\n
\n

We thought we found a\u00a0solution<\/strong> to this issue thanks to a nice\u00a0algorithm<\/strong>. A really simple axiom<\/strong> : get the number of columns and check that every rows enumerate the right amount of cells<\/strong>\u00a0by merging lines and temporarly replace problematic carriage returns with a unique string to be replaced later within InDesign.<\/p>\n

\"algorithme\"<\/a><\/p>\n

In the above figure, the first row only hosts two “cells” when there should be three. We then merge the rows 1 & 2 to to get a three cells row. That’s the main concept. While the first trials were very enjoying, we had to face the awful truth. Our cooking won’t work everytime.<\/strong> Indeed, given how data would be found, it was almost impossible to reconstruct all the lines accurately.<\/strong><\/p>\n

\"\"<\/a><\/p>\n

Considering the red row cell, can we tell if it’s related to the orange cell or a separate cell within the row ?\u00a0No we can’t !!<\/span><\/strong><\/p>\n

\n

Conclusion<\/h4>\n
\n

So it seems impossible to deal with carriage returns within a CSV\/TXT file<\/strong> because sooner or later, there will be some scenario where only the human brain can tell. That’s why InDesign can’t take them into account and so many editors working with CSV. And we won’t do better.<\/p>\n

What else then ?<\/strong>\u00a0If you want to stick to datamerge, you will have to replace carriage returns within your source tables<\/strong> ( Excel files\u2026 ). Just check that a carriage return within your file is nothing but a jump towards a next row. You can use an unique string like ##RC## or any other pattern you won’t find within your data.<\/p>\n

Another solution would be to\u00a0prefer the XML format<\/strong> which can deal with carriage returns. But if you do use another technique, let us know.<\/strong><\/p>\n

Loic<\/p>\n","protected":false},"excerpt":{"rendered":"

Any datamerge user has faced this issue : one “cell” has\u00a0a carriage return (Ex: a two lines adress) but while datamerging with InDesign, everything goes wrong ! Informations are misused or even disappearing. But all your data is right within your table software. A single carriage return has corrupted the the data processing of the […]<\/p>\n","protected":false},"author":2,"featured_media":1310,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/posts\/1311\/"}],"collection":[{"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/posts\/"}],"about":[{"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/types\/post\/"}],"author":[{"embeddable":true,"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/users\/2\/"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/comments\/?post=1311"}],"version-history":[{"count":0,"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/posts\/1311\/revisions\/"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/media\/1310\/"}],"wp:attachment":[{"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/media\/?parent=1311"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/categories\/?post=1311"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/tags\/?post=1311"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}