
- #INDESIGN DATA MERGE RECORDS APPEAR DIFFERENT THAN SOURCE HOW TO#
- #INDESIGN DATA MERGE RECORDS APPEAR DIFFERENT THAN SOURCE CODE#
The different encodings (UTF-8, UTF-16, and others) are just different ways of representing the same Unicode characters in data.
#INDESIGN DATA MERGE RECORDS APPEAR DIFFERENT THAN SOURCE CODE#
A capital Eth in the Icelandic language (Ã) is always code 00D0 (hexadecimal), and is stored as 00D0 in UTF-16 and C390 in UTF-8. There are currently more than 100,000 defined, and the current specification allows for more 1,000,000. This allows for more than 256 standardly defined code points. In Unicode, there is not a one-to-one relationship between bytes in a file and characters (except that in UTF-8 encoding the standard 128 ASCII characters are directly mapped to the same bytes they are in 8-bit ASCII). I am looking to learn something new here too, thanks! The font info is in the InDesign master page items that are linked to the data merge document. I have had data merge character translation issues in CS3 when using UTF formats. Perhaps this is because I generally export out a. csv file did not bring in any font or other information, just the raw text. Please correct me if I am wrong, the plain text file does not contain any font information, just ASCII text. csv format - or perhaps tabs separating the fields, which is exported from Excel. The data merge source file is just a simple text file in. Or am I wrong in this regard? There are many formatting options (UTF-8, Unicode etc). The font data is in the original Excel file, however this font metadata would be lost when exporting out a. csv file (unless UTF16 includes font metadata info?). That being said, I don't think that the Chinese font is in the InDesign file, nor is it in the data merge source.

Kyle, thanks for bringing up GREP, it is not easy to learn - however it has a lot of power! The InDesign email list that I linked earlier has a few GREP experts on it and I have tried to follow their posts without too much success, GREP syntax is not easy to learn for the casual user. Any time you see "," it should be "" without the interleaving spaces.
#INDESIGN DATA MERGE RECORDS APPEAR DIFFERENT THAN SOURCE HOW TO#
I don't have time to figure out how to force it to be correct. The outer enclosing brackets define a list of things to match, the caret inverts the match (selects everything that isn't listed), "" means all printable characters including white space (which should include the carriage-return characters but doesn't), and "" means whitespace characters, which will capture the carriage returns.ĮDIT: I guess a colon followed by a lowercase P is interpreted as a code for a smily with its tongue out. This should change all characters that are not normal printable characters to the other typeface. In the "Find what:" field, enter "]" (without the quotation marks), then click on the magnifying glass icon to the right of "Change Format:," and select the font for the Chinese characters. In the Find/Change window, change to the "GREP" tab.

With all of the text in Futura, select Edit>Find/Change. You should be able to do this with Indesign's Find/Change process. Please let the forum know what the solution is when you find it! The best InDesign/Automation source that I know of is here, join up and ask your question (email list): You would obviously like to automate this task. I personally would see if the client could send you a separate database that only has the Chinese names, then you could setup a separate masterpage and data merge with the correct font. There may be some macro or other way to isolate the Chinese text in MS Excell, however that is beyond my knowledge. plain text issue? Why does TextWrangler work correctly and why does InDesign fail? You say that the Chinese looks fine in TextWrangler.what if you open the same file into TextEdit.does it display incorrectly as InDesign does? Is this a rich text vs. If the Chinese uses different fonts, then I am guessing that you need to bring in the character or paragraph sytle into InDesign so that you can map the style to a style and font in InDesign that has Chinese characters. I thought that this may just be a simple font issue, the same font used for both Western and Chinese characters - as some OT fonts contain both character sets.
