CS4 also, Joe. Are you importing through Data Merge? Because it refused to see the .xls. If you're just importing as a table, that's not what I'm doing.

Is there something in Prefs to change this?

Oh......no, I was just placing it.After taking at look at the Indy Help file I see:

QuoteAbout data source files

The data source typically originates from a spreadsheet or database application, but you can create your own data source file using InDesign or any text editor. Data source files should be saved in a comma-delimited (.csv) or tab-delimited (.txt) text format.

I guess my next question is...what font was being used in Excel and then in InDesign? When you save as a .csv file any font info is lost. Then when you import it into InDesign it will use whatever font you have selected in your document. If it's different than the Excel doc then that character may not be in the font you are using in Indy. Just a guess on that though. Also was the Excel doc created on a Mac or Windows?

Quote from: Joe on July 16, 2010, 10:14:13 PMI guess my next question is...what font was being used in Excel and then in InDesign? When you save as a .csv file any font info is lost. Then when you import it into InDesign it will use whatever font you have selected in your document. If it's different than the Excel doc then that character may not be in the font you are using in Indy. Just a guess on that though. Also was the Excel doc created on a Mac or Windows?

I'll have to check on fonts, though I don't think that's the issue. The enye appears in the original Excel file, but like I said when I generate a .csv from that to import into Indy the enye turns into Symbol characters. I don't recall what font is being used in Indy, but it supports the enye because I can type option-n-n into the text and there's an enye. I will assume the Excel files are Windows and I also received an unhealthy batch of Publisher files with this project.

My guess then is the difference in character mapping between Mac and Windows (until proven wrong). :laugh:

Do you have Indy for the PC you can test it on and see if it works OK on Windows?

Did you say that if you open the .csv in Mac TextEdit you have already lost it?

can you try to save the excel file as .txt tab delimited?
that's what i always do, but I can't recall dealing with any
accent marks.
find change is the only thing I can think of to do.

Im interested in the cut and stack you figured out.

Have you tried opening the .csv in a text editor and then doing a find/change to fix the character?

Try to export it from excel as Text (tab) and make sure that Arial is loaded into the system

Quote from: DCurry on July 17, 2010, 04:22:06 PMHave you tried opening the .csv in a text editor and then doing a find/change to fix the character?

That's probably what I'll do from now on - this is the first time I've ever encountered this and didn't really discover it until it hit bindery. You guys would laugh if you had seen the bindery guy come up to me and say he didn't speak Spanish but these names looked "wrong", lol. Pretty new with Data Merge. Either find/change in the csv or in Indy. This time around none of the names had an accent mark, which is pretty common in Spanish and other languages so I'm curious to see how those come through if I get them.

I'm going to try the other suggestions listed, I'll let you know what I discover. I'll also post some test files on Monday or Tuesday so you can see how to set up a cut & stack multiple-up layout. I also have an Excel file with a macro that easily generates a cut & stack database file for numbering (I only wish I could set up such a macro for a database of names, but it's not as simple as numbering).

Quote from: gnubler on July 17, 2010, 09:04:46 PM

Quote from: DCurry on July 17, 2010, 04:22:06 PMHave you tried opening the .csv in a text editor and then doing a find/change to fix the character?

That's probably what I'll do from now on - this is the first time I've ever encountered this and didn't really discover it until it hit bindery. You guys would laugh if you had seen the bindery guy come up to me and say he didn't speak Spanish but these names looked "wrong", lol. Pretty new with Data Merge. Either find/change in the csv or in Indy. This time around none of the names had an accent mark, which is pretty common in Spanish and other languages so I'm curious to see how those come through if I get them.

I'm going to try the other suggestions listed, I'll let you know what I discover. I'll also post some test files on Monday or Tuesday so you can see how to set up a cut & stack multiple-up layout. I also have an Excel file with a macro that easily generates a cut & stack database file for numbering (I only wish I could set up such a macro for a database of names, but it's not as simple as numbering).

Gnubler, you're using OpenOffice, right? Use the database software in there (or use Access if you have it). Your sorting options are a lot more advanced, and you can easily use SQL queries to do exactly what you're wanting to do. I know you -- you'll catch on to it really quickly. Stop using Excel (or other spreadsheet software) for database stuff! :angry: Seriously, even FileMaker Pro would be better.

Yes, just for the record everybody - when I mention Excel it means I'm using Open Office on the Mac. I have used both apps interchangeably for several years and have noticed few differences between them. Maybe I should be csv-ing the Excel file on Windows Excel and see if there's a difference in how Excel encodes the foreign language characters.

Weird. I created a new spreadsheet in Open Office. Put the ñ in it and exported a .csv file. It has the weird characters in TextEdit but if I open it with TextWrangler the ñ looks fine but Indy still imports the weird characters.

Did some more testing. I think this may be an OpenOffice bug. If I create a FileMaker Pro database and export the .csv the characters show up fine in the .csv. My problem now though is Indy can't use that .csv which makes no sense because the .csv looks fine.

Interesting. Since I have Excel on Windows I'm going to try generating the csv from that and see what happens. I don't have Indy on Windows, though.

Here's some sample files showing how I'm using Data Merge to impose a multi-up press sheet that can be cut & stacked. It takes some extra steps in preparing the database file and having to manually create a multi-up press sheet.

1.alpha-names.xls
My sample Excel spreadsheet file, just a list of names sorted alpha by last name. (I shortened the database for this test)

2. alpha-names-6up-c&s.xls
How I set up the new spreadsheet. Because this job is running 6-up I have to create 6 columns of data. (And in this example it's actually 18 columns because each nametag has 3 text boxes - this will make sense when you see the Indy file). I've named each column based on its position on the press sheet (eg: First Name p-1, Last Name p-1, District p-1, First Name p-2, etc)

3. alpha-names-6up-c&s.csv
Saved file from #2 above as a CSV, Unicode UTF-8, field delimeter comma, text delimeter quote (I believe these are all default values in Excel/Open Office)

4. 6up-alpha-names_c&s_CSVimport.indd
Here's my InDesign layout template. I've set these nametags 6-up to run on an 8.5x11 sheet. It has a background layer and a CSV layer. I've selected the CSV file through the Data Merge palette and mapped the correct column header to the correct position on my press sheet (p-1, p-2, etc). Then with my BG layer turned off I create a new, merged document through the Data Merge palette. You can either generate a new Indy file or go straight to PDF. I usually go straight to PDF because I've had larger database lists that end up being 100+ pages long. See screenshot create-merged-doc.jpg for the settings I used for Merge Document (I think these are also the defaults).

5. 6up-alpha-names_c&s_PRINT.indd (or .pdf)
The resulting file (whether it's Indy or PDF) will be 6-up with just the database info to imprint on your background image shells (at least that's how this job was set up).

Since I brought the Spanish enye into this thread I added an enye to the first four surnames in the database, so in my final file you'll see the wacky characters in position 1 on pages 1-4. Still working on how to handle this and need to do some testing on Windows Excel (I did all the above database edits using Open Office on Mac). All Indy files saved as .inx so everyone should be able to open them.