Apply Paragraph Style while preserving paragraph and character overrides

[Manan Joshi]

Hello All,

I have a paragraph with two kinds of overrides applied over it. First one is a paragraph level override like left indent, and other a character level override like changing fonts of some characters in the paragraph. Now i want to change the paragraph style applied on this paragraph but preserve both kinds of overrides. Using applyParagraphStyle does not preserve the paragraph level override

For ex: app.selection[0].paragraphs[0].applyParagraphStyle(pStyle, false) // This removes the left indent override, but maintains the character level override

app.selection[0].paragraphs[0].applyParagraphStyle(pStyle, true) //This removes both the left indent as well as the character level override

Am i missing something, as according to documentation of applyParagraphStyle, false as the second option should preserve the local formatting.

Thanks,

-Manan

[Trevor:]

Ok so you have 2 paragraph styles 1 called quack and the other called duck.

quack has a 10mm indent to it but on your paragraph you've giving it a 20mm indent.

You want to apply duck to it which has an indent of 30mm but keep the 20m indent override.

AFAIK the only way of doing that is to detect quacks overrides first then apply duck and then apply the overrides to the newly ducked paragraph.

This is not a bug or fault in the documentation.

HTH

Trevor

[Manan Joshi]

Thanks for the reply Trevor, i also had finally arrived at the same conclusion which you confirmed.

Now my other query would be, how to detect overrides on a paragraph style. I know there is a method/property on the paragraph that can tell us if it has overrides over it.

In order to identify the overrides do we need to traverse through all the properties of the paragraph and match it with those of the paragraphstyle and the properties whose value don't match would be identified as overridden. Won't this be a time taking process, is there a faster way to achieve this.

Thanks,

-Manan

[Laubender · Accepted solution]

https://forums.adobe.com/people/Manan+Joshi  wrote

… In order to identify the overrides do we need to traverse through all the properties of the paragraph and match it with those of the paragraphstyle and the properties whose value don't match would be identified as overridden. Won't this be a time taking process, is there a faster way to achieve this.

Hi Manan,

yes this is a time consuming process and requires a lot of coding work.

Especially if it comes to enumerators and nested styles, nested GREP styles, tabLists, bullet characters, numbering restart policies or applied conditions.

You have to do a exemption lists for properties as well. Just to name some in no particular order you would not like to compare: length, contents, allPageItems, parentStory, parentTextFrames, endBaseline, endHorizontalOffset, horizontalOffset, baseline, numberingResultNumber, appliedParagraphStyle, styleOverridden etc.pp.

Regards,
Uwe

[Manan Joshi]

Thanks Uwe, i had implemented this code and did find it really eating up the time in cases i had to do it for lots of paragraphs, and yeah i did stumble upon the fact that i need to be mindful of not using some properties. But the list i had made so far was not as extensive as you gave, so you did help me save some time of investigation

Thanks for all the help Uwe and Trevor much appreciated

[Laubender]

https://forums.adobe.com/people/Manan+Joshi  wrote

… But the list i had made so far was not as extensive as you gave, so you did help me save some time of investigation

Hm…
Maybe you did not get into some special cases yet?
Just saying… Cannot tell, because I do not know your code and your sample documents.

Regards,
Uwe

[Manan Joshi]

Yeah i was just testing with a very simple document so its highly probable that i did not land up in these use cases that you pointed. But the point you mentioned regarding the properties totally makes sense and is self evident for many of the properties you enlisted.

-M

[Trevor:]

Hi Manan

If you can "afford" to you c++ SDK (which I think you are experienced in) or regular HTML extension.

Then you can try this approch

a=app.activeDocument.stories.everyItem().paragraphs.everyItem().properties.slice()

a[2].contents = ''; // etc..

// deal with the more difficult properties

data = a.toSource();

Shove data to the "other" engine

Do the same with the paragraph styles

Get the "other" (i.e. js or c++) engine to merge nested styles and map them.

Use JSON stringify etc.

Compare and contrast the required overrides.

Send back to the jsx engine the properties to apply to each paragraph.

My guess is for larger documents you should see at least a 50 times speed improvement.

Worth a shot?

Even if you wanted to keep it all in the jsx engine this method might be good.

HTH

Trevor

[Manan Joshi]

Hi Trevor,

The script is to run in InDesign server. C++ is definitely i could do but then again you can only do things that the client approves of and most of the times its difficult to convince them unless they see the pitfall themselves.

Well i will try the approach you mentioned.

Thanks

[Trevor:]

What the document means by local formatting is the character overrides and not the paragraph ones.

[Laubender]

AFAIK the only way of doing that is to detect quacks overrides first then apply duck and then apply the overrides to the newly ducked paragraph.

Hi Trevor,

I agree.

This could be tricky for all possible overrides one cannot find properties for in character styles.
Especially for GREP Styles, I think. Doable, but you have to write a lot of code. With a plain leftIndent override this should be easy.

FWIW:

Let's see into the styleOverridden property of the Text class.
That will also return true, if the only override is a typical one that we usually associate with paragraph formatting.
Like a different value for leftIndent that is not defined in the applied paragraph style.

I am inclined to define "local formatting" like that:

If styleOverride returns true for any insertion point in a paragraph, the paragraph is "local formatted".

And you are right, DOM documentation sometimes is a bit vague.

( the understatement of the century )

Regards,
Uwe