Stacking Order of pageItems in CS5

I use the findings of this thread to get the z-index for an HTML Export. This works well with less than ~200 PageItems per Page. With more PageItems InDesign becomes unresponsive and I need to kill the process manually. Tested with Windows 7 and CS 6/CC 2015.

The everyItem() function slow with > 150 PageItems and unusable with > 600 PageItems.

I don't see a solution, but want to add this bit of information to the thread.

For testing I used the following script:

var items = 200;
var dok = app.documents.add(); 
var page = dok.pages[0];

$.writeln("start " + Date());
for (var i = 0; i < items; i++) {
    page.textFrames.add();
}


$.writeln("analyse complete " + Date());

var zOrderById = {}; 
var itemZO = page.pageItems.everyItem().index,  
itemIds = page.pageItems.everyItem().id,  
t = page.pageItems.length;  

while( t-- ) {
    zOrderById[itemIds] = itemZO;  
} 

$.writeln("end " + Date());

Hi, I'm new to this thread but used information from it recently to improve the behavior of some code that needs to process pageitems in back-to-front order.

The changes I made -- using the 'index' property -- are like this, assuming oPage is a Page object:

   var pageItemArray = oPage.pageItems.everyItem().getElements();     // get the collection's pageitems in an array

   var indexes = oPage.pageItems.everyItem().index;          // get the index values of each item too

   for( var iPageItem=pageItemArray.length-1; iPageItem > -1; iPageItem-- ) {

      var oPageItem = pageItemArray[ indexes[iPageItem] ];     // use index[iPageItem] instead of iPageItem to find the next pageitem

      ...

This seemed to work, but I'm processing an InDesign file today with a three-page spread -- a back cover, a spine, and a front cover of a book.  The back cover has 2 pageitems and the front has 5 items (one of which overlaps the spine page; the spine page itself has no items).

When my loop has 'oPage' looking at the back cover, the 'indexes' array is [5,3], and pageItemArray is [  [object Rectangle],[object Rectangle] ]

So now I'm confused.  The documentation says a pageitem's 'index' property is "The index of the PageItem within its containing object." -- but oPage only has two objects.  The code blows up if I run it with this set of data, because  pageItemArray[ indexes[0] ] translates to pageItemArray[5].

I wondered whether maybe the contents of the 'indexes' array is spread-relative, since 5 and 3 would work as indexes into oPage.parent.pageItems.everyItem().getElements().  Yet when my page loop comes around to the 'front' page,the 'indexes' array now contains [5,3,2,1,0].  I did not expect to see duplicates here, if these index values are spread-relative.  So that theory seems like it must be bogus.

Harbs or somebody, can you explain what I'm doing wrong here?  When I'm getting the 'indexes' array from oPage.pageItems.everyItem().index, shouldn't (according to the documentation) the values be the index of each of the page's items within that page?  I need code that will let me list the pageitems for each page of a spread, in bottom-to-top z-order for each page.  Do I need to just forget about using this approach altogether, and use each item's parentPage property to find which page it's on, and pre-process a spread's items into separate page-specific lists, then go through each list I've created?

Thanks for any help.

- Rich

Check the index of the pageItems.

The index is the placement in the z order and does not necessarily match the position in the collection...

Harbs