Reset an array at the end of the frill processing


I have a question with the array resetting after the end of the frill processing.

Originally, I planned to use an array to store texts on each page for indexing. The result is perfect when composing only one page. Unfortunately, when composing more than a page (compose range(+)), the array on each page has changed. I wonder if this is caused by the variables from the next page moved to the previous page for pagination checking.

I have undef the array at the end of the frill processing but the issue still exists. Can anyone point me in the right direction?



  • Jonathan,

    Good point.

    But that should not be a problem, at least not with the code extract that Terrence gave us.
    It is OK if the array contains too many entries.

    An example will make this clear:
    Lets say that on the finished page 1 there are 3 index entries.
    Compose of the main text will add these 3 entries as the first 3 on the array.
    If compose needs to compose a few extra lines of page 2 and these extra lines contain further index entries, these extra entries will be pushed at the end of the index array.

    Now frills processing kicks in and we start looping through the lines of page 1. Like this we will only find 3 flagged lines that contain an index entry (see the code that Terrence provided).
    Only when a find a flagged line we shift an entry from the index array.
    Like that we will only read the first 3 entries on the index array as we shift the array only 3 times.
    The extra (page 2) entries will be on the array but they will never get used.
    Then at the end of the loop the array gets reset and is ready for the next page.

    Of course if Terrence looks at the content of the index array at the start of the frills processing, he will see the extra page 2 entries.
    But these should never get used.
    Not according to the code snippet Terrence gave us.

    Maybe it is time that we see the complete code Terrence is actually using...

    PS: I changed my test code example to stick closer to the original code from Terrence. Like this it no longer reads the complete content of the array but only the entries that really appear on the page.

  • Thanks Bart & Jonathan for the clear explanation.

    This is what exactly I want to ask. However, if the paragraph contains <index> tag in which "Index 2" is just located at the beginning of the line, like:

    %<index>Index 1</index>This summary aims to give you an overview of the information contained in this
    <index>Index 2</index>prospectus. Since it is a summary, it does not contain all the information that may be important to you and is qualified in its entirety by and should be read in conjunction with, the full prospectus.

    I am wondering if this may also happen to the line justification. Would "Index 2" be pushed twice into the array?


  • Terrence,

    Not sure. 
    I think the danger is bigger when the <index> tag is glued against the previous word.
    A thing which you can prevent by using the '!' preprocess operator.
    (not sure if that can still be combined with a /Pb macro in 'i' mode).
    I guess Jonathan is in a better position to give you a correct answer.

    I also wonder what you will do when 2 index terms fall on the same line.
    As you get only 1 flag but you need to output 2 index terms.

    Let me guess:
    Initially you simply tried by pushing the index term onto the px;;0 text register.
    But then you ran into the problem of what happens when there are 2 index terms on the same line as there is only 1 instance of the px;;0 register per line.

    Hence you decided to go the perl array route...

    If you really want to solve this multiple occurrence on the same line, then you better switch to the following way of working:

    We are going to use a number register to set a unique index number for each index term.
    So you first get hold of the current value of the (lets say) number register 10, increment it and store the content into the array at that index number.
    Something along the following lines:
    sub capture {
      local $/;
      my $term = <STDIN>;
      my $X = XPPcompo->new();
      my $number = $X->get_reg('#10');
      $index[$number] = $term;

    Then during the frills processing loop, when you encounter a flagged line, you read out the current instance of the same main number register using: 
      my $number = $X->get_main_numreg(10, 't');
    This will give you the array index of the last term for the current line.
    (the current instance is the value of the number register at the end of the line)
    If you keep track of the previous value that you read, you know how many and which terms you need to read from the array.

    Oh and before you start the frills processing loop, you read the first previous instance of the same number register, so that you have an initial value to start with.

    Well that is what I would do.
    There are probably other ways to solve the same problem...

  • Bart,

    It's awesome, but may I know when and how to reset the number register 10?



  • Terrence,

    I forgot to tell you that you no longer reset the perl array at the end of the frills processing loop.
    Like this there is no need to reset the number register 10.

    The perl array will just hold all of the index terms that are present in the division.
    And the number register will just keep on incrementing with each <index> tag found in the division.
    But with every compose (one page, page range, whole div,..) the number register gets set to the correct starting value.
    That is the real beauty of using number registers.