WordRTFImportPreferences? It comes with a couple of settings that may apply: preserveLocalOverrides, removeFormatting; perhaps a bit more.

Usually, I would set them to useful defaults in the UI, but ID Server has none of that …

Use GREP.

bl will mark only the first character of a word starting with a lowercase. The b code marks a location, not an actual character, so it will work whether there is a space (or any other non-word character), or nothing at all.

Mind you, XML is not the only way you can import database data. Look at Mail Merge, for example — it should be able to import your CSV (never used it, personally). You can use this if the transition from web text to InDesign is a straightforward one — i.e., import text, apply styles, print, go home.

But if you need to move stuff around, rename and group elements, or add custom texts, XML is the way.

I would recommend not to use InDesign to test your first XSTL transformations with. It doesn't appear to emit any useful errors, and if anything at all is wrong, the XML doesn't appear at all. So I use Saxon, a powerful XSLT processor, through the Kernow GUI. The screenshots are Windows, but it also works happily on my Mac. You edit your XML and XSLT with a good plain text editor (I use TextPad/Windows and TextWrangler/Mac) and process the files with Kernow. Since it has an output window of its own, you can immediately see what happens. You can dot your XSLT with debug stuff like <xsl:message>… thus far it works …</xsl:message>, and these will also appear in the Kernow output window. And if everything seems to work, you can try the same files in InDesign.

(Apart from the huge difference in XSLT versions — 1.0 for InDesign, which covers pretty much the basics and nothing else, where Saxon supports 2.0 plus a handful of extensions — there appear to be a few minor differences as well. My first try did work in Kernow/Saxon but failed in InDesign. I wouldn't know where to start looking for more info on that. Fortunately, there are dozens of different ways to do the same thing, even with bog standard XSLT 1.0.)

The canonical XSLT reference is at https://www.w3.org/TR/xslt, and https://www.w3schools.com/xsl/ contains lots of useful snips and tips.

One thing is important: within seconds (well, minutes anyway) I had something up-and-running using the powerful “for-each-group” and “group-by” XSLT commands. However, InDesign didn't load the XSL at all — those commands are “XSLT 2.0”, and apparently InDesign only can handle XSLT 1.0. I didn't even get an error message …

So I had to take a short round-trip to the web — fortunately, your grouping problem is a well-known one (look for “Grouping with the Muenchian Method”, named after its inventor Steve Muench).

XSLT is a somewhat odd 'programming language', as it's not procedural/structured, like Javascript or Visual Basic, but rather functional (see https://en.wikipedia.org/wiki/C&#8230;.._paradigms) — you define a set of 'rules' to apply, and the XSLT parser runs each of the rules on your input file.

It takes some mind-shifting to “get what you want”, because it would seem that most of the times you don't get anything at all … (when none of your rules appear to match anything of the input XML). So yeah, it takes some practice. But, in the words of Kay, “Oh yeah, it's worth it. … If you're strong enough.”

The DTD is not the correct place to add or remove items; it merely describes what goes where (and with what attributes, and in which order — etc.).

In fact this shows a shortcoming in your XML file: it ought to look like

<categoryHeader>
<contact>
<name><address><etc>
</contact>
<contact>
<name><address><etc>
</contact>
</categoryHeader>

— but in this case, each contact has its own header. I'm sorry for your overheated brain, but … XSLT is the way to transform one type of XML into another type.

Can you post a small sample of what your XML looks like now, i.e., with the cat headers in the wrong position?

That's some funny stuff you got there — I think I'm gonna hold you to that promise!

All created on the computer?

.. That “join(“r”)” line near the top should actually read “join(“r”)”, to insert a return between each line. If I call up the Edit Post, I get the entire script on a single line :(

(It's of no effect to the inner workings of the script but I thought you might to try the sample as-is.)

The getFiles command returns anything that matches the mask you provide. In my example, I limited it to “”*.indd” to get only InDesign files, but — after some deliberating — I decided to add an explicit check because it may also return a Folder named “my files.indd”. (Don't laugh. Of course, me personally would never name a folder something like that, but you'd be amazed.)

This 'explicit check' is right below the for..loop:

if (myList[list] instanceof Folder)
continue;

.. so the entire rest of the loop will be skipped ('continue') if the item under consideration is a folder. To make it scan for just folders, you need to make two crucial changes:

1. Change the pattern of 'getFiles' to (“*”), or omit it entirely — its default is in fact “*”. This will make it pick up any and all files and folders.

2. Change the line after the for.. command to

if (myList[list] instanceof File)

continue;

so the commands below it will only be processed when 'myList[list]' is a folder.

.. Or do i need to write a loop that goes into the folder and scans until it's done?

Well … it depends on what you are planning to do. If you want to 'process' all InDesign files in a certain folder and all the ones in subfolders, possibly nested, you need a recursive routine. If you look up “Recursive” in any good dictionary, it'll read “see Recursive” — that sums it up, I guess.

A good way would be:

1. Don't use the for..loop I gave as an example, but instead define two functions: processFile and processFolder.

2. Start your script with 'processFolder'.

3. Have this function scan for all files, and call the function 'processFile' for each.

4. Then have it scan for folders, and call the function 'processFolder' for each.

You see, hopefully, that #4 is the recursive part: if there is a folder inside your main (starting) folder, the function will call itself and process the files in there. If there is a folder in that, it will call itself and process the files in that one. Et cetera ad infinitum, or until all files & folders are processed — whatever comes first.

Tip: If part of your 'processFile' involves saving the file under a new name, take care not to process these in turn! That might lead to an endless loop, not quite ad infinitum but merely ad full hard disk.