prd789
My feedback
44 results found
-
20 votesprd789
supported this idea
·
-
76 votes
Hi,
Thank you for reporting the issue. We are currently investigating the issue and updated the status in the Uservioce thread. However, the issue is still not reproducible in-house and we need additional information
- Screenshot of Memory usage while the issue is observed
- Is the "Contextual Task bar" shown? If yes, Disable it from "Window->Contextual Task bar"
—
Adobe InDesign Team
An error occurred while saving the comment prd789
supported this idea
·
-
2 votesprd789
supported this idea
·
An error occurred while saving the comment prd789
commented
Are you using a World-Ready composer? If so, this is related to:
This is replicable whenever there is a text variable (footnote number, page marker, running heads) + small caps + World-Ready composer.
-
7 votesprd789
supported this idea
·
-
4 votesprd789
supported this idea
·
An error occurred while saving the comment prd789
commented
Which composer are you using? If it's a World-Ready composer, than I think it's related to this issue: https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/48169982-bug-small-caps-not-applied-correctly-to-variable
I can repeat your file behavior if I'm using a World-Ready composer, but it appears correctly if I switch to a non-World-Ready composer.
-
10 votes
An error occurred while saving the comment prd789
commented
I've encountered this as well. When I open an older file that uses World-Ready Composer in 19.2 and 19.3, do a force recompose, the page markers change with all caps applied. There's no way to fix it unless you change the composer.
prd789
supported this idea
·
-
32 votes
Hi,
We are unable to reproduce the issue in-house.In case you have some consistent steps to reproduce the issue from scratch, please feel free to send a mail at amaarora@adobe.com or start a new thread on this portal
Thanks
prd789
supported this idea
·
-
5 votesprd789
supported this idea
·
-
4 votes
Hi,
The issue is currently under investigation.
—
Adobe InDesign Team
prd789
supported this idea
·
-
25 votes
This issue is fixed in InDesign 2024 19.2 Release.
--
Adobe InDesign team
prd789
supported this idea
·
-
21 votes
To identify the cause of this issue, we had started our investigation with the aim to resolve it. However, we are unable to reproduce the issue inhouse and would need more information
• Are you using any Plug-in or non-supported/non unicode/non-OpenType fonts?
• Video recording of the crash?
Please share the information with us at sharewithID@adobe.com
—
Adobe InDesign Team
prd789
supported this idea
·
-
55 votesprd789
supported this idea
·
-
8 votesprd789
shared this idea
·
-
8 votesprd789
supported this idea
·
-
11 votes
This issue was fixed in one of the recent updates (18.2) of ID2023 release.
--
Adobe InDesign team
prd789
supported this idea
·
An error occurred while saving the comment prd789
commented
I can repeat this behavior and it also results in odd indenting with the paragraph and the subsequent paragraphs with just a regular left indent on a paragraph with dropcaps.
Both examples had the exact same settings. Flush left drop cap paragraph followed by a paragraph with a first line indent.
I then added a .25" left indent to the dropcap paragraphs:
The first example shows what happens when the setting is checked on: The dropcap paragraph is indented to .5" and the non-dropcap paragraph first line indent is ignored.
The next example shows what happens with the setting is checked off: The dropcap paragraph is indented to the expected .25" and the non-dropcap paragraph first line indent is maintained.
Note that in the file with the screenshot, if I trigger a recompose with Honor Indents off, the top/on example resets to match the bottom/off example.
-
10 votesprd789
supported this idea
·
-
918 votesprd789
supported this idea
·
-
7 votes
An error occurred while saving the comment prd789
commented
We've run across this problem as well in non-ME InDesign. It does seem related to font, but I'm wondering if it's not related to the fact that OTF fonts uses the width of the glyph 00A0 for non breaking space, whereas Type 1 fonts use the width of a regular space. If the font has a differing space for 00A0, then a non breaking space will not work as expected and the font is at fault. However, it seems another layer of interaction happens when World Ready composer is used. As noted in the bug, the non breaking space will behave in Paragraph Composer, but incorrect in World Ready. This should be fixed.
prd789
supported this idea
·
-
467 votesprd789
supported this idea
·
-
19 votesprd789
shared this idea
·
Multiple members of my team have experienced this issue. One resolution that seems to have worked so far that points to an issue with CC2024 preferences being loaded into CC2025. This is a workflow we have used for years.
Our process:
--Installed 20.0 with our custom 19.3 preference file (~/Library/Preferences/Adobe InDesign/Version 20.0/en_US/InDesign Defaults)
--20.0 was very laggy
--Trashed preferences
--Rebuilt custom preferences in 20.0 (matched settings that were in 19.3 version, but just re-selected them in 20.0). This stopped the lagging on that computer.
--Loaded rebuilt preference file (InDesign Defaults) on another user's computer and this also stopped the lagging.
Has there been a changes with how preferences encoded that causes corruption issues if you bring older InDesign Defaults preference files to 20.0?