Anchored textframe with auto-sizing/auto-adjusting "height", text aligned to baseline and anchored object settings "anchored position: custom", "anchorPoint: bottom left/center/right" causes InDesign 2020 (15.0.1) to freeze (on Mac and PC).

1. create an new document (size doesn't matter)


2. create an new textframe (dimensions doesn't matter)


3. create a second textframe (dimensions doesn't matter)


4. insert some text in second generated textframe


5. select the text and apply the option "align to baseline".


6. anchor second textframe into the first created textframe


7. set anchored object settings of the anchored textframe to: "anchored position: custom" and "anchorPoint: bottom left or bottom center or bottom right"



8. select the anchored textframe




9. choose the textframe fit option "frame to content" or use the shortcut "strg + alt + c" on PC

InDesign 2020 freezes.

or repeat steps 1. to 8. and choose auto-sizing type "height" or "height and width" or "height and width proportionally" for the anchored textframe

InDesign 2020 freezes.

see attached screenshot. I can't attach a .indd or .idml file cause this is not allowed (error: invalid file type)

In previous versions (CC 2018, CC 2019) auto-adjusting "height" works as expected

The bug has been already reported, it's been claimed to be fixed in 14.0.1, but actually still persists and never was corrected.

Typing "T" just selects the type tool very briefly, then changes back to the previous tool. Clicking inside a text frame has the same result, even if you get to select some part of the text, it just changes back tot he previous tool in most of the cases. The only way to get it work, is to select the tool in the sidebar, however even there it takes several seconds to become active.

Using InDD 15.0.1 on a Mac Pro, MacOS 10.13

Hover Scrolling lets you interact with the dropdown menus without ever having to click on them. Sounds cool, right?

Normally, this is not a problem, because you can easily see what has been changed because you've got an object selected. But when working with conditional text, the conditional text indicator visibility is a GLOBAL setting, and thus, hover scrolling over it can change your document, even with nothing selected. And if you're not on a page with conditional text. you'd never even know that your document got changed, until you send it to print!

This has been plaguing me for over four years and there is no way to turn it off.

I write a blog article about this and have been documenting it for four years: https://indesignsecrets.com/hover-scrolling-indesign-cc-feature-bug.php

I have made a video about it here: https://youtu.be/5uBI77mothA

InDesign needs to add a preference to our off this setting. It would be so easy! There are already preferences to disable the other annoying features, like Publish Online the new start workspace, and the new document dialog box. You could put it under "Preferences > General."

Adobe, please fix this!

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.

• InDesign 15.1.2 / Mac OS 10.15.6

• Create an InDesign document with Arabic content. Apply any Arabic font.

• When exporting to EPUB (Fixed Layout) we should see the Arabic text appear in the epub viewer in similar manner as it shows in InDesign document.

• The exported epub document is viewed in Apple's Books application, and Adobes Digital Editions 4.5 with similar problems in both epub viewers, where all Arabic text is either invisible or messed up and shifted from its location.

• Attached images from InDesign document, and epub file which was exported from InDesign.

• Links from InDesign forums on the same topic…
https://community.adobe.com/t5/indesign/arabic-text-no-showing-on-epub-fixed-layout/m-p/11406882?page=1

https://community.adobe.com/t5/indesign/arabic-text-not-showing-upon-export-to-epub-on-version-15-1-1/m-p/11384957?page=1

https://community.adobe.com/t5/indesign/arabic-epub-issue-from-indesign/m-p/10818486?page=1

When exporting a PDF with the Japanese version of InDesign for Mac, the Osaka font is used for the characters in the page information. If there are voiced or semi-voiced sound marks of Japanese characters in the file name, an error will be displayed and the characters will be garbled because Osaka does not support those characters.

1. Name the indd file "だじづでど.indd".


2. Export the PDF.


3. An error is displayed and the file name of the page information is garbled.

Osaka is no longer a very old font on the Mac. Don't use Osaka now.

Use a font that supports semi-voiced sound marks to prevent errors. Illustrator already uses KozGoPr6N-Regular to prevent errors.

Japanese:
PDFのページ情報にOsakaフォントを使わないでください

日本語版のMac版InDesignでPDFを書き出すと、ページ情報の文字にOsakaフォントが使われます。ファイル名に日本語の文字の濁音や半濁点があると、Osakaがそれらの文字に非対応なので、エラーが表示され、文字化けします。

1. inddのファイル名を「だじづでど.indd」にします。


2. PDFを書き出します。


3. エラーが表示され、ページ情報のファイル名が文字化けします。

MacではもはやOsakaはとても古いフォントです。今はOsakaを使わないでください。

半濁点に対応したフォントにして、エラーを防いでください。IllustratorはKozGoPr6N-Regularを使ってすでにエラーを防いでいます。

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.

After choosing »Delete all comments« from the fly-out menu of the PDF comments panel at every position, where a comment was before the removal, a <FEFF> char is left behind, which shows up as a zero-width colon (:), when special characters are turned on.

Since this is a useless char after deleting the comments, the <FEFF> should also be removed, when selecting the removal in the fly-out.

<FEFF> shows up with XML tags, notes and index markers, so we can’t simply do a TEXT search for <FEFF> to remove it.
BTW:
\x{feff} doesn’t work in GREP search, which is kind of strange ...

In CC2020 a new function for writing alternate text for links was introduced.
Using this function and generating a PDF Leeds to wrong PDF notation. The alt text in PDF is presented by alt text, which is forbidden in the PDF world, where alt text only should be used for non text elements, e.g. pictures. By presenting only the alt text the accessibility is lost – this is against the goal to hav a better output!
A correct output would lead to a content entry.

Note: Alt text for links is under discussion, as such alt text is not present for all users (it would be read out loud, but you can't read it) – this is not about equal access.

Thanks for fixing, this would be a good step for all people relying on accessible PDFs.

Best, Klaas