40 results found

1. [ID-4258070]Disappearing Punctuation Marks in Hebrew RTL Justified Text in Exported PDF

   Severity Level: Critical
   Impact: Severe disruption to Hebrew text layout workflow and document integrity

   Bug Description

   Punctuation marks are randomly disappearing in justified Hebrew text blocks (RTL direction), specifically at:
   - Paragraph endings
   - Forced line breaks
   - Last lines of justified paragraphs

   Technical Context

   • Text Direction: Right-to-Left (RTL)
   • Language: Hebrew
   • Text Alignment: Justified

   Affected Punctuation Marks

   • Periods (.)
   • Semicolons (;)
   • Commas (,)
   • Colons (:)

   Specific Behavior in RTL Context

   1. When Hebrew text is set to justified alignment, punctuation marks vanish:
      • At the end of paragraphs
      • Before forced line breaks
   2. Exception: Punctuation marks remain visible if the last line is explicitly right-aligned
   3. The issue appears to be specific to RTL text direction and does not occur in LTR text

   Known Workarounds and Their Limitations

   1. Legacy Composition Engine Option:

      • While switching to the legacy composition engine in preferences resolves this specific issue
      • We strongly advise against this solution due to:
        • Previously reported bugs and limitations in the legacy engine (see bug reports #ID-4245219)
        • Performance issues documented in our earlier reports
        • Compatibility concerns with newer features
      • We require a proper fix in the current composition engine rather than reverting to legacy solutions

   2. Temporary Layout Workaround:

      • Right-align the last line of affected paragraphs
      • This is not viable for production as it:
        • Affects layout consistency
        • Requires constant manual intervention
        • Disrupts automated workflows

   Technical Impact

   • Compromises Hebrew document accuracy
   • Requires constant manual checking and fixes
   • Disrupts automated workflows for Hebrew text processing
   • May lead to incorrect final output in published Hebrew materials

   Priority Level

   Immediate attention required as this bug:
   - Affects core Hebrew typography functionality
   - Creates significant quality control issues in RTL text layouts
   - Requires time-consuming manual verification
   - May result in incorrect published content

   Steps to Reproduce

   1. Set paragraph direction to RTL
   2. Create a Hebrew text block with justified alignment
   3. Type a paragraph ending with any punctuation mark
   4. Add forced line breaks within the paragraph
   5. Observe the disappearance of punctuation marks at:
      • Paragraph endings
      • Before forced line breaks

   Technical Investigation Request

   Please investigate:
   - RTL text rendering engine behavior
   - Interaction between justified alignment and RTL text direction
   - Potential conflicts between Hebrew text processing and punctuation handling
   - Implementation of punctuation handling in the current composition engine

   Request

   Immediate investigation and hotfix needed in the current composition engine. While we acknowledge the existence of a legacy engine workaround, we require a proper fix in the current engine to maintain workflow efficiency and compatibility with modern features.

   Severity Level: Critical
   Impact: Severe disruption to Hebrew text layout workflow and document integrity

   Bug Description

   Punctuation marks are randomly disappearing in justified Hebrew text blocks (RTL direction), specifically at:
   - Paragraph endings
   - Forced line breaks
   - Last lines of justified paragraphs

   Technical Context

   • Text Direction: Right-to-Left (RTL)
   • Language: Hebrew
   • Text Alignment: Justified

   Affected Punctuation Marks

   • Periods (.)
   • Semicolons (;)
   • Commas (,)
   • Colons (:)

   Specific Behavior in RTL Context

   1. When Hebrew text is set to justified alignment, punctuation marks vanish:
      • At the end of paragraphs
      • Before forced line breaks
   2. Exception: Punctuation marks remain visible if the last line is… more

   •  

   • 

   •  

   •  

   •  

   • 

   388 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   157 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  AdminSanyam Talwar (Senior Lead Software Engineer, Adobe InDesign) responded

   Hi,

   We have been able to reproduce the issue and it is currently under investigation. 

   —

   Adobe InDesign Team

2. [ID-4246352]NIKKUD (accents/diacritics) selection has become invisible

   InDesign version: v20 (both Mac & PC)

   Hebrew letters can use NIKKUD - vocalization diacritical marks (function like Vowels) under/above the letter.

   • In previous versions (-2023) it was possible to select only the NIKKUD (attached image) of the letter. (in order to specify the position of the NIKKUD using the Diacritic Positioning panel or to change color, etc.)
   • In the current version (2024-2025) the selection is on the entire letter, and there is no visual indication whether the letter or the NIKKUD is selected (attached image).

   Note: Sometimes there are two NIKKUD characters and even in such a case in the past it was possible to choose each separately (attached image)

   InDesign version: v20 (both Mac & PC)

   Hebrew letters can use NIKKUD - vocalization diacritical marks (function like Vowels) under/above the letter.

   • In previous versions (-2023) it was possible to select only the NIKKUD (attached image) of the letter. (in order to specify the position of the NIKKUD using the Diacritic Positioning panel or to change color, etc.)
   • In the current version (2024-2025) the selection is on the entire letter, and there is no visual indication whether the letter or the NIKKUD is selected (attached image).

   Note: Sometimes there are two NIKKUD characters and even in such a case in… more

   •  

   •  

   •  

   216 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   50 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  AdminSanyam Talwar (Senior Lead Software Engineer, Adobe InDesign) responded

   Hi,

   We have been able to reproduce the issue and it is currently under investigation. 

   —

   Adobe InDesign Team

3. [ID-4243320]Cursor moves differently in MENA builds.

   InDesign version: v20 (both Mac & PC)

   In right-to-left languages ​​(Hebrew & Arabic) the cursor movement went crazy:
   - Left key - goes up
   - Right key - jumps to the end of the line...
   We can't work that way

   Note: both (23\25 indd) set to 'Visual' in preferences > right-to-left > cursor movement (of course, changing the setting to 'logical' doesn’t solve it)

   • 

   184 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   46 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  AdminSanyam Talwar (Senior Lead Software Engineer, Adobe InDesign) responded

   Hi,

   We have been able to reproduce the issue and it is currently under investigation. 

   —

   Adobe InDesign Team

4. [ID-4206781]Text wrapping has changed to before 2019 use textFrame based indent

   To place a graphicItem with text wrap, it is not an object-based indent like 2020, but a text frame-based indent before 2019.

   1 Version
   16.0.1(macOS10.14/10.15.6)

   2 Steps to reproduce the issues
   1. Make TextFrame. To places graphicItem above the textFrame and set text wrap.
   2. The indent set in the textFrame does not take effect for the object for which wrap text is set like before 2019.

   3 Expected result
   Indent set in the textFrame does take effect for the object for which wrap text is set like 2020.
   Please refer below Community article.
   https://community.adobe.com/t5/indesignフォーラム/indesign2020ではできていた回り込み時のインデント設定の維持が2021ではなくなっている/m-p/11677071

   4 Actual result
   The indent set in the textFrame does not take effect for the object for which text wrap is set like before 2019.

   To place a graphicItem with text wrap, it is not an object-based indent like 2020, but a text frame-based indent before 2019.

   1 Version
   16.0.1(macOS10.14/10.15.6)

   2 Steps to reproduce the issues
   1. Make TextFrame. To places graphicItem above the textFrame and set text wrap.
   2. The indent set in the textFrame does not take effect for the object for which wrap text is set like before 2019.

   3 Expected result
   Indent set in the textFrame does take effect for the object for which wrap text is set like 2020.
   Please refer below Community article.
   https://community.adobe.com/t5/indesignフォーラム/indesign2020ではできていた回り込み時のインデント設定の維持が2021ではなくなっている/m-p/11677071

   4 Actual result
   The indent… more

   •  

   •  

   95 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   21 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  amaarora responded

   Thanks for reporting. We will review it

   -InDesign Team

5. [ID-4213629]Indesign performance issue : Slow work of Indesign when editing text with large footnotes

   I'd like to report a bug. Please follow the scenario below:

   1. In a single column with lots of text in it, make two columns for a fragment of text

   2. In text within the two-column setup, make a footnote. Add several lines of text to the footnote

   3. Turn on the "Span Footnotes Across Columns" feature so that footnote ends up in the same group with the footnotes at the bottom of the page rather than below the two-column fragment

   4. Expected behaviour: normal editing can be performed after these manipulations

   5. Observed behaviour: any text editing after turning on the "Span Footnotes Across Columns" feature becomes lethargic and near impossible. Turning this option off immediately solves the speed issues.

   Please log a bug to fix this behaviour.

   I'd like to report a bug. Please follow the scenario below:

   1. In a single column with lots of text in it, make two columns for a fragment of text

   2. In text within the two-column setup, make a footnote. Add several lines of text to the footnote

   3. Turn on the "Span Footnotes Across Columns" feature so that footnote ends up in the same group with the footnotes at the bottom of the page rather than below the two-column fragment

   4. Expected behaviour: normal editing can be performed after these manipulations

   5. Observed behaviour: any text editing after turning on the "Span Footnotes Across… more

   • 

   •  

   38 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   27 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  AdminRavi Kiran (Senior Lead Quality Engineer, Adobe InDesign) responded

   We’re reviewing this issue.

   —
   Adobe InDesign team

6. [ID-4257735]One Frame Grid Remains Unchanged When Modifying Multiple Selected Frame Grids

   InDesign CS4 (v6) and Later

   When changing the “Number of Characters per Line” or “Number of Lines” for multiple selected frame grids, one of the frame grids always fails to update. This bug, first observed in CS4 (v6), remains unresolved.

   Steps to Reproduce:
   1. Select multiple frame grids.
   2. Go to the menu and choose “Object > Frame Grid Options...”
   3. Modify the “Number of Characters per Line” or “Number of Lines” settings.

   Result: Changes are not reflected in one of the frame grids. It appears that the frame grid with the smallest object ID does not get updated.

   Expected Result: All selected frame grids should reflect the changes.

   Bug Recording
   https://mega.nz/file/k5BVTIDa#IQAzAETDuxzmmmDDfdDDVcDTb302hy0sCR4IJcnVllc

   ---

   選択した複数のフレームグリッドを設定変更すると常に1つだけ変更されない。

   InDesign CS4（v6）以降

   選択された複数のフレームグリッドの「行文字数」「行数」を変更すると、常に1つだけ変更が反映されません。このバグはCS4（v6）で発生し、現在も直っていません。

   再現手順
   1. 複数のフレームグリッドを選択
   2. メニュー「オブジェクト > フレームグリッド設定...」を選択
   3. フレームグリッド設定で「行文字数」「行数」を変更する

   結果：
   1つだけ変更が反映されない。オブジェクトIDが最も小さいフレームグリッドだけ変更されないようです。

   期待する結果：
   選択されたすべてのフレームグリッドに変更が反映される。

   InDesign CS4 (v6) and Later

   When changing the “Number of Characters per Line” or “Number of Lines” for multiple selected frame grids, one of the frame grids always fails to update. This bug, first observed in CS4 (v6), remains unresolved.

   Steps to Reproduce:
   1. Select multiple frame grids.
   2. Go to the menu and choose “Object > Frame Grid Options...”
   3. Modify the “Number of Characters per Line” or “Number of Lines” settings.

   Result: Changes are not reflected in one of the frame grids. It appears that the frame grid with the smallest object ID does not get… more

   28 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  AdminSanyam Talwar (Senior Lead Software Engineer, Adobe InDesign) responded

   Hi,

   Thank you for reporting the issue. It is currently under investigation. 

   —

   Adobe InDesign Team

7. [ID-4216162]A splitted footnote with three lines violates keep options and makes a widow instead of an orphan

   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

   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… more

   •  

   •  

   22 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  amaarora responded

   Thanks for reporting the issue. We are reviewing it

   -InDesign Team

8. GREP position marker "^" = Beginning of Paragraph (not beginning of a new line after a forced line break)

   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).

   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… more

   •  

   18 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   4 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  amaarora responded

   Thanks for reporting the issue. We will review it shortly

   -InDesign Team

