1 page of pasteboard suddenly extending far out

[Typothalamus]

It's been a while since this happened – a month – but now having the pasteboard on 1 page of ~400 suddenly extend out one side. I immediately stopped work and IDML'd it. It did not change. Now will delete this one page and replace/reconstruct the page, and perhaps avoid using the pasteboard for idea collection going forward. But this is bizarre and problematic.

And @Robert at ID-Tasker, could your tool help identify the potential source of this issue?

normal ID file aboveExported to IDML and resaved as ID

[Robert at ID-Tasker]

Please go ahead and post screenshots. No idea what sparks this or what precipates it - long attempting to find out. Not sure what to make of this in terms of further diagnosing the problem and how to address it.

By @Typothalamus

Thanks. 

The only way to properly diagnose the problem would be to log every change made and keep every copy of the file...

Which is rather impossible... 

[Robert at ID-Tasker]

Most likely, the problem is in the way InDesign handles Undo History and the way files are saved - by OS. 

With SSDs it's rather unnoticeable, but with HDDs - LED would blink after every change made in the document - quick save made by InDesign on the disk to preserve current state - that's why you can get most of the file after the crash. 

The way system saves files - it's not neatly organised.

With HDDs, it was "wherever head is and if there is an empty sector nearby" write would occure.

With SSDs - it's probably similar - "whichever sector has least writes". 

Then, when INDD file is open - InDesign needs to go through all this "history of changes" and build final state of the file. 

If anything anywhere at any point gets misread - or was missaved - corruption will occure.

It might be visible straight away - but most likely, will go unnoticed - and will be "noticeable" when it's too late... 

I don't think even Save As done every minute would be an answer... 

There are apps that save in similar way - incrementally - but they might use a different approach? 

[Robert at ID-Tasker]

Then, when INDD file is open - InDesign needs to go through all this "history of changes" and build final state of the file. 

It would be nice to have access to this part of the file loading - to "pick and choose", at which point to stop loading the file... 

[Robert at ID-Tasker]

Then, when INDD file is open - InDesign needs to go through all this "history of changes" and build final state of the file. 

It would be nice to have access to this part of the file loading - to "pick and choose", at which point to stop loading the file... 

Or... it could go even further - tree view like structure, with info when object is created and then how modified. 

@Dirk Becker - what do you think? 

[Peter Spier]

WOW.

I hate to say this, but at this point I would probably recover all the text and images and create a whole new project just to feel safe that the corruption is gone.

I know that would be a ton of work, but at least you now know what the last version of the layout looks like.

[Robert at ID-Tasker]

@Peter Spier

I think it's a result of @Typothalamus preparing file for me?

Exaggeration of the current corrupted state of the file... 

We were always suggesting to do IDMLing - but it doesn't work all the time... 

@Typothalamus tried to send me original file - but last part of the splitted ZIP was missing so I couldn't open it.

But, maybe the other way of fixing - would be to move ALL PAGES to a new file? 

@Typothalamus - could you please send me the whole file again - the one that still "looks" OK - or try yourself to move pages to a new document - and see if it will fix it - or at least won't result in those oversized spreads?

You would've to select all pages - in the Pages panel - then either perform drag&drop or Move option from the hamburger menu. 

[Peter Spier]

I only suggested a "clean" start because this isn't, as I recall, the first time corruption has cropped up and there have been some previous trips through .idml.

Moving pages to a new file would probably work, but on a project like this with so much time already invested I tend towards the "belt-and-suspenders" approach.

[Robert at ID-Tasker]

@Peter Spier

Yes, you're right - but maybe we could find a "quicker" way to fix files?

Kind of recreating every object from scratch - but using InDesign's mechanism - similar to IDMLing? 

I suspect - that IDMLing tries to export EVERYTHING - used / needed or not - but when you copy pages - or even a single object - only "things" used / related to this object or on those pages - are transferred... 

Snippets should work similarly... 

And assets in Libraries? 

[Robert at ID-Tasker]

Clean snapshot of the current state - without any extras / overheads... 

[Robert at ID-Tasker]

I've just tried moving pages of this corrupted file - everything got transfered over, beside guidelines:

As can bee seen in the top-right corner - Layers Pallet - all objects wen through as well...

The list changes, depends on the active spread.

It's possible to click checkbox on the right - but object is still invisible.

[Robert at ID-Tasker]

And opening in Story Editor - works:

AND can be moved - but not in the UI - only through scripting:

Also, when it is "selected" - is reported as a point:

