Re: Initial questions

Hi Ersin,

Excellent! I'm looking forward to seeing the patch.

The vertical offsets are given by the fp_CellContainer::getTopPad()
and ::getBotPad() methods.

These in turn simply return m_iTopPad, m_iBotPad

These values are set in fl_CelLayout::setCellProperties()

From the values of m_iTopOffset, m_iBottomOffset

These are either set to the default values of 0.01inj

or the values of the properties of "cell-margin-top" and "cell-margin-bottom"

Cheers

Martin

On Fri, Nov 27, 2009 at 12:35 PM, Ersin Akinci <ersin.akinci@gmail.com> wrote:
> Hi Martin,
>
> I fixed all the previous problems and I've got a patch almost ready to
> go.  I was surprised how simple the final patch ended up being, it's
> basically just one line of code plus the property import/export stuff!
>  It was all a matter of finding out where in the rendering engine to
> put it.  I'm just waiting for uwog to finish an invoice template,
> which should be done by tomorrow, for me to submit the patch.
>
> One last question, however.  When the cell's vert-align is set all the
> way to the bottom (it uses a variable from 0 to 100) the text won't
> render until you click in it/type in it because technically the cell
> is being rendered ever so slightly outside of the clipping rectangle.
> This could easily be rectified by making sure that the cell's ypos +
> height is always at least a certain margin above BotY.  What
> property/variable sets the margin?  I know that cell-margin is
> currently unused, so is it table-row-spacing?  I noticed that it's set
> by default to 0.01 in, whereas row-col-spacing is 0.03 in, but on my
> screen I can clearly see that the column "margin" is much narrower
> than the row "margin", so maybe that's not it.  Is it one of the
> padding settings?
>
> Also, aside from the actual property, what are the other
> spacing/margin/padding properties supposed to do in principle?  I'm
> interested in implementing them.
>
> Thanks,
> Ersin
>
> On 11/20/09, Martin Sevior <msevior@gmail.com> wrote:
>> On Fri, Nov 20, 2009 at 10:37 AM, Ersin Akinci <ersin.akinci@gmail.com>
>> wrote:
>>> Hi Martin,
>>>
>>> Thanks for the heads up, I joined the group and now I have access to
>>> the NLNet documents.
>>>
>>> I took a break yesterday from coding and went back at it again today,
>>> and now I've got vertical alignment working reliably when the table
>>> isn't broken across multiple pages.
>>
>> Excellent that unbroken tables work.
>>
>>   As you predicted, broken tables
>>> are problematic.  It seems to be getting caught in a loop in the
>>> fp_TableContainer::_brokenDraw function, specifically when evaluating
>>> whether pCell->getY() > getYBottom().  It effectively "skips"
>>> formatting that cell without moving pCell to the next cell container,
>>> and since pCell never increments and the rendering logic is nested
>>> within a while(pCell) loop, it never breaks out.
>>>
>>
>> OK A simple solution is to just add the m_iYOffset to pCell->getY()
>>
>> ie ((pCell->getY() + pCell->getYOffset()) > getYBottom())
>>
>>> I'm guessing that this check is never normally made because pCell's
>>> ypos is magically never set to be greater than the table's y bottom,
>>> otherwise this loop would be unavoidable with all broken tables.
>>
>> Right.
>>
>>> However, my vertical alignment code works by adding m_iYOffset to ypos
>>> in fpCellContainer::setToAllocation.  BTW, I reworked everything so
>>> that fl_CellLayout::format calculates the YOffset for each cell and
>>> assigns it to m_iYOffset in each cell layout's container with an
>>> accessor function.  I tried overloading getY, but it proved to be
>>> messy, and at any rate I'm not sure how viable it is in the long term
>>> to overload basic accessor functions like that since at some point
>>> down the line a new function might be written that assumes that getY
>>> returns the true ypos of the cell.
>>>
>>
>> All good solutions.I think simply adding the offset as suggested above
>> will fix you up.
>>
>>> Could you give me a brief overview of how tables work when broken over
>>> pages?
>>
>> The idea is that there is a mater table which is as big as it needs to
>> be. It could be over a pages long for table. Then table that are
>> actually displayed in columns are "broken" at the appropriate y
>> position.
>>
>> So suppose a table has a total height of 100,000 layout units. each
>> column on a page might be 10,000 units. The top of the table is
>> positioned at position 5,000 in a column.
>>
>> Then first broken table is has a broken position of 0. ie there is 0
>> offset between the top of this table and the top of the master table.
>>
>> The second broken table is broken at 5000. ie There is an offset
>> between the top of this table and the top of the master table. (the
>> first broken table fill the second half of the column and takes up
>> 5000 units).
>>
>> The third broken table has a broken position of 15000, the 4th 25000,
>> 5th 35000 etc.
>>
>> So the idea is that the code in fb_ColumnBreaker puts tables into the
>> columns one after the other. Then code in brokenDraw knows which
>> elements are contained in each broken table and draws them.
>>
>>> Also, I wanted to clear up some confusion over the
>>> terminology: is the term "broken" used to refer both to tables split
>>> over multiple pages as well as tables split up by cells?
>>
>> No. "broken" means it is a table container that is placed in a column
>> and can be drawn.
>>
>>> Right now
>>> I'm thinking about adding a check somewhere so that if the ypos cell +
>>> height cell > ybottom of the table then it manually
>>> shifts...something, but I don't know what.  Shifting the ypos of each
>>> cell in each row below it would be horribly messy.  Perhaps nipping
>>> the problem in the bud by changing the allocations?  I don't know yet
>>> because while I feel like I have a good grasp on how unbroken tables
>>> and cells are rendered, I still know very little about when they are
>>> broken.
>>>
>>
>> Hopefully the suggestion I made above will work. Maybe you should
>> submit a patch to the mailing list if it doesn;t work? I'll take a
>> look and see if it can be fixed. I finally have a bit of time to do
>> some coding.
>>
>> Cheers
>>
>> Martin
>>
>>
>> Cheers
>>> Thanks,
>>> Ersin
>>>
>>> On 11/18/09, Martin Sevior <msevior@gmail.com> wrote:
>>>> Hi Ersin,
>>>>             Please join the
>>>>
>>>> abi_nlnet
>>>>
>>>> Group. The document describing the NLnet sponsored bugs is:
>>>> cell alignment
>>>> abi_nlnet.abw
>>>>
>>>> https://abicollab.net/documents/edit/1751/0
>>>>
>>>> You do not have to implement the UI for vertical cell alignment but
>>>> you do need to implement import/export to odt format.
>>>>
>>>> Cheers
>>>>
>>>> Martin
>>>>
>>>
>>>
>>> --
>>>
>>> =========
>>>
>>> Ersin Y. Akinci -- http://www.ersinakinci.com
>>>
>>
>
>
> --
>
> =========
>
> Ersin Y. Akinci -- http://www.ersinakinci.com
>
Received on Fri, 27 Nov 2009 23:41:23 +1100