9. GREP search failed to match all text in a story

   We use to be able to search all text in a story by using this (?s).+ code. It’s working fine in CS6. But in CC2019, 2020, and 2021 on both Mac and Windows it will fail to select all text in the story if there is more than ~ 50000 character. Only the first ~ 50000 will be selected.

   This might be related to an old bug that was introduced in 14.0.2 that was fixed in 14.0.3.

   Steps to Reproduce:
   1. Create a document with one story containing more than 50000 characters
   2. Do a GREP Find using (?s).+

   A similar issues when trying to use \X+ to select all text in a story. Only some portions of the text over multiple of ~ 50000 text will be selected.

   We use to be able to search all text in a story by using this (?s).+ code. It’s working fine in CS6. But in CC2019, 2020, and 2021 on both Mac and Windows it will fail to select all text in the story if there is more than ~ 50000 character. Only the first ~ 50000 will be selected.

   This might be related to an old bug that was introduced in 14.0.2 that was fixed in 14.0.3.

   Steps to Reproduce:
   1. Create a document with one story containing more than 50000 characters
   2. Do a GREP Find using (?s).+

   A… more

   17 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Under Review  ·  amaarora responded

   Thanks for reporting. We will review the issue

   -InDesign Team

10. PDF/X-1a運用において、危険度が高い「画像の配置方法」を発見しましたので報告させていただきます。

    Indesign （15.1.3）（16.4）（17.3）などで以下の現象を確認できます。
    表を作成し、「セルをグラフィックセルに変換」という機能を使用せずに、空のままのセル内に画像を配置します。
    配置方法は、何も選択していない状態で「ファイル」、「配置」、画像を選択して「開く」、配置先のセルをクリックといったものです。
    この配置方法でドキュメントを作成し、「プリント」より出力して確認したところ何の問題もありません。
    印刷会社へ渡すためのPDF/X-1aを「書き出し」より出力します。
    期待する結果としては、「プリント」からの出力結果と同等のPDFが作成されることです。
    実結果は、Illustratorのドロップシャドウが黒ベタに、同ぼかし効果が無効に、Photoshopのレイヤマスクが黒ベタになったPDFが作成されてしまいます。
    以上です。

    •  

    •  

    16 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  AdminSanyam Talwar (Senior Lead Software Engineer, Adobe InDesign) responded

    Hi,
    We have been able to reproduce the issue and it is currently under investigation.

    —

    Adobe InDesign Team

