How to save a long table of contents that the Object/Captions/Menu has created inappropriately?

Robert, quoting you:

R: I think the problem with your 1st screenshot - text examples - is that you are not using align to grid for the text?

Me: Absolutely. I ‘m talking about two things: text wrap and images. No grids. My observation (accompanied by the photo) does not point at all to design or appearance problems. We are talking about how to drive, not the cosmetic of the vehicle.  I’m describing how text wrap should beyond its simple use. And how it can be a great option for large-breath book assembly. But it is now unusable because it absurdly overlays the image with the galley. A real mess as seen in the example.

Dear James,

I am not sure that something mechanical (TOCs, captions, indexes) is idiosyncratic in itself. It is something quantifiable and solid. Nor that the use of ID menus deserves “meticulously manage” because this implies that the user is responsible for bad results. Nor do I find that anything in ID is really complicated. The problem is that ID is an obsolete program. Perhaps an explanation is its engineers and managers seem to be dedicated to spending billions of dollars (20, dear) on buying Figmas and other curious anticipations of the future despite the fact that the laws forbade it from the beginning.

When a TOC is duplicated, cut, deleted or pasted ID aborts. Simply because the engineers have not “seen” that these pieces are simply correlations of numbers and paragraphs that if duplicated (many times totally replacing a TOC eliminates manual adjustments or special insertions) must be thoroughly worked out to avoid problems. They are not neurons. They are just letters and numbers.

Your idea in this post not to use some ID menus as captions is impossible to sustain. We don’t accept when you say that “but the only solution I (and others) have found is not to use the Caption feature” what you mean. I do not belong to that select group who already know what not to use in ID. Give us your list. Everything in ID should be used, adequately or not. Captions are fundamental: they allow  automatically place a caption without using eyes or hands. The problem is that engineers and managers are far away from the users, and so on and so forth.

The GUI for making TOCs is the saddest and most absurd option. It is cumbersome and primitive. We have been putting up with it for many years, it used to be fine and now it is just a waste of time and grumbling. The style menu is another disaster. You can only manage styles one at a time...

But essentially the problem with ID is that the files get corrupted. As if it’s food you work with. No. They get corrupted because the Adobes haven’t worked out a lot of incompatibilities. And it doesn’t seem to be part of their concerns. A problem simply appears and they have designed the window that says that ID is not working... Lately hyperlinks are starting to show up as a cause of abortions when that was never happening and they were never part of the design. Surely the engineers have damaged something else to fix something else. Hyperlinks now seem to be the new ID blank holes.

And it’s better not to run the permanent complaints of scripters with ID. From Jongware to M. Autret, the deafness of the engineers to the handling of this language is permanent. To propose to use ID thoroughly is absurd under the idea that “life is like that”. No. We want everything to work and be better. We don’t want to pay for softwares that don’t work because the engineers don’t wake up at the same time as the users.

InDesign's caption feature is... idiosyncratic. It is of limited overall use except to shops that meticulously manage their image data, and it has many complicated aspects that are not of much use to, say, the average book or magazine author/designer.

I am not surprised it does not work well with other elements like TOC generation. But the only solution I (and others) have found is not to use the Caption feature at all. Create your own Caption text styles and use Object Styles to manage the images in conjunction with the following text, while trying to avoid creating grouped image/caption text box elements, which can cause other structural and cross-reference issues.

No, it's not a good situation. But there's no sign that the overall model is going to change, so our choice is to master the feature exactly as it exists, and work within its (fairly convoluted) limits... or just not use it at all.