Challenge...

[Jim Ault]

True, my quick example outline does leave spanning the divider number y  to
fail...   so the last line retention is necessary.

Additonally, the colors may be specified in the top portion of the PDF file
so a test for 

if vColors is not empty -- we have found the location of the color specs
no need to look further... might be of value.

Jim Ault
Las Vegas

On 6/20/06 2:08 PM, "Alex Tweedly" <alex at tweedly.net> wrote:

> 
> 
> Jim Ault wrote:
> 
>> There are other strategies for reading a file into memory using
>> 
>> open file fn
>> put 1 into x
>> put 50000000 into y
>> repeat forever 
>> read from file fn from x for y characters
>> if it is empty then exit repeat --no more chars to process
>>  
>> 
>>>         filter it with "*/Separation*"
>>>         replace "#20" with space in it
>>>    
>>> 
>> put cr & it after vColors
>> read from file from x for y characters
>>  
>> 
>>>         filter it with "*/DeviceN*"
>>>         replace "#20" with space in it
>>>         replace "]" with "" in it
>>>    
>>> 
>> put cr & it after vColors
>> add y to x
>> end repeat
>> close file fn
>> filter vColors without empty
>> 
>>  
>> 
> In my role as curmudgeonly code debugger, I should point out that this
> can fail when the interesting string spans a "block" boundary - though
> since the blocks are 50Mb in size, this is perhaps unlikely. You can
> avoid that risk by doing something like
> 
> put empty into lRemainder
> repeat
>      ...   
>      put lRemainder into lBuffer
>      read from file from x for y characters
>      put it after lBuffer
>      put the last line of lBuffer into lRemainder
>      ....   (using lBuffer to do the test)
> end repeat
> 
> This has the disadvantage of one extra copy of the data; the technique
> of putting lRemainder together with the first line of each block, and
> then testing that combined line in addition to the rest of the block is
> left as an exercise for the reader.
>