11. WorldReady settings go missing in [Basic Paragraph] style

    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.

    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)).

    … more

    •  

    •  

    •  

    •  

    15 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  AdminRavi Kiran (Senior Lead Quality Engineer, Adobe InDesign) responded

    Thanks for reporting this issue.
    We’ll review this shortly.

    —
    Adobe InDesign team

12. Grep expressions with ~F in a character class fail in endnotes

    The inclusion of ~F in a character class invalidates grep expressions in endnotes.

    InDesign version: 14.0.2.324 (with the GREP fix installed)

    Steps to reproduce:

    1. Open the attached document. It contains a single page with text and an endnote.
    2. In the GREP tab of the Find/What window, enter the following GREP expression:

    \d[^.,;~F]+

    And target the document. The expression matches from a digit up to the next period, comma, semicolon, or footnote marker.

    Expected result: The expression should match some text in the main text and in the endnote.
    Actual Result: The expression does not match anything in the endnote.

    To show that it's ~F that's the problem, use this expression:

    \d[^.,;]+

    It matches in the main text and in the footnote, as expected.

    The inclusion of ~F in a character class invalidates grep expressions in endnotes.

    InDesign version: 14.0.2.324 (with the GREP fix installed)

    Steps to reproduce:

    1. Open the attached document. It contains a single page with text and an endnote.
    2. In the GREP tab of the Find/What window, enter the following GREP expression:

    \d[^.,;~F]+

    And target the document. The expression matches from a digit up to the next period, comma, semicolon, or footnote marker.

    Expected result: The expression should match some text in the main text and in the endnote.
    Actual Result: The expression does not match anything in the endnote.

    To… more

    14 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    6 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  amaarora responded

    Hi,
    Thanks for reporting the issue
    We are looking into it

    -InDesign Team

