Version : Adobe InDesign 2021(ver.16.0.1 ja_JP)
OS : macOS10.15.6

1.Steps to reproduce the issues

1. Open Find/Change Window.

2. Select "文字種変換" and click "Specify attributes to Find" and Select Style button.

3. The selected Style does not shown in "Find Format" area and we can't apply it. However, click the button, we can see selected Style we selected previouse step.

4. The Change Format in "文字種変換" also unavailable.

2.Expected result
The selected style is displayed correctly in Find Style area and is correctly apply.
Also, the replacement style is set correctly in Change Style and replaced as well like InDesign 2021.

1. Actual result
   We can't set Find Format and Change Format options in "文字種変換" in Find/Change window.
   Test file, screenshot, video or GIF capturing the issue (optional)

Japanese.
1.問題を再現する手順

 1.検索と置換ウィンドウを開きます。

 2.「文字種変換」を選択し、「検索形式」をクリックして、「検索する属性を指定」ボタンをクリックします。

 3.選択したスタイルが検索形式のエリアに表示されず、適用できません。ただし、再度「検索する属性を指定」ボタンをクリックすると、前の手順で選択したスタイルが表示されます。

 4.「置換形式」のスタイルも利用できません。

2.期待される結果
InDesign2021と同様に、選択したスタイルが「検索形式」エリアに正しく表示され、検索対象として正しく機能する。また、「置換形式」も同様に設定できて正しく置換が行える。

3.実際の結果
「検索と置換」ウィンドウの「文字種変換」で「フォーマットの検索」および「フォーマットの変更」オプションを設定することはできません。

Please refer below,
https://community.adobe.com/t5/indesignフォーラム/文字種変換で検索形式の指定ができません/m-p/11695809

Dear Support,

with the GREP position marker "^" for "Beginning of Paragraph", the GREP-search should consider the position of the beginning of a paragraph.
But this marker does not only recognize the beginning of a paragraph, but also the beginning of a new line after a forced line break (SHIFT-RETURN).

This is not correct: A forced new line is not the beginning of a paragraph.
The only correct way would be to consider the beginning of a paragraph (RETURN).

Sometimes you can use "(?=\r)\w+" to look for a word behind a Return instead of "^\w+" to find only the hits at the beginning of a paragraph. However, a combination with the search for a paragraph format can be disturbing here: with the lookbehind combined with a paragraph style only those places are found, where two consecutive paragraphs have the same paragraph style.

Please correct the effect of ^ to only beginning of paragraph (and not forced line break).

InDesign 14.0 on Windows 10 x64

I just upgraded to InDesign 14.0, and there appears to be a bug when clicking a document-installed font from the font list. The font list gives an error message to "Click 'Activate' button to activate fonts" and the text frame keeps the existing font, instead of changing to the new font.

Expected result:
The expected result would be the same behavior as InDesign 13.1, where you could click a document-installed font from the font list, and the text frame would update to the newly selected font.

Actual result:
In InDesign 14.0, clicking a document-installed font from the font list gives an error message to "Click 'Activate' button to activate fonts" and the text frame font stays the same.

Steps to reproduce:
1. Create a new document in InDesign.
2. Create a new text frame with the word "Test." Save and then close.
3. In the same location as your new document, create a "Document fonts" folder. Copy an OTF or TTF font file into this folder. In my case, I copied "Sacremento-Regular.ttf" into this folder.
4. Reopen the new InDesign document you saved in step 2.
5. Select the text in the text frame. Note the current font (most likely Minion Pro).
6. From the type list, select the document-installed font you copied into the "Document fonts" folder.
7. Note the "Click 'Activate' button to activate fonts" error message, and that the font for the text frame has remained the same.

I have reported a variation of this—back with CS6—but it seems not to have been fixed. I assume it's a bug, but if someone can enlighten me about what I might be doing wrong and how I can fix this, I'd appreciate it.

I often work on books that include Arabic and Hebrew words and phrases in the middle of English text. They only way to get the Arabic ligatures to form is to use one of the World Ready composers. When I do that, though, the kerning around some English characters often—but not always—is affected. I have tried turning on and off various settings—justification settings, kashidas, etc.—and their effect seems to be random. Sometimes the changes fix the problem until the page redraws, sometimes the errant kerning is corrected in one location but shows up in another location, sometimes nothing happens at all. I'm attaching two screen captures of a book that I have in production now with the word "economics" selected in each. In the shot with the World-Ready Paragraph Composer active, you can see the extra kerning between the "e" and the "c." In the shot with the WRPC deactivated, the word looks as it should.

Is this a bug? If not, what am I doing wrong? If it is, when might we expect a fix. Unfortunately, I have a deadline on this project now and can't see any reasonable way to fix this. Thanks for considering this problem.

Adobe InDesign (ME) 2021, 2020, CC 2019, ..., CS6
macOS and Windows

