m1b
My feedback
16 results found
-
153 votesAvailable in Prerelease Builds ·
AdminRavi Kiran
(Senior Lead Quality Engineer, Adobe InDesign)
responded
We've just posted the latest InDesign PreRelease Build (20.1.0.70) in which we have done some performance improvements. We've also got this build validated by a couple of our Pro users and we believe that the Performance issue is fixed in this build.
We would like you to verify this new PreRelease build (available from the Adobe Creative Cloud Desktop App) and let us know if the performance issues that you were experiencing have got resolved with this build.
If you are not part of InDesign's Prerelease program and would like to join and try out the latest Prerelease build, do the following:
* Go to https://www.adobeprerelease.com/
* Sign in with your Adobe ID (the Email ID associated with your Adobe account)
* Select ‘Available Programs’
* Find ‘InDesign Prerelease’ and click ‘Join’
* Once you’ve joined, go to the Creative Cloud Desktop Application on your machine, click on 'Apps' in…
m1b
supported this idea
·
-
4 votes
An error occurred while saving the comment m1b
supported this idea
·
-
27 votesm1b
supported this idea
·
-
4 votes
An error occurred while saving the comment m1b
commented
This seems like a good idea to me. I guess it could be similar to the Object Style "Size and Position" sizing feature, off by default, but available if you want it.
m1b
supported this idea
·
-
3 votesm1b
supported this idea
·
An error occurred while saving the comment m1b
commented
I found the same issue just now. The problem occurs in the normal Find Text and Find Grep UI also.
I think it is because the UI has no way to distinguish between changeTo === "" and changeTo === undefined.
So my guess is Adobe decided to just disable changeTo in cases where you are changing other properties, eg. Paragraph Style. It's a shame that it is also disabled in the scripting API, where we can explicitly set changeTo to undefined if we want it ignored.
I would like this fixed too. The UI should have an "Ignore" option for changeTo similar to the way styles' properties can sometimes be set to "ignore".
Both the attached screenshots, showing a search for a number with a tab should remove the number and apply the new paragraph style, but both fail because the changeTo is ignored.
-
6 votes
An error occurred while saving the comment m1b
commented
We had a [discussion about this on the forum](https://community.adobe.com/t5/indesign-discussions/grep-for-endnote-reference-chains/m-p/14821829) which adds a few examples of the problem.
m1b
supported this idea
·
-
930 votesm1b
supported this idea
·
-
21 votesm1b
supported this idea
·
-
32 votesm1b
supported this idea
·
-
33 votesm1b
supported this idea
·
-
14 votesm1b
supported this idea
·
-
32 votesm1b
supported this idea
·
-
10 votesm1b
shared this idea
·
-
3 votes
An error occurred while saving the comment m1b
commented
By the way, I first [asked this question on the forum](https://community.adobe.com/t5/indesign-discussions/scripting-how-can-i-position-a-page-item-in-quot-layoutwindow-quot-coordinates/m-p/14473987).
m1b
shared this idea
·
-
57 votesm1b
supported this idea
·
-
11 votesm1b
supported this idea
·
An error occurred while saving the comment m1b
commented
We had [a discussion related to this topic](https://community.adobe.com/t5/indesign-discussions/indesign-losing-style-settings-when-pasting-text-to-new-document-text-with-unidentified-overrides/m-p/14333610).
I suspect the best solution might be for Indesign to ensure the [No paragraph style] is a constant across all instances of Indesign on all systems, and that [Basic Paragraph Style] should be the “default” style if users want such a thing. That way serious uses can safely base their styles on [No paragraph style] with causing the problem mentioned in the discussion I link to.
In other words I think the root of this problem may be that Editing the font/style *with no document open* currently seems to edit [No paragraph style], but it should edit [Basic Paragraph Style]. I’m not 100% sure I’ve understood the under-the-hood situation, but that is my guess.
I can confirm that this bug still exists. I'm running MacOS 15.2 ID 20.0.1.
My test code:
```
//@targetengine "mySession"
var myEventListener = app.eventListeners.item("mAfSave");
if (myEventListener.isValid)
myEventListener.remove();
myEventListener = app.addEventListener("afterSave", testQRCodeCrash);
// myEventListener = app.addEventListener("afterOpen", testQRCodeCrash);
myEventListener.name = "mAfSave";
function testQRCodeCrash() {
alert('Test started');
if (!app.documents.length) return;
app.scriptPreferences.measurementUnit = MeasurementUnits.POINTS;
// any of these cause Indesign to crash:
app.activeDocument.rectangles.add({ geometricBounds: [0, 0, 40, 40] }).createPlainTextQRCode('test');
// app.activeDocument.rectangles.add({ geometricBounds: [0, 0, 100, 100] }).createTextMsgQRCode('1234567890', 'test');
// app.activeDocument.rectangles.add({ geometricBounds: [0, 0, 100, 100] }).createEmailQRCode('foo@bar.com', 'test', 'test');
// app.activeDocument.rectangles.add({ geometricBounds: [0, 0, 100, 100] }).createHyperlinkQRCode('https://foo-bar.com/test');
alert('Test completed');
};
```
See this [discussion on the forum](https://community.adobe.com/t5/indesign-discussions/function-createplaintextqrcode-crashes-adobe-indesign-without-any-reason-provided/m-p/15036478#M601870), too.
- Mark