13. [ID-4199810]Cross reference takes more space than its text

    A cross reference sometimes takes up more space than its actual text.

    In the attached shows a frame with text with the right side of the text frame visible and the word "with" (above) extending well beyond the 2nd to last line in the frame. The "112" in the picture is a cross reference. When that cross reference is removed and "regular" text is typed in the 112 fits on the line.

    Question first posted and confirmed by another here: https://forums.adobe.com/message/10908454#10908454.

    This happens in CS6 and in CC2019, 14.0.1 x64.

    •  

    13 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    4 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  AdminSanyam Talwar (Senior Lead Software Engineer, Adobe InDesign) responded

    Hi,

    Thank you for reporting the issue. We have been able to reproduce the issue and it is currently under investigation. 

    —

    Adobe InDesign Team

14. Bad optical kerning for superscript "4"

    When a superscript "4" follows a closing smart quotation mark, optical kerning is set to -60 or -70 depending on font. This is too close (basically a crash).

    This is annoying for books with lots of endnotes, where superscript numbers usually follow quotation marks.

    12 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  amaarora responded

    Thanks for reporting the issue
    We are reviewing it

    -InDesign Team

15. BUG (since CS6!): Nonbreaking Space (^S) Issue with World-Ready-Composer

    Issue:
    When using the ›World-Ready Composer‹, the character ›Nonbreaking Space‹ (^S) behaves exactly like the character ›Nonbreaking Space (Fixed Width)‹ (^s); i.e.: in justified paragraphs, its width does not adjust (like regular spaces do), but it is fixed and unchanging.
    This only occurs with the ›Adobe World-Ready Composer‹ (both ›Paragraph‹ and ›Single-line‹) and not with the regular ›Adobe Composer‹ (neither ›Paragraph‹ nor ›Single-line‹).
    It is not related to the font used, it has been tested with many different fonts.

    1. Versions with this bug, tested and confirmed by myself or colleagues:
       InDesign (Standard Version) CS6, CC2015.0
       InDesign (Middle Eastern Version) CC2020 (15.1.2), CC2021 (16.0)
       I suppose it occurs in all versions since CS6 (when the ›World-Ready Composer‹ was first introduced, afaik)!

    2. Steps to reproduce this issue
       Enter a few lines of text and insert the character ›Nonbreaking Space‹ somewhere. Choose any of the ›Justify‹ paragraph styles and select the ›World-Ready Composer‹. Switch to the regular ›Adobe Composer‹ with the same setup and compare the result.

    3. Expected Result:
       The ›Nonbreaking Space‹ should adjust its width just like any other of the regular spaces.

    4. Actual Result:
       The ›Nonbreaking Space‹ does not adjust its width.

    5. Example as Screenshot attached.
       (Menu is in German: ›Globaler Adobe-Absatzsetzer‹ = ›Adobe World-Ready Composer‹; ›Adobe-Absatzsetzer‹ = ›Adobe Composer‹)

    As far as I know, this issue has been reported only once before (https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/39403822-non-breaking-space-is-smaller-than-regular-space-w). But in this report, it is stated incorrectly that the Nonbreaking Space would be smaller than a regular space. It can, in fact, be larger as well (e.g. in a tight line with regular spaces smaller than their 100% optimum). The real nature of the issue is that it does not vary its size.

    PLEASE FIX ASAP!
    Thanks

    Issue:
    When using the ›World-Ready Composer‹, the character ›Nonbreaking Space‹ (^S) behaves exactly like the character ›Nonbreaking Space (Fixed Width)‹ (^s); i.e.: in justified paragraphs, its width does not adjust (like regular spaces do), but it is fixed and unchanging.
    This only occurs with the ›Adobe World-Ready Composer‹ (both ›Paragraph‹ and ›Single-line‹) and not with the regular ›Adobe Composer‹ (neither ›Paragraph‹ nor ›Single-line‹).
    It is not related to the font used, it has been tested with many different fonts.

    1. Versions with this bug, tested and confirmed by myself or colleagues:
       InDesign (Standard Version) CS6, CC2015.0
       InDesign (Middle Eastern Version) CC2020… more

    •  

    •  

    11 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  amaarora responded

    Thanks for reporting. We will review the issue

    -InDesign Team