[Robert at ID-Tasker]

Then, after moving all objects to (0,0) position:

There is still something "outside"...

[Robert at ID-Tasker]

Some leftovers:

[Robert at ID-Tasker]

And one more time - move to (0,0)  🙂

[Robert at ID-Tasker]

The tree structure isn't properly shown - because it's by objects-on-pages - not objects-in-objects tree, which can also be achieved:

There are some anchored TFs - and more info about them - info exxtracted after selecting Text:

Those, that are not intended - column TYPE - and without PAGE NAME / INDEX - those are from the overset text.

Indentation is based on the parenting tree - and for those, parenting ends on the Character - anchor point in the Text / Story - so as those Characters do not have "graphic" parents - there is no Parent TextFrame.

[Robert at ID-Tasker]

Some leftovers:

Just noticed - pretty much nothing has been moved to (0,0)...

But at least - are visible and accessible even in thee UI...

And InDesign automatically resized Pasteboard.

[Dirk Becker]

The InDesign document is an "object oriented database". Objects identified by the ID that also scripters come across for most objects. There are atomic changes via commands that can commit or rollback - you know them as undo steps. You can group commands into sequences / transactions - see doScript + undo modes. And see the recent history panel (guessing the name from my German version).

On the other hand, keeping track of the changes requires disk space.  Remember, when the original code was written in the mid 90s, really big disks had maybe one GB of space.

Watch the history panel, or the undo menu item, after close+reopen both reset. If you run a script with plenty edits on many pages, it helps to save the document every now and then, also InDesign may decide this on its own. The transaction log is discarded, some disk space is reclaimed. Some other space is lost - growing documents, save-copy-as takes care of that.

What you wish for is already starting to show for cloud based documents. There is a panel for document versions/revisions, and you can walk along some kind of history for 60 days. Steps do not yet tell you about the changes, and the preview only shows the first page. A long way to go.

[Robert at ID-Tasker]

@Dirk Becker

Yes, "object oriented database". 

But I'm not talking about the current state of the Document. 

There should be a way to analyse / monitor this Undo History saved within the document - during opening / loading? 

[Robert at ID-Tasker]

I suspect it's like: 

• Document preparation info - number of pages, size, etc. 
• Add TextFrame on the page with ID="001" - set ID="123" to this TF, set size, etc. , 
• Set contents of the TF with ID="123" to "abcd",
• ...
• ...
• ...
• (a few thousands of other operations) set new position of the TextFrame with ID="123" to (x, y) 
• (another few thousands of operations later) set new contents of the TextFrame with ID="123" to "qwertyuiop" 
• ... 
• ... 
• Whole file loaded 

So, it would be great to be able to see and access this "creation history during loading document". 

[Typothalamus]

My bandwidth for coping with anything else is strained due to personal circumstances. I frankly am at a great loss and likely cannot cope well with further complexities. Much pressure coming from multiple corners... we've all gone through such.

As a reminder, the file you analyzed is part of an old one. The newer one is not misbehaving yet, which is based on a cleaned-up version of another later one that showed one corrupted pasteboard a few days ago, among 380. I stopped then and there, IDML'd, cleaned up. But I find it impossible to work and keep things clean as I image/text problem solve on remaining iterations. 

[Robert at ID-Tasker]

Why my post is no longer marked as correct answer? 

@Typothalamus - have you unmarked it or someone else did?

[Typothalamus]

If solving for pasteboard resizing, it's absolutely correct. If solving for corruption that leads to erratic pasteboards, it's another matter, so I thought I made a mistake.

In either case, it's clearly correct for pasteboard resizing and I didn't mean to imply otherwise. 

I was under the impression it's a corruption issue, then saw that as a misidentification, and marked it as correct – just resize it. And subsequent to that, was led to see it, potentially, as corruption again. 

I've found an old 'corrupted" file version... there may be some answers in this. Preparing it and sending as a zip now.

[Robert at ID-Tasker]

Thanks for clarification. This forum sometimes behaves "strangely".

Could you please send me this corrupted file privately? 

[Robert at ID-Tasker]

On the other hand - your question was to identify "source of the issue" - which is rather impossible(*) - and I've only provided the way how to fix the problem post factum - not how to avoid it in the future...

(*) unless, there will be some clues in the properties of this object - so it would be really great to see this file. 

[Typothalamus]

Yes, I've sent a very small unzipped portion, just a few pages, with the issue. I hope this uncovers something. Thank you.