I'm experiencing a bug where Nested Line Styles are interfering with Grep Styles.

To reproduce:
1. Create a Character Style "Small Caps" that only applies OpenType All Small Caps.
2. Create a Character Style "No Break" that only applies the No Break rule.
3. Create a Paragraph Style "Test":
    a. In Nested Styles, add Small Caps for 1 line
    b. In Grep Styles, add:
        i. Small Caps: ([\u\d&@#\$%/]{2,}(?!\l{2,}))|([\d&@#$%]+)|(I'D)
        ii. No Break: (?<=.{55}).{15}$
4. Fill with placeholder text, and add a string of capital letters (something that matched the Small Caps grep) somewhere in the middle

You'll notice that the line style and grep small caps work, but the No Break style isn't being applied. Switch the order of the grep styles (No Break first) and now it's the opposite—No Break works but not Small Caps.

Now, remove the Line Style, and suddenly both grep styles work.

Refer to the attached screen shot. I can also provide a sample .indd file with the styles prepared. I've used styles set up like this for a while without problems, so this may be related to a recent InDesign update.

InDesign CC 2019 14.0:

I have a 4 state multi-state object. Each state has a full-screen image with a text title and description which animates in (Fly-in from top) for each state upon load. Left/Right buttons control the interactivity.

However, when I add an animation to the text title/description in State-1 it causes the full-screen image to not load and the test/description text doesn't appear either. (Tested in Indesign in the EPUB Interactivity Preview panel and on iPad/iBooks)

When testing it in the EPUB Interactivity Preview panel and I go to State-2 using the buttons and then return to State-1 the image loads and the text animates as planned.

Why won't the animation show when State-1 first loads? I wanted to attach the InDesign test file to show the issue but it won't allow.

Thanks,

Eoin

When placing an Arabic weight statement (e.g. "13g") followed by a tab and a percentage (e.g. "19%"), the weight declaration ("g" or "mg") moves to the percentage when exporting to pdf. Only when setting PDFX/1a:2001 is selected the output is correct. But this setting removes all layers and flattens transparencies so it's not very useful.
A workaround is to place a space after the tab (so on the left side since this is a right to left language).
See screen shot in attachment. On top = InDesign file, bottom = pdf created from this file using PDFX/4. The top line in the Indesign file has no space after the tab, resulting in a wrong placement of the "غ" (= Arabic "g") as marked red in the screen shot.
Sample file : https://www.dropbox.com/s/15db51rlwen8ehg/SFDA-test.indd?dl=0

The Prevent Manual Positioning creates a Locked Object, but unlocking the widget doesn't remove the Prevent manual override.

When you check to "Prevent Manual Override" an anchored object receives a lock adornment. An object Style can be created from this object. If that lock is unlocked the Object style shows as override, but the "Prevent Manual Override" is still checked.

If the object style is redefined. The lock adornment is still unlocked, and the "Prevent Manual Positioning" is still checked. Reapplying the style locks the object.

There should be more consistent behaviour of "Prevent Manual Positioning" and the "Lock". Even though they are similar they are not the same. If checking "Prevent Manual Positioning" activates the Lock. Unlocking should also uncheck "Prevent Manual Positioning".

We are developping a plugin for inDesign and while testing a new feature on a Mac we noticed that sometimes InDesign was crashing. We managed to reproduce this bug in a very simple indesign script that make inDesign crash 100% of the time and I'm looking for a way to get around this inDesign bug.

The crash occurs when we programatically add an htmlItem to a pageItem then close the document too quicky, It's only on Mac, doing that on windows works perfectly. The crash error seems to be a memory usage problem on inDesign's side.

Here is the script code :

var document = app.activeDocument;

var sourcePageItem = document.allPageItems[0];

sourcePageItem.htmlItems.add(

document.activeLayer,

LocationOptions.AT_END,

sourcePageItem,

{

  geometricBounds: sourcePageItem.geometricBounds,  

  htmlContent: '<b>Hello</b>',  

}

);

document.close(SaveOptions.NO);

other observations :

-Doing a sourcePageItem.htmlItems[0].remove(); to remove the htmlItem after adding it doesn't change anything, so the problem comes from using the function htmlItems.add() and not having an htmlItem in the document.
-Delaying the close by using $.sleep(5000) before fix the crash, but we can't rely on it as the delay needed increase with the number of htmlItems added and it might be different from a computer to another due to performances.
-Saving the document or not doesn't change anything

I've added my clean document with just a rectangle frame, the script and the crash report on this url : https://we.tl/t-uFpX658s0o since we can't add an indeed file to the post

If there is no way to fix it, do you have an idea to get around this inDesign bug ?

How to repeat the issue:

1. Activate Clipboard history in windows settings (win 10)


2. Copy a random number to your clipboard (my testnumber "-2,375")


3. Create a new document and place a rectangle (or random object) on your page


4. Select the object and click (focus) in the field for the y-coordinates


5. hit "windows+V" to open your clipboard history (must be activated in the settings)


6. Click on your previous copied number.

6-Bug. The number has been pasted two times in the y-coordinates field.

Test system:
- Win 10 pro (1809)
- current Indesign CC version (how to check the actual version?)

By the way, if you try the clipboard history in a text field in inDesign, it works totally fine.

Thanks for your help.