16. Invisible character

    Apply all Auto Edits inserts an invisible character before which then interferes with Find and Replace. When pasted into a GREP search, it looks like ~I, but can't be found. It can be manually removed, but this is not helpful, as I need to be able to perform a comprehensive Find/Replace.

    •  

    •  

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    5 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  amaarora responded

    Thanks for reporting.
    We will review the issue

    -InDesign Team

17. arabic

    Cursor Direction when typing Arabic or other RTL languages. in Middle Eastern version ONLY.

    1. All Middle Eastern versions (English يدعم العربية)

    2. Type Arabic text. Place the cursor within text. Hold "Shift" key and click on right arrow key on the keyboard to select/highlight text. Cursor moves left and select next character on the left while clicking on right arrow.

    3. To select a character to the left of the cursor, we should hold (Shift+left arrow) To select a character to the right of the cursor, we should hold (Shift+right arrow)

    4. What actually is happening now and for over 20 years when we had Adobe PageMaker ME and Adobe Illustrator ME is the opposite cursor behavior to the what we're trying to select. We hold (Shift+right arrow) cursor will move and select text to the left, we hold (Shift+left arrow) cursor will move and select text to the right.

    5. see animated GIF on InDesign forums here… https://forums.adobe.com/message/10174226#10174226

    Cursor Direction when typing Arabic or other RTL languages. in Middle Eastern version ONLY.

    1. All Middle Eastern versions (English يدعم العربية)

    2. Type Arabic text. Place the cursor within text. Hold "Shift" key and click on right arrow key on the keyboard to select/highlight text. Cursor moves left and select next character on the left while clicking on right arrow.

    3. To select a character to the left of the cursor, we should hold (Shift+left arrow) To select a character to the right of the cursor, we should hold (Shift+right arrow)

    4. What actually is happening now and for over 20 years when… more

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    5 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  Abhinav Kaushik responded

    Issue is currently under review.

    -InDesign Team

