You cannot define a floating trap to look at a column rang (between 63 and 65 for example).
The floating traps are trap characters that floats horizontally on the sample line. Let's consider the following lines:
ezvl-30ppp187.epix.net - - [23/Aug/2000:01:13:40 -0400] "GET / HTTP/1.0" 200 5810 "wysiwyg://navbar.outer.18/http://www.mainstreetbancorp.com/demo/index.html" "Mozilla/3.01C-KIT (Win95; U)"
188.8.131.52 - - [23/Aug/2000:01:28:43 -0400] "GET /img/anim_thumbtack.gif HTTP/1.1" 200 6514 "http://www.catchtheweb.com/express/search_1.htm" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)"
I can set a floating traps to look at B-B- (B for blank) and then [ ]. The footing trap parses each line and if it found B-B-B and  anywhere on the each line, then it highlights it.
When using the floating trap, the following may affect the size of extracted fields:
A template's width serves as the maximum field length that can be extracted.
The occurrence of the next trap character will truncate a field.
The beginning of a new field will truncate a field.
I fully understand your model. My challenge is to effectively capture the detailed lines from the report, I need to trap based on the position of a decimal ".". There are other decimals ahead of the one I need to trap, so a standard floating trap will not work.
Is it possible to use a standard "fixed" trap, but have it toggle between a "." and a numerical value.?
You may try the character list trap and provide the following characters:
.0123456789, which mean if any of these characters are present that that column position, then select the line. The character list trap puts the Greek symbol theta right above the character in the sample line. You may also try the numeric OR trap (the pipe character |).
PDF files are such a joy to work with ...
Mo suggestions would be my first line of approach as well. Quick and easy to try.
If that does not work out then ...
I have not tried this and I am no expert on it in any way but have you considered a REGEX approach?
Complex to define, possibly, but it may be possible to create a catch all design that would work for any variation that might creep in over time and changes to the PDF producer source program.
If not regex then a "nasty PDF file" solution, from pre regex availability days, would be to grab a large chunk of the line or even all of it in a single field and then slice and dice it to extract the fields required. Something of a sledgehammer to crack a nut in your single character position shift example BUT again if there may be a possibility that such glitches could further develop and become more erratic a well thought through slice and dice approach can be extremely good as a catch all solution.
I have, sometimes, found reports where the first few fields do manage to present consistently in a report and the inconsistency only arrives later in a report line - so one can simplify the task by using a standard approach for as much of the consistent section as possible and then the slice and dice approach for the rest.
Going back to the potential for a floating trap approach (and noting that you have to work to define every field in the line to make it work but see above w/r to extracting a large "field" and slicing and dicing) is there anything else you can trap with? If you can and have enough space to define an over-size field that can be used though out the report then one can potentially extract the numeric values approximately in position and sort out the alignment and if necessary convert the field type using a calculated field.
Once again the objective would be to come up with something that allows both for the visible problem and any possible and predictable future extension of the type of problem if at all possible.