Well, for one I did not learn to write scripts for InDesign by watching tutorials, or by reading Adobe’s documentation, or from some magical webpage where everything was spelled out for me. I learned it by doing it – for a decade. As programming languages go, Javascript is pretty well documented – and quite forgiving as well. Even if you feel you have written some very bad code, well, if it works, it works. And if it doesn’t, tinker until it does. Writing highly optimized code comes last. Writing pretty code may never come for some.

> … where should I look for DOM (if it is needed) etc …

Javascript is a programming language, and with it, you can write programs. However, it is just a programming language. There is no universal interface to other programs, so everything – yes, everything – you want to do “in” another program needs interacting with its DOM. You can write all the Javascript for a webpage you want, but if you never do a document.write(“Hello World!”);, then how do you know it even did run – if you don’t interact with the HTML DOM to see the output?

> … MS Word or MS Excel etc, then who is going to help me, where will I find the milestone to get started …

How do you find anything on the web? Google. For example, I did not even know that one could write Javascript for MS Office programs (and I was going to say so) but hey! look! Google turned up this: https://msdn.microsoft.com/en-us/magazine/jj891051.aspx

But the bottom line is: there is no substitute for plain grunt level “learning”. As Kylie Minogue says, “There’s no shortcut to learning a craft; you just have to put the years in.”

Comparing numbers for size with GREP is a dark art and best avoided whenever possible. Justin is right: trying to solve your problem (barely mentioned so far; but there are scripts to adjust numbers!) with GREP leads to the adage “now you got two problems”.

Anyway, I’ll have a go at it, just for the fun of it :D

(?![012]\d{3})\d{4,}

This find series of 4 digits or more, but if there are only 4 it will ignore them if they start with “0”, “1”, or “2”. The addition of “0” in this sequence will make it ignore “0123” as well – you may consider that a bonus.

InDesign does use ‘true’ ligatures – of course only when they are provided in the font to begin with, and it also has to ‘know’ that they are there (i.e., the ligatures are properly indicated with one of the OpenType features).

Your test with Times shows that this is most likely not a proper OpenType font and so it doesn’t contain any other ligatures than “fi” and “fl”. These two are special in that they pre-date OpenType; they are ‘normal’ characters, but InDesign is smart enough to find and use them anyway.

The reason that Dwayne believes that InDesign fakes ligatures: “… two characters. InDesign just makes them look like ligatures …” is also because InDesign is way, way smarter than your Average DTP software. It scans regular text strings for combinations that can be replaced with ligatures, and when it finds any, it does not change the text but only the display. This is why you can search for a single ‘f’ and it finds this even when in a ligature, and why you can place the cursor ‘between’ two characters ‘inside’ a ligature and type a single letter which seemingly automatically ‘discards’ it.

… Back to the original question.

> For example, I am using FF Tisa Pro which has ligatures for ch/ck/ct, but they don’t appear normally.

.. which is actually a good thing :) The common ligatures “fi” and “fl”, and in some fonts combo’s such as “ff”, “ffi”, “fj”, “fk”, “ft”, “fh”, and “Th”, are designed to prevent optical clashes between the overhanging part of the “f” and the next character. Some fonts don’t need a ligature because its design makes it unnecessary; then again, they still may contain a design for the standard ligatures because a text file may contain these character codes.

The design for the ligatures you want is beyond this common use, and so they have an OpenType feature of their own: “Discretionary Ligatures”. As with all OpenType features, the character designs must be in the font and the correct OpenType feature must have been inserted as well, for InDesign to be able to use it.

This seems to work for FF Tisa Pro: see https://myfonts.us/td-M6bEf4; I ticked the box “Discretionary ligatures” in the Typographic Variant settings, and lo, it contains both ‘ct’ and ‘st’.

Are the endnote numbers marked in any way, such as superscripted? If so, with a manual override? With a Character Style? The most optimal case would actually be if they all had a character style named “endnote” – in that case, it can be scripted without fear of accidentally changing “a² + b² = c²” to “a³²⁶ + b³²⁶ = c³²⁶” (which would be a problem, mainly because there are no such values for ‘a’, ‘b’, and ‘c’!).

Shifting table contents globally ‘left’ and ‘right’ into previous and next rows, is not a usual table task. If a table column is not aligned correctly with another, you can copy-and-paste the wrong content one position to the left or right. But that won’t work with ‘row wrap’.

Fortunately, it can be scripted. Here are shiftup.jsx and shiftdown.jsx. They move the *text content* of a table one cell left or right – unless there is something in the first (or last) cell, of course!

//DESCRIPTION:Shift table cells 'up'
// A Jongware Script 21-May-2015
currTable = app.selection[0];
if (currTable.hasOwnProperty('baseline'))
	currTable= app.selection[0].parent;
while (currTable instanceof Cell || currTable instanceof Row || currTable instanceof Column)
	currTable = currTable.parent;
if (currTable instanceof Table)
{
	if (currTable.cells[0].texts[0] &&
		currTable.cells[0].texts[0].length > 0)
	{
		alert ("no room to shift up!");
	} else
	{
		for (i=1; i<currTable.cells.length; i++)
			currTable.cells[i].texts[0].move (LocationOptions.AT_BEGINNING, currTable.cells[i-1]);
	}
} else
{
	alert ("please make sure the cursor is inside a table!");
}

and

//DESCRIPTION:Shift table cells 'down'
// A Jongware Script 21-May-2015
currTable = app.selection[0];
if (currTable.hasOwnProperty('baseline'))
	currTable= app.selection[0].parent;
while (currTable instanceof Cell || currTable instanceof Row || currTable instanceof Column)
	currTable = currTable.parent;
if (currTable instanceof Table)
{
	if (currTable.cells[-1].texts[0] &&
		currTable.cells[-1].texts[0].length > 0)
	{
		alert ("no room to shift down!");
	} else
	{
		for (i=currTable.cells.length-2; i>=0; i--)
			currTable.cells[i].texts[0].move (LocationOptions.AT_BEGINNING, currTable.cells[i+1]);
	}
} else
{
	alert ("please make sure the cursor is inside a table!");
}

Lookaheads with variable length are perfectly reliable. It’s just lookbehinds that suffer from this.

1. Your styles are marked with a pink background. Almost everything is in the same style.
2. Your paragraphs all have overrides, hence the red line in the margins.
3. All of your text has overrides, hence the red line through the text.

You must have downloaded and used Marc Autret’s StyLighter: https://creativepro.com/style-highlighting.php

Run it again and uncheck the options to get rid of it. (Unrelated but: that’s a LOT of local overrides. You may want to look in to using styles properly…)

Well paint me fifty shades of red. I checked my script right after posting it, just to make sure the items I mentioned were correct. But- the weird thing is, I saw this same (wrong) construction in your original script and deleted it without thinking too much about it.

The forum software must be doing something … unexpected here!

It should look like this .. oh wait, I cannot show it :P It should be just the first set of square brackets with a single c inside. The second set with the slash inside should NOT be there.