InDesign's WorldReady settings (Paragraph Direction, Kashidas, etc.) are being stripped from a document's [No Paragraph Style] style when opened on a machine with a missing 3rd-party plug-in (like Em Software's InCatalog). This appears to happen with any 3rd-party plug-in that adds a text attribute with a prefix that's lower than the WorldReady plug-in's prefix. While the following steps use the Middle Eastern app (English Arabic), where there's a UI to see the style's empty/blank WorldReady entries, we've confirmed that this problem affects all app variants (including English (Roman)).

To reproduce:
1. Install ME version of InDesign 2021 (English Arabic).
2. Install Em Software's InCatalog plug-in (http://emsoftware.com/products/emcatalog/ ) or any plug-in that adds a text attribute with a prefix ID below that of WorldReady's 0x50f00. (The SDK's BasicTextAdornment sample will work if its kBscTAPrefixNumber is changed to something like 0x43a00.)
3. Restart InDesign while holding down Shift-Control-Option/Alt (to ensure the session workspace's [Basic Paragraph] style is rebuilt to include the new plug-in's text attribute).
4. Create a new document and add a text frame containing a few paragraphs using the [Basic Paragraph] style. This text should compose as right-to-left (the ME version's default direction, as specified by WorldReady's kParagraphDirAttrBoss). Create a numbered list, since that's a great way to see the problem.
5. Save the document.
6. Quit InDesign.
7. Remove InCatalog (or whatever plug-in was installed in step 2).
8. Restart InDesign.
9. Open the document that was saved in step 5.

Alternatively:
1. Install ME version of InDesign 2021 (English Arabic).
2. Restart InDesign while holding down Shift-Control-Option/Alt (to ensure a clean session workspace)
3. Open the attached SavedWithInCat(2021ME).indd file. (Well, UserVoice won't let me upload it. Ask & I can send directly.)

Notice that the text frame in the opened document incorrectly flows left-to-right and the numbered list's numbers wrongly show on the left rather than the right. Edit the [Basic Paragraph] style and note that the WorldReady settings in the Middle East Character Formats and Indents and Spacing panels are blank/empty. (See attached before-after screenshots.) One would expect a style to survive intact even when opened on a machine with a missing 3rd-party plug-in, but instead some of its settings may be at risk of being lost.

We've used WorldReady as the victim here, but this problem affects any plug-in, Adobe or 3rd party, that adds a text attribute with a prefix that's higher than the missing plug-in's prefix (such as Em Software's InData).

Details: We've isolated what looks like a long-standing problem (bug?) with the SDK's AttributeBossList::CopyInto(), where it stops the copy when it encounters an attribute whose plug-in is missing. Instead, the copy should continue after the missing plug-in's entry order to produce a complete list of non-missing attributes. Copies produced by AttributeBossList's Duplicate(), ApplyAttributes(), and its copy-constructor are all affected.

1. Version of Adobe InDesign
   This issue appears in every InDesign versions since footnotes are supported.
   Bug reports / feature requests (from CS3 up to CS6) have been ignored in the past.




2. Steps to reproduce the issues
   given:
   a) a footnote with three text lines
   b) splitting footnotes allowed in the footnote options
   c) keep options: at start/end of Paragraph 2/2 (2 lines at start, 2 lines at end)

Play with the textframes hight so that the footnote is forced to be splitted. It will only split 2/1, not 1/2.

1. Actual result
   The footnots splits with 2 lines in the textframe within the footnote starts and ends with one single line (widow) in the next textframe.




2. Expected result
   a) best choice: hold the keep options!
   (e.g. 2 at start / 2 at end; so don't split a footnote with 3 and less lines).
   b) alternative: make an orphan (full line at the start of a footnote paragraph) instead of a widow; widows are absolutely not allowed (because they ony fill a part of a line, maybe only one word)




3. Test file, screenshot, video or GIF capturing the issue (optional)
   Screenshots appended

(Hmm ... tried to attach an INDD file and I'm told they're not allowed. Really? OK ... will try a ZIP file with the INDD inside. Nope ... ZIP won't work either. Uploading a PNG screenshot)

Column Rules fail if a Table is the first item in a Text Frame

Please see the attached sample file.

On page 1 and 2 you will find a variety of 2-column frames with column rule applied.

In each case, the column rule will fail BECAUSE the first item in the frame is a Table. But, on page 2 I've added one extra example where a leading paragraph does exist, and because of this the column rule is ok.

I suspect the problem stems from the basic idea that a Column Rule will not appear in a text frame if there is NO text in the frame. Actually ... I'm not 100% sure I agree with that operation. If the column rule would appear with our without text, then this would solve the problem. But ... that might cause other problems.

Either way ... the Table is not being recognised as a valid trigger for the column rule to be invoked.

Thanks :)

Allan

1. InDesign CS4 - CC2017




2. Generate an Excel spreadsheet that contains at least one cell with the value "-1". Save as XLSX. Import/place (cmd-d) this file as "unformatted table".




3. the cells with the value "-1" should still have this value.




4. the cells are empty. All other values seem to show up correctly.

Additional information: Working regularly on Annual Reports with 100+ tables, our choice is to import as „unformatted table“ and to do all formatting in InDesign. After changes in Excel, all we have to do is updating the linked tables via the link panel. Table contents change, formatting stays. Perfect. But we are dependent on our clients still willing to use the outdated XLS format.

Please have a look at this problem! Thank you in advance.

Best regards

Since a few weeks (we think since the InDesign 16.1 x64 update), we see a major problem in a lot of our books:
Words that already contain a hyphen (minus sign: -), and that are hyphenated automatically by InDesign, get a double hyphen!
Normally, when hyphenated words are at the end of the line, the 'hard typed' hyphen gets replaced by the automatic hyphen (with the blue ~ added above it), but now the automated hyphen is added, so we get two consecutive hyphens (--). Sometimes on the same line, sometimes one on the next (see example screenshot).

This is a serious and big problem, experienced by everyone in our team (10 people), on multiple different projects (using templates we use for years already).

It causes a major liability issue towards our customers, when the books are printed this way! Please fix this.

We are all on Windows 10 Pro and have the latest version installed (InDesign 16.1 x64)