On Mon, Nov 16, 2009 at 10:09 PM, Ersin Akinci <ersin.akinci@gmail.com> wrote:
> Hi Martin,
>
> Thanks again for your advice. I've made some limited progress in that
> I've gotten AbiWord to recognize my property tags, but for the most
> part I'm simply trying to wrap my head around the rendering engine. I
> think I understand it much better now, but I've still got my work cut
> out for me, and I have a few more questions for you.
>
> The short version: When I insert a table and type something into it, I
> know what functions are being called and what they do in general, but
> I don't know the chain being called. That is, I'm having difficulty
> understanding how these functions are connected to each other,
> especially when transitioning from the logical layer to the physical
> layer.
>
Hi Ersin,
Good news that you've go the property tag recognized!
The general terms, fl_* classes shows the logical presentation of the
document structures.
So for example, fl_DocSectionLayout holds all the content of a
document section. Document sections, contain paragraphs
(fl_BlockLayout), tables (fl_TableLayout), footnotes
fl_FootnoteLayout etc)
These are connected through a collection of doubly linked lists:
So for a example a section containing paragraphs (block) and a table
might look something like this.
Section<=>block><=>block<=>table<=>cell<=>block<=>block<=>block cell<=>block<=>
etc.
So the block class can be contained by either section directly or by the cell.
The fp_* physical classes contain the information required to actually
place the object on the screen. All the physical class have methods
that enable them to draw themselves and they continually delegate this
formation to the physics classes they contain.
So a table draws itself by drawing its collections of cells (plus what
info the table needs to draw).
Cells draw themselves by drawing their collections of lines (plus
whatever info the cells need)
Lines draw themselves by drawing their collection of runs.
Runs actually draw themselves on the screen.
> The longer version:
>
> First, I was told in IRC that the logical layer already does the
> "physical" positioning of all the elements on a virtual page in 1440
> dpi and that the actual physical layer simply scales them to the
> screen. The latter certainly doesn't seem to be true, and if it were,
> why not implement vert align in the layout methods? On the former
> point, if it is true, I have yet to find the code that does it (maybe
> something about that call to the function "tlu"?) It's a little
> confusing because the components of the logical and physical layers
> don't directly correspond to each other.
>
The Physical fp_* classes actually do the positioning in layout units
at 1440 dpi.
The graphics classes translate these layout units to the actual
resolution of the drawing device be it a compuer screen or printer
paper.
> Second, I put a bunch of UT_DEBUGMSG's to trace through the functions
> (as gdb's backtrace goes through a lot of GTK methods), and I was
> surprised to learn that fp_CellContainer::draw is _never_ called. Yet
> cell containers are definitely being created, and
> fp_CellContainer::_drawBoundaries is being called, but I don't know
> where from. It seems like the rendering "control path" goes like
> this: page -> column/vertical container -> table -> line, but I don't
> know where _drawBoundaries falls. It seems especially strange because
> it starts with an underscore, doesn't that usually mean that it's a
> private function?
>
Cells are most often drawn with:
void fp_CellContainer::drawBroken(..)
tables are most often drawn with:
fp_TableContainer::drawBroken(...)
Tables and cells are first layed out as one single entity, then
"broken" across columns.
So a table that spread across 20 columns would have 20 linked broken
tables. The broken table has all the offset calculations that position
the cells correctly in the columns.
Cells can also be broken across columns.
> On that note, seeing as I'm confused as to which fp_Cell functions are
> called and which are not, I haven't been able to see how cell
> containers and lines are connected in the rendering process. The
> fp_Line::draw method seems to be called independently by the
> fp_VerticalColumn::draw render loop without any reference to a cell's
> properties.
>
No, a line contained by a cell is drawn through
fp_Cellcontainer::drawBroken(..) method.
However a fp_CellContainer is a child of the fp_VerticalContainer
class and inherits some methods from it.
The fp_VerticalContainer class is implemented in the fp_Column.cpp file.
> In fact, it almost seems like the y position of cells and tables is
> dependent upon the y position of lines rather than the other way
> around! I noticed that fp_VerticalContainer goes in a loop calling
> the draw functions of each container within it, so I tried a quick
> hack: if the current container being looked at is a line, do
> pContainer->setAscent(30) (I made the setAscent and setDescent
> functions to public in the header file). I was very surprised to see
> that the entire document shifted up by thirty pixels, whereas I was
> thinking that only the lines would be.
>
Don't change the publicity in your patch. The pContainer could be
actually be a table.
> One last question, for now: what exactly is a broken table? Is it a
> table that's spread over multiple pages?
>
Yes. That is it exactly.
Good luck for th enext phase.
Cheers
Martin
> Thanks for bearing with me! As confusing as it is, I feel like I'm
> beginning to get the swing of the rendering engine, and with a little
> more study I hope that I'll be able to contribute code soon.
>
> -Ersin
>
> On 11/15/09, Martin Sevior <msevior@gmail.com> wrote:
>> On Sun, Nov 15, 2009 at 8:07 AM, Ersin Akinci <ersin.akinci@gmail.com>
>> wrote:
>>> Looks like I spoke too soon. There's a very handy README.TXT in the
>>> text/fmt/xp directory of the source that makes a lot clear, and uwog
>>> has been helping me with a lot of the basics. I think the critical
>>> thing to understand for me is that cells are sections, but unlike
>>> tables they do _not_ have a separate source file =).
>>>
>>
>> Yes. Cells and tables are in the same source file.
>>
>> Everything is layed out from top to bottom in the whole document.
>> The top left corner of the document is (0,0)
>> The top left corner of the column is (0,0)
>>
>> You are on the right track by altering the cells y position.
>>
>> All positions are relative to their own containers.
>>
>> Line positions are calculated relative to the cell positions which in
>> turn calculated relative to the table positions.
>>
>> The complication is that tables are contained by columns which are
>> constrained to lie on a page. Worry about that later though.
>>
>> I hadn't thought to use the cell y-padding to position it. I think it
>> would be better to invent a new fp_CellContainer member variable to
>> position the cell vertically. Call this m_yAlign. Then the cell's
>> yposition is YofRow + yPad + m_yAlign
>>
>> Then m_yAlign is normally 0 unless vert-align is centered or bottom.
>> If it's centered yAlign= ((Height of row) - (height of cell))/2
>>
>> If it's "bottom" the m_yAlign = (Height of row) - (height of cell)
>>
>> You need to make sure m_yAlign is updated every time
>> fl_CellLayout:::format() is called.
>>
>> Good Luck!
>>
>> Martin
>>> -Ersin
>>>
>>> On 11/14/09, Ersin Akinci <ersin.akinci@gmail.com> wrote:
>>>> Hi Martin,
>>>>
>>>> I dove right into the code and I feel like I'm making headway, but I
>>>> wanted to run a few things by you before I keep going.
>>>>
>>>> So far, what I understand about the way cells are displayed is the
>>>> following. Everything on the page is a kind of a "container",
>>>> including cells. Containers have draw methods that use properties to
>>>> render themselves, and in the case of cells there are margins,
>>>> currently unused and set to 0 by default, that affect the padding
>>>> around the cell. My initial reaction was that a vertical-align
>>>> property could trigger a recalculation of the top padding property (it
>>>> seems like everything is being rendered from top to bottom), but I'm
>>>> not sure when that should occur in the code. I'm a bit confused also
>>>> because I don't know how containers of different kinds interact with
>>>> each other, e.g. how does a line calculate its position based on the
>>>> information of its cell. I began to speculate that maybe the pPrev
>>>> and pNext pointers point to other kinds of containers and that the
>>>> draw/height calculation algorithms iterate over a linked list of them
>>>> to detect "adjacent" containers (i.e., text inside of a table cell
>>>> would actually be a line container linked to a cell container), but
>>>> that's sheer speculation--am I wildly off?
>>>>
>>>> So in other words, I think I understand now how individual container
>>>> types are being rendered (especially cells and lines) and I've
>>>> isolated the default values that might be responsible for putting cell
>>>> contents up at the top, but I don't understand yet how all the
>>>> components interact with each other.
>>>>
>>>> On a similar note, I thought that maybe a vert-align property in a
>>>> cell could change the ascent property in the line container(s) inside
>>>> of it, which would change its y position with respect to...something,
>>>> but again I don't know what it's being related to exactly. I would
>>>> much appreciate a brief explanation of how containers fit into the
>>>> grand scheme of the piece table, and also how they're
>>>> different/related to the similarly named "blocks" and "fields".
>>>>
>>>> Also, could you explain to me exactly how the X/Y coordinate system
>>>> works? I understand that most objects have two kinds of positions,
>>>> one being a physical pixel position on screen and another being a
>>>> position in the piece table, but what does the physical position mean
>>>> exactly? Are the X/Y coordinates being related to the screen directly
>>>> or through some other mechanism? I.e., when I say xoff = 50, is it
>>>> literally painting on screen fifty pixels to the right, or perhaps is
>>>> it fifty pixels to the right relative to the left side of the current
>>>> page...? Etc.
>>>>
>>>> By the way, I've signed up for Abicollab and I added you as a friend.
>>>>
>>>> Thanks in advance for the help, I hope I haven't been too vague!
>>>>
>>>> -Ersin
>>>>
>>>> --
>>>>
>>>> =========
>>>>
>>>> Ersin Y. Akinci -- http://www.ersinakinci.com
>>>>
>>>
>>>
>>> --
>>>
>>> =========
>>>
>>> Ersin Y. Akinci -- http://www.ersinakinci.com
>>>
>>
>
>
> --
>
> =========
>
> Ersin Y. Akinci -- http://www.ersinakinci.com
>
Received on Mon Nov 16 15:16:26 2009
This archive was generated by hypermail 2.1.8 : Mon Nov 16 2009 - 15:16:26 CET