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

[palala fog]

When using these specifications for captions and making a table of contents the result is a mass of unthread frames with their page numbers isolated and converted into anchored items:

I ask for help in order to:

Plan a: how to save this result (below) so as not to lose work and achieve a TOC from this imput?

or

Plan b: avoid a solution that consists of ungrouping the caption in each figure, which forces to execute a lot of manual operation and to lose what has been done. It seems group is the worst solution.

The problem is that using the group caption option in the caption menu creates an unusable result.  Perhaps a bug that I didn't count on.

Thanks

  

[James Gifford—NitroPress]

I'm not quite grasping what's happened here, or why, but there should never be a problem "saving" a TOC if the TOC style (schema) has been saved. The actual TOC can be re-generated at any time, and indeed, that's the whole purpose — being able to regenerate it as each change to the content is made. (I note this seems to be more a TOF — table of figures — but that shouldn't make any difference.)

What is preventing you from deleting all this unwanted mess, checking your TOC schema to make sure you have the right paragraph styles selected, and re-generating the TOC into a newly dragged or placed text frame?

It looks to me as if you have a poorly selected Paragraph Style for the captions. I also don't remember if I've ever tried to generate TOC entries from paragraphs with anchors in them, but I sure must have, and I've never seen the complications you're showing.

Start by creating a fresh TOC schema, under a defined name (don't use 'default') and make sure you have tagged the caption style correctly.

[palala fog]

James,

this post clearly stated that generating a table of contents from paragraphs that have been created under the menu Object/Captions only works properly if you do not group the image with the caption, as the menu supplies it. This positive result eliminates that the steps or styles for creating the table of contents are not correct. They are fine if the group option is not used.

Assuming that a table of contents is «poorly» generated when its output has turned into a jumble of loose parts and anchored elements does not seem adequate. It cannot be logically inferred. There is deep structural damage here as can be seen in the photos. Never seen.

Obviously tests have been tried in several ways and the result is the same. Using the "group" function in the captions menu is a disaster. Not using it gives a normal result. The problem is that we need to use this option and now we are faced with repeating what we have already done.

Thanks.

[James Gifford—NitroPress]

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.

[Barb Binder · Accepted solution]

Hi @palala fog:

What version of InDesign are you using? I'm trying to recreate this (though collecting description and not name metadata). This is from 19.0.1 and I'm enabling Group Caption with Image in the Caption Setup dialog box before generating live captions and not seeing the issue. Are you on a different version? Or am I missing a step?

~Barb

[palala fog]

Barbie, hi.

Ventura 13.6
ID 19.0.1

I feel It is a deep damage and assume it comes from using the "group" function because once you remove its use in the "captions" menu the problem begins to disappear. an the solution: remove the caption that was associated to the image. Manually placed the new caption and it was solved with an unpleasant investment of time and energy.

I suspect there was a style conflict that caused problems. Also,  sometimes during the experiments to fix the mess I got a warning that the hyperlinks didn't have a destination when generating bthe TOC. This is the second time this has happened in three months on a different file. I put the post in the Forum a few weeks ago but there was no response. It seems as an obscure topic that has no information on the web.

And in the case of this thread also generating an idml copy was problematic. It forced to re-start the machine which is a resource that works here when the files are annoying.

The generated TOC galley behaves strangely. It comes fragmented in unthreaded lines of text. It is selectable but does not make a copy and is clearly a badly damaged galley.

PS. Something that is a disgrace that happens for years on every computer and in every version is when a table of contents is deleted because ID aborts many times.

[palala fog]

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.

[James Gifford—NitroPress]

Without having an example file to dissect, none of us here can put an exact finger on the cause of the problems you're encountering. We can only look at what's presented and make our best guess, from experience and accumulated knowledge, about what might be worth checking and what fixes might be useful.

And (unless I am misreading you) the idea that if a feature is in InDesign, it must be functional, useful, the correct approach, or the only method that should be used is, sorry, nonsense. There are many features that have become outdated, were never developed to their full potential, or are leftover pieces of an Adobe initiative that has been abandoned.

Some users find the overall caption system perfect for their needs. I'd bet that far more users find it overly complicated, limited, far too dependent on embedded image data, with one-way format conversions and other quirks — and just too much trouble to use. Relatively simple captioning methods can be used in its place, and if Paragraph and Object Styles are developed to manage the details, without any real loss in productivity or workflow.

It's possibly your problems trace to an actual bug. Well, that's not too uncommon with ID. So you can work out why your documents want to pull this extraneous information into a broken list, or you could back up and devise a caption and TOF system that is fully under your control, using features and functions known to work properly. But as the Caption system hasn't been touched or updated in many years, I wouldn't wait for the Devs to fix any part of it. My suspicion, and hope, would be that it's completely replaced with a more flexible, open system in the next major ID revision.

[Robert at ID-Tasker]

You are right... But you are not first and won't be last... 

Unfortunately, like @James Gifford—NitroPress said - it is what it is - you just need to accept it and learn how to navigate this minefield...

[palala fog]

It seems a paradox that an Adobe expert suggests that we must accept ID as it is. ID is more and more. And less and less.

The deidification of this app does not blind us to the disgrace of being subjected to a precarious option. Using ID I feel like I'm back in the days of linotype, moveable print,  laboriously and heavily embroidering a fabric that eats up intelligent time.

And of course, around ID there are a lot of really wonderful and generous people who help us and give their time. That calms us down a lot. But those who ask us to keep quiet are not the best advisors and opinion leaders.

[Robert at ID-Tasker]

You are missing a point - we are not trying to say that everything is OK - it's just that there is nothing much we can do - only try to find workarounds and share them with others. 

Adobe is fixing problems - but, like everywhere - there is a gradation system. 

Captions probably are not at the top of the list. 

You can go to the uservoice page and post your comment there - but unless the problem / bug is critical - it will be at the back of the queue. 

[James Gifford—NitroPress]

You are welcome to pause your project until Adobe fixes the issue to resolve your problem.

But most experienced users, up to 'expert,' would recognize that ID has limits and outright faults, and find methods to work around those limits rather than simply complain that it doesn't do exactly what is wanted (or, sometimes, even what it promises).

I'm not sure what other answer you are seeking, expert or not. Robert T. has already acknowledged that you're right, as a user who expects features to work as designed. But the fact is the Caption feature is poorly conceived, implemented with undue complexity and "works" only in a very narrow sense... when it isn't actually faulty.

So you can wait for Adobe to fix it, or move around the problem. I suggest the company is not in any mad scramble to implement that fix because of your complaints, which add on to a long, long list of them. 🙂

And ID is nothing if not enormously flexible, with a dozen ways to achieve most objectives. A built-in feature is rarely more than one, quick, limited alternative to others. I can't think of one that is "the only way" and can't think of many that are the absolute best approach — most are just the most efficient and "good enough" method.

[palala fog]

Barb,

What is really important is that you did an experiment which was to reproduce a query. And solve my question.

Thanks for your great work on the forum.

[Robert at ID-Tasker]

---

@palala fog wrote:

The style menu is another disaster. You can only manage styles one at a time...

---

Unfortunately, you are working on a Mac, but for a PC, even the free version of my tool can help a lot:

Right now it is imited to showing basic information, but in the end, user will be able to modify ANY setting instantly - in multiple styles in multiple documents at once, synchronise only selected settings, import / export definition, etc.

[palala fog]

Robert,

Hello, yours is a good answer with information.

I was referring to a certain precariousness or limitations of the styles menu. You can only work one at a time and the two categories (character and paragraph) are separated. In serious style surgeries, when you go back to old work and start creating new styles this is a calamity. It is also cumbersome. It forces you to do a lot of manual steps, which is something that in book assembly processes is exhausting because of the sheer number of steps.

Also the TOC menu is very cumbersome and small. In this there has been zero improvement. Using it with a dozen styles is impossible. (Photo)

Captions is definitive. It allows in books with a lot of photos or figures and graphics to automatically place the captions that should have not only one but several options. As if it were just another style: to use it in different pieces where the caption goes above or below and when one wants to use another style for different situations.

One dreams that ID would contract  (if not) very experienced designers in big editorial work and that the problems that arise would be solved. Many years ago Penguin Books called in Jan Tschichold to take over the reins of editorial design and that continues to bear fruit.

An example of the above: in the assembly of books with a lot of graphics (photos, figures, tables, etc.) it would be a great help if, when placing these pieces on top of the text, the space was left free for the piece, but no. The galley is mysteriously placed behind the text, causing great discomfort and making this possibility useless. The galley is mysteriously placed at the back, causing great discomfort and making this possibility useless. See photo.

Best regards

[Robert at ID-Tasker]

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

If you've used it - then your document would look "better" - text on both sides of the spread would be aligned. Also, you would avoid problems with the charts - as you would have them more "standardised". 

In case of more options for  Captions - you would need to work on a PC - then, you could achieve anything by using my tool.

[Barb Binder]

Thank you @palala fog. That is the role of an Adobe Community Expert—we volunteer here in our spare time to help users figure out various Adobe applications. Keystroking a situation that we've never directly experienced and discussing the outcome is a great way for the user and the expert to continue their learning.

That said, I didn't run into any issue with generating a TOC from the generated, grouped, live captions so I'm still unclear what is going on for you. Can you tell me about the role of hyperlinks in your doc? Are you adding hyperlinks to the generated live captions? How are those getting into the TOC?

~Barb

[palala fog]

Barb,

very nice your reply. Thanks.

I definitely think there was a style problem. It's instinct. This is not new but it's not very common. I remember once when applying a colour to a style caused dramatic changes and damage.

When you use a lot of character styles (coloured underline, for example) to check groups of words and sometimes delete or replace used ones, there is usually a certain "corruption" (they don't let you delete or modify them and show erratic behaviour) that forces you to leave them alone and not try to delete them because of the imminent danger of total damage.

Hyperlinks appeared in a warning notice explaining the non-execution of a table of contents. The file only had half a dozen of them in footer references. And in the that menu there were almost hundreds of them in red. That had already happened with another file without explanation that I sent to the forum without success. Indigestible cables from the engineers, probably.

The handling of TOCs is very dangerous because if they are duplicated in the pasteboard to remember or save a change they always abort. This behaviour probably has to do with what happens in captions: they are pieces of text with imbrications linked to pagination or information layout and they are very fragile.

Indesign reminds us of the end of a Faulkner's roman: «Given the choice between the experience of pain and nothing, I would choose pain».

[palala fog]

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.

[Robert at ID-Tasker]

We are talking about how to drive, not the cosmetic of the vehicle. 

By @palala fog

Yes, but if you use Align To Grid - you'll get rid of all the problems you are talking about.

The text under the Graphics - will automatically start in the "right place" - after you size your Graphics accordingly.

And then, your publication will look better.

You'll also avoid different spacing problem at the bottom - last line of the text and edge of the paper.

This how your text will look like on the spread...

Or you could apply Vertical Alignment = Bottom in the TextFrames with your main text.

I'm not a book / graphics designer - but I was working with someone who was exceptional in that matter - and I've picked up few things - and one of them is to make a "grid" for text and objects - consistent margins are obvious, then Align Text To Grid, then you need to decide how / where graphic objects are placed and follow those rules.

In your example you have the same chart on both sides - I know it's just a copy, not a real spread - but it would look REALLY bad, if you would have a few mm difference in height if those were different charts...

[palala fog]

I am very sorry that you did not understand the problem. The image clearly shows two elements text and figure. Grid, leading, size type are not relevant elements here. The best thing you can do is to discuss the issue with a colleague.

Continuing:

Robert: If you’ve used it - then your document would look “better” - text on both sides of the spread would be aligned. Also, you would avoid problems with the charts - as you would have them more “standardised”.

Me: Not at all.. This is not cosmetic. The point is related to real engineering and real software. Not tips, tricks, shortcuts. We are talking about large documents with hundreds of images and hundreds of pages, and how resolve it. I  sent the same page but duplicated to make the comparison. Is not a doubled side layout. I don't understand your inference of talking about spread. You are  many things.
guessing.

And charts have NO problems. They are «standardised» simply by design. But they have to be placed with intelligent software and that's what there is not: All these steps here are manual, time-consuming and infinite.

[Robert at ID-Tasker]

You keep arguing about a "problem" that can be resolved quickly - if you do your document correctly.

If you can't understand what I'm talking about - then I'm sorry.

But maybe this will convince you:

As you can see - text is aligned - and as long as you make your graphics "sticking" to those lines (right) - or half-in-between (left) - but consistently - you won't have a problem with uneven spacing.

[James Gifford—NitroPress]

I will confess that I no longer have any idea what this thread is about. It keeps going around and around about some "serious problem" that appears to be simple misformatting of the styles and layout, allowing text to flow over an anchored image. But it's wandered over into long rants about how Adobe won't fix these problems, which is apparently having global consequences of some sort.

IMHO, the documents in question are either corrupted or have poor style settings, and an experienced pro could sort it out in an hour or so using completely standard methods, not "workarounds and fixes." But as long as the discussion keeps going in circles about how we just don't understand and are probably shielding Adobe's failings... no useful result is going to be found.