a call for "table print" specific testing

[Lubomir I. Ivanov]

On 25 July 2014 17:23, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Fri, Jul 25, 2014 at 04:14:27PM +0300, Lubomir I. Ivanov wrote:
>> the other thread aside ([PATCH 0/7] multiple PrintLayout related fixes).
>
> That thread seemed to indicate that we are making progress but there are
> still bluriness issues here and there. What a pain.
>
>> please, apply the attached patch and test the "table print" option
>> with many dives on a lot of pages with long dive notes on multiple
>> lines!
>>
>> i have a script that generates a massive divelog which produces
>> dive rows in the table with variadic height and all seems good.
>>
>> the patch notes *attempt* to explain a strange bug that occurs....
>
> Even with the explanation it still seems baffling to me. I wonder if
> Thiago can find someone in the Qt community who could help us with this.
>
> Side note on your patch, Lubomir... >> 1 and << 1 used to be faster with
> compilers ca 1985. The compilers that we use today tend to figure these
> things out by themselves. And even if we were to save two cycles here -
> from a readability perspective I prefer * 2 and / 2.
>

updated version with / 2 attached.

could be a bug in QPicture. the math makes no sense; i tell QPicture
to grab a rectangle in the lines of {0, 0, pageW, pageH}, but what it
actually does is {0, -negValue, pageW, pageH - negValue} (where
negValue is the size of the previous row), introduces a row from the
previous page and yet places the new page heading exactly at {0, 0}.
the visual result is that on top of a heading on a new page the row
from the previous page can be seen (an even goes outside of the page
frame).
for some reason if we adjust the rectangle by the (heading-height / 2)
offset it works fine on a couple of OSes.

on the other hand, directly rendering to the QPainter that is attached
to the printer works fine and the index list of where pages start
makes complete sense )this results in a raster table though).

would be happy for someone to chime in with ideas about this part and
printing in general, but we haven't seen such a person yet.
either way, this is a bug fix (on top of 0a53449) if we want the
"table print" table to be in vector.

lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PrintLayout-fix-a-potential-bug-in-the-recent-table-.patch
Type: application/octet-stream
Size: 4023 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140725/c74d6f30/attachment.obj>