PageRanges

[Janschenkel]

Goshdarnit, my story would have been so much better if I had remembered the 'flaggedRanges' property and could have concluded with that.
Why do I have the memory of a goldfish?

Jan Schenkel.

[mwieder]

flaggedRanges?
Is this documented somewhere?
Wuzzitdo?

[LCMark]

Ah - it would appear it is not in the dictionary at the moment - odd as 'flagged' is. 'the flaggedRanges of <field chunk>' allows you to get a set a return-delimited list of the ranges of characters in a field that have the 'flagged' property set - for error highlighting etc.

[jameshale]

just filed a bug http://quality.runrev.com/show_bug.cgi?id=12182

seems the pageranges doesn't like to count past 65535.

if there are more than 65535 characters in the field the character count resets after it hits 65535.

example given in bug report (numbers refer to the example stack)...

Example: if there are 70575 characters in the field then the last three lines of the pageranges gives...

64706,1588
1589,4192
4193,5040

The last value (5040) is 70575 - 65535

a workaround is easy enough but it would be nice if it wasn't required.

[LCMark]

@jameshale: Indeed - I noticed that and fixed it this afternoon for the next build (which will be 6.6.2-rc-1 and/or 6.7-dp-2 -- its been merged into both). It was as you surmised - a 16-bit int was being used rather than a 32-bit int.

[jameshale]

Wow that was serendipitous.
Were you perhaps looking at http://quality.runrev.com/show_bug.cgi?id=11688?
Or something else that cropped up with the way pageranges works?

[jameshale]

I have been using this property in my current project as a way to replace scrolling groups and allow for easy switching between 1 and 2 page views. It is so much better than scrolling fields (especially when your field has over 100,000 characters of styled text.)
However I seem to have run into an inconsistency.
Firstly, I am not using a fixed text height. I realise this may be an issue but in my initial testing it didn't seem to be and it allows images to be embedded in the pages without issue.
In the course of testing other aspects of my app I need to change pages frequently and it was here I noticed the problem.
Some pages were too long to fit the field I was displaying them in.
OK, maybe the fact I am not using fixed text heights is going to be a problem.
To try and get round this I reduced the height of the field from which I was taking my page ranges (by 60px!) thinking this would more than compensate for variable text heights (although images didn't cause any problems and my font size is only 14).
Still no. The variation was larger than 100px on some pages (display field is 550 by 700).
Tried also reducing margins and width to make the source field smaller, still no.
Indeed the variance between pages became even more noticeable. Not what I expected.
Reading back through Jan's proposal I noticed he referred to the PageHeights property.
Going to the dictionary I see it requires a field border of 0 and a margin of 6 to work correctly.
Getting the impression that the PageRanges may use the PageHeights routines I went back and set the appropriate values in the source field.
The inconsistency in length reduced and is now about 1 line out in 1 in 8 pages, 2 lines out in say 1 in 20.

If this 'recovery' is indeed due to obeying the PageHeights requirements then at the very least they should be repeated in the dictionary entry for PageRanges.

If not, what else might be going on?
What assumptions are being made in calculating the ranges?
What, if any, are the correct field properties to have in place?

[LCMark]

@jameshale: I noticed the index problem when I was looking into the pageHeights/pageRanges issue when paragraph properties are applied. I had a go at fixing the problem but I was getting partial lines in the character ranges and I couldn't figure out what was going on in the time I had. The pageRanges code was based on the pageHeights code which is why they are probably showing similar issues.

I think we can agree that the correct behavior of pageRanges and pageHeights should be that you get sequences of pages that fit within the geometry of the field so I think that is the behavior to aim for. At the moment the routines are not taking into account paragraph properties that add space in-between paragraphs which is the principal problem I think.

Of course, that problem does illustrate a deficiency in pageRanges as a means to do pagination - if a page splits a paragraph half-way through its lines, what should happen if the paragraph has spacing above/below or borders? i.e.

Code: Select all

+----------+
|Some text |
|wrapped   |
+----------+

If a page break occurs between these two lines, really the border / spacing should apply above the first line on the first page, and then below the second line on the second page. This is something what would mostly work with pageHeights (since the field should clip the unwanted sections away); however with pageRanges its a little more tricky as that's just giving you a character range (and so can't communicate any changes in formatting that might be needed).

Ultimately I guess what we need is both to be able to set things like borders individually (top, left, right, bottom) and then modifications to the styled text exporting properties (RTF, HTML, StyledText array) so that if you export part of a paragraph it appropriately unsets any non-applicable borders and such. (This is me musing slightly here - the pageHeights / pageRanges still at least need to be fixed to work as well as they can with current field properties).

[jameshale]

Thanks for replying Mark. I take it from your discussion that the pageranges works for what it is given by the pageheights and that is where the finessing needs to take place.
As I mentioned I was able to minimize the unevenness by adhering to the 0 border, 6 margin note in the page heights entry. At the very least this should be referred to in the pageranges entry.
As for the paragraph formatting issue there could also be some additional information in the htmltext entry at least stating what paragraph style options survive HTML to LC's htmltext conversion. This would at least give a heads up until a better resolution is found.
Given the unevenness I observed was for basically plain vanilla HTML (I had stripped out anything I didn't see described in the htmltext dictionary entry) it would seem that it is not just paragraph styling that is having difficulty.
I must say I did find it odd there are border/margin conditions on the pageheights. It seems strange to place such a restriction. It as if the routines are just assuming a specific setup rather than taking the parameters that exist in any particular case. Perhaps it wasn't an issue back then but it might point to other restrictions (assumptions) that simply no longer apply and thus are not able to cope with the data presented.
My lower level coding skills stopped I with fortran so I am not able t look at the code in any meaningful way to be of any help. But I would like to encourage you and or someone in the team to look a bit deeper.
Even though printing or presenting pages probably seems very yesterday there is still a need and LC provides such a great vehicle to fashion solutions that could service that need.
Being able to accurately able to break a "page" ( of any dimension) correctly would be really so cool.