Quote:
Originally Posted by badbob001
Ok, but I just didn't want an arbitrary auto_split_buffer percentage to push the final image beyond the target dimensions. It would be nicer if the overlap buffer was dynamically determined based on how much leftover space there will be after the split.
Say the target device is 600x800 and there is a 1000x800 page. A non-buffered split would be 2 x 500x800 pages. With bordering, it'll add 50 pixels to the left/right sides of each page. It would look better to only add the border to the sides away from dividing edge:
[border][left page] [right page][border]
Now it is very clear visually which side of each page is the divider.
|
Sorry, I don't see the point of [border][left page] [right page][border]. The auto split algorithm should only be splitting pages which are independent from each other. If it decides to split them then, it doesn't matter which page was left or right before the split (since they are independent, they could have easily been on opposite sides of the same piece of paper, know what I mean?). All that matters is maintaining proper page order during a split.
Btw, the split doesn't necessarily occur in the dead center of the image. The split algorithm starts in the center and moves outwards to handle cases where the two-page scan isn't perfectly centered. The split buffer then takes the specified percentage of the other split page. So if a page with a width of 1000 is split at x=600 and the split buffer is set to 0.1, then the left page (with a width of 600) will get a 40px buffer from the right page (width of 400), and the right page gets a 60px buffer from the left page. This all happens prior to resizing.
Quote:
Originally Posted by badbob001
Another idea would be a dynamic overlap buffer that would calculate how much room is left (600-1000/2=100) and add that difference to to the left and right pages so we don't have to deal with borders for splits.
[left page][100 pixel overlap] [pixel overlap][right page]
|
I like that idea, I'll try to implement it.