1 Reply Latest reply on Feb 23, 2015 12:09 PM by cchimi

    Table rows affecting pageReference.add and insertion points

    cchimi Level 2

      I've found a behavior I can't figure out. Hoping someone will have some idea about what to look at, if not an answer.

       

      I have a script that inserts index entries (page references) at insertion points throughout a document. I have a function that returns an insertion point, and I can verify that it is returning what I'd expect (the locations are based on a find that looks for text of a particular paragraph or character style; but regardless of how it is found the function just returns a single insertion point).

       

      The script works as expected, except in some cases the actual location of the page reference marker is offset by some number from the insertion point (I've verified as well that the index of the insertion point is correct immediately before pageReferences.add, but the value of the pageReference sourceText's insertion point does not match that starting index).

       

      After some experimentation I've found that having tables before the text to be manipulated is at least one cause of this. A table with a header and one, two, or three empty rows seems to have no effect; the page reference appears where it should. With six rows, my page references are offset by 5. With 13 I get a variety of offsets (12, 11, 10 for my short sample). More rows creates more of an offset, but not one that seems predictable to me. The offsets do seem consistent, meaning every time I run the script I get the same result. I just don't see a pattern.

       

      Is there something about table rows that could cause this? I've accounted for the placement of the text on the page just in case; I've created a 13 row table that has narrow rows and therefore takes up no more space than my 5 row table. I still get the same results. All of the table rows other than the header are empty, so it's nothing to do with the contents. The desired insertion points themselves are not within tables; they appear somewhere in the text following the table.

       

      The code that inserts the page reference is minimal:

       

            var startIndex = fndText.index
            var myPageRef = myFinalTopic.pageReferences.add(fndText, PageReferenceType.CURRENT_PAGE);
            var endIndex = myPageRef.sourceText.index;
      

       

      The startIndex and endIndex variables are just there for debugging purposes; they show the offset between the intended marker location and the actual one.

       

      (Interesting, possibly relevant fact; the order in which I insert the markers seems irrelevant. Their location in the text appears to be what matters. So, when I move backwards through the document I get offsets of 12, then 11, then 10. But when I reverse it and move through the document in order I get offsets of 10, 11, 12. The same offsets for the same text.)

        • 1. Re: Table rows affecting pageReference.add and insertion points
          cchimi Level 2

          The more I play around with this the less I expect to find an answer; it's just so weird and non-uniform. In any case, should anyone else come across it I have found a somewhat hacky workaround. I had to dig a bit in the DOM, but you can move the actual index marker character. So, I added a step like this:

           

          //In my case it seems like a difference of -1 might be ok; could vary in other situations.
          if (startIndex < endIndex || (startIndex - endIndex) > 1){
            var myParent = myPageRef.sourceText.parent;
            myParent.characters.itemByRange(endIndex, endIndex).move(LocationOptions.AFTER, myParent.insertionPoints.itemByRange(startIndex, startIndex));
            $.writeln("Fixed index entry to: " + myPageRef.sourceText.index + ". Final difference of :" + (myPageRef.sourceText.index - startIndex));
          }
          

           

          I'm still testing, but that seems to work. (Of course, it takes an already slow process and makes it slower, but at least it's accurate!)