Javascript find/change fails

[Matthew Williams CMH]

Hi all

I've written a small javascript to replace tags in a document with formatting, but it's not working, and I have no idea why. I know that the code below is correctly populating the find and change fields in the dialog, and I know that if I open the find/change dialog and click "Find Next," this works. Run from the Javascript, however, the actual find/change is not effected. Can anyone see a problem here that I'm missing? (This is the complete code other than a couple comments.)

Thanks!

m.

-----

app.findChangeGrepOptions.includeFootnotes = true;

app.findGrepPreferences.findWhat = "¦case:all_caps¦(.+)¦/case¦";

app.changeGrepPreferences.changeTo="$1";

app.changeGrepPreferences.capitalization=Capitalization.ALL_CAPS;

app.activeDocument.changeGrep(); //This line seems not to work

[Matthew Williams CMH]

Lol. So much to respond to!

I'm not sure I'm ready to give up on text-file import, which has been so reliable for me. There would still be Word-to-InDesign issues that would have to be overcome—like the discretionary line break that I mentioned. Those are not insurmountable, but I worry that other problems of which I'm not yet aware would emerge. I'd also have to look into adding structure and tags to a document that was not created from an XML import.

As I think about what would be involved, I realize that preprocessing for a Word import would not improve on my current system of preprocessing for a Tagged Text import. In fact, it would complicate the import process. I'd still have to plant some tags in the Word file for postprocessing in InDesign. There's no gain there because I'm already doing that with my macros, and right now, using Tagged Text, I don't need to do any postprocessing in InDesign. In addition authors do dumb things like colorizing spaces, and that kind of detritus would all get imported unless I vastly increase the cleanup routines in my macros. It's kind of you to offer your macros, but ultimately, I don't think I can count on catching every mess that an author would make. The beautiful part about dumping a tagged file to text is that all that stuff is discarded automatically.

If I abandon the idea of an XML-first workflow, then I might as well stick with Tagged Text (and hope that Adobe doesn't kill it off entirely before I retire). From a postprocessing perspective, I can either import an XML file and postprocess the local formatting OR import a Word file and postprocess some local tags as well as XML structure/tagging OR import a Tagged Text file and postprocess just the XML structure/tagging. It seems like at least for now, I would be better to stick with Tagged Text and work on postprocessing routines to structure the document

Just to answer your question about cstyles, I don't use cstyles for bold, italic, boldital, superscript, subscript, underline, etc. In fact, I pretty much never use cstyles at the manuscript stage because InDesign won't allow nested cstyles (except when GREP applies them) except for notes to myself. For example, my macros remove equations but plant cstyled callouts where they need to go within a paragraph.

Having said all that, I think I've settled on sticking with Tagged Text and working on postprocessing the XML structure/tagging. I hadn't worked through all this in my head, so I appreciate you bringing the Word-import option up. It's helped me to clarify my goals.

[Robert at ID-Tasker]

If Tagged Text is working for you - great 😉 

But maybe you shouldn't mix XML at the beginning? If you are adding extra tagging in your text - then do XMLing in the InDesign at the end - as a last step ?

[Matthew Williams CMH]

That's my thought, too. I'll continue as I have for the last 20+ years but develop some Javascripts to prepare documents for export to XML.

Thanks again for your help!

[Robert at ID-Tasker]

About your comment on InDesign not supporting nested CharStyles - not sure how much do you know about internal structure of the text in the InDesign and because there is no proper documentation about Tagged Text - but you can implement your post-processing tags directly in your source Tagged Text file. 

Block of text can be:

- Story, 

- Text, 

- Paragraph,

- Word, 

- Character. 

Then there is a Line - or TextLine - and another VERY IMPORTANT type - TextStyleRange.

There is also InsertionPoint but it's not import right now. 

When you style part of the text in a way that it differs from the surrounding text - it is converted into TextStyleRange - and each part around it into separate TextStyleRange.

So a paragraph with a consistent formatting will have only one TextStyleRange child - but if you change formatting of a part of it in the middle - for example apply CharStyle - you'll get up to 3x TextStyleRanges - and of course only 2x if you re-format text at the beginning or end 😉

So instead of adding tags for No Break and use JS to apply NoBreak - you can just do this directly in your TaggedText - the same way you tag occurrences of CharStyle. 

Can't tell you how you should code it - laying down - but you can reverse engineer it by exporting sample text and checking what InDesign will export 😉 

[Robert at ID-Tasker]

Example of using NoBreak locally - just found online:

<ParaStyle:q2><CharStyle:qt>make a straight path for him to travel<cKerning:100>!<cKerning:>’<cHorizontalScale:0.500000><cNoBreak:1> <cNoBreak:><cHorizontalScale:>”<CharStyle:> 

There is a space between cNoBreak tags and "1" is a switch to turn it On.

[Robert at ID-Tasker]

Can you post JPG / PNG?

[Matthew Williams CMH]

Yep. Sorry about that. PNG attached.

[Robert at ID-Tasker]

I meant from your original / tagged file 😉 to see where XML tags are. 

[Manan Joshi]

Hi @Matthew Williams CMH,

You code worked for me on my test document. The only thing I would change in your code is to edit the grep expression to

"¦case:all_caps¦(.+?)¦/case¦"

Can you share a document where it does not work you?

-Manan

[m1b]

Hi @Manan Joshi, search on this thread for words "XML Testing" and you will find that @Matthew Williams CMH has shared a test .indd. Also read my posts if you haven't. It's a strange problem—out of my area of knowledge. I'm interested to see what you make of it.

- Mark

[Robert at ID-Tasker]

I still got no chance to check mentioned INDD file - but if there are XML tags inside the text - it should be possible to add them to the grep to ignore / treat as part of the text? 

0xFEFF

[Matthew Williams CMH]

Hi all

Mark discovered that removing the table (or any paragraph after the table) from the test XML or INDD files allows the Javascript to work. I have confirmed that without the table in the INDD file, the Javascript works. I have also determined that this holds true for new INDD files (which is to say, there appears to be no corruption or artifact in the existing INDD file that causes the Javascript to fail).

I suspect that the problem is with the invocation of the Adobe namespaces, but as nearly as I can tell, the table is following the required format when accessing those namespaces. Unfortunately, I can find no documentation of those namespaces, so I'm only guessing.

After thinking things through after a prompt from Robert, I've decided NOT to develop an XML-first workflow and will instead focus on developing scripts to process files for export to XML, which is, I suppose, the only really necessary goal—to provide my clients with an XML file and and INDD file at the end. However, I would still be glad to find out why the table in causing a problem and how to format tags in compliance with the Adobe namespaces.

[Robert at ID-Tasker]

Still can't check your file - hurt my back so need to lay down 😞 but got another idea - can you export your file into IDML and check the contents around the table if there is anything strange inside the text that is preventing JS from working?

Or... even IDMLing your file and then try JS to run again? 

Maybe there is some mess from Tagged Text - as it's no longer actively developped maybe some gremlins are messing around - that will be fixed through IDMLing? 

[琥珀 猫太郎]

It seems that you can search by removing the tags up to the last TX tag including the last LL tag.