18. GREP Beginning of STORY not Working in InDesign 2020 15.0.3

    GREP (Beginning of STORY) not Working in InDesign 2020 15.0.3

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  amaarora responded

    Thanks for reporting. We are reviewing the issue

    -InDesign Team

19. Underline with variable font

    When the underline of a variable font is activated, the underline takes the whole height of the page. (Indesign 15.1.2)

    •  

    7 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    5 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  AdminRavi Kiran (Senior Lead Quality Engineer, Adobe InDesign) responded

    The issue has been fixed in the latest release of InDesign – InDesign 2021.
    Please update to this new version of InDesign to get the fix.

    —
    Adobe InDesign team

20. Footnote marker is replaced with an unknown character if preceded by a character with a specific Unicode pattern

    Footnote marker is replaced with an unknown character if preceded by a character with a specific Unicode pattern. Unicode pattern is U+##1a. Here are some of those characters:

    U+011a
    U+021a
    U+031a
    U+041a
    U+051a
    U+061a
    U+071a
    U+081a

    You could try the attached test file for placement in to an InDesign document. Unicode of the character following the footnote marker is : U+011a

    This happen when file format of the file is either RTF or DOC. Its not a issue with DOCX.

    • 

    7 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Text/Story/Table  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  amaarora responded

    Thanks for reporting the issue
    We are reviewing the bug