DO NOT REPLY [Bug 39777] - [PATCH] GSoC: floats implementation

2006-07-19 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39777.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39777





--- Additional Comments From [EMAIL PROTECTED]  2006-07-19 10:13 ---
Created an attachment (id=18617)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18617action=view)
First patch for before-floats implementation

Basic implementation of before-floats. Known problems are:
* bug when the whole normal content is typeset and there are both footnotes and
floats left to be placed;
* floats too big to even fit on one page alone are not handled yet;
* the keep-with-previous property for the generated inline anchor-area is not
implemented;
* some clean-up in LayoutManagers should be possible;
* others that I may have missed...

Changelog:
* Created a breaking subpackage where, if this is agreed, all classes related
to the Knuth approach will eventually be placed.
* Created an OutOfLineRecord class for dealing with both before-floats and
footnotes. It is basically made of code extracted from PageBreakingAlgorithm
that was related to footnote handling. Most of it could also be used for
floats.

(pending: documentation and testcases)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


Re: [GSoC] Auto-table layout questions

2006-07-19 Thread Patrick Paul

Hi,

I think I am trying to solve this the wrong way. I just realized there 
is a getKnuthElementsForRowIterator() method in the TableContentLM which 
in turn makes use of cellLM.getNextKnuthElements() ...


Patrick

Patrick Paul wrote:


Thanks for the pointers.

The intended meaning of un-touched was to say that no line-breaking 
or other processing takes place on the elements, just returning the 
element list.


What is unclear to me is how I can get the element list for a specific 
table-cell. Here is what how I see things :


1. create a TableRowIterator for the table-body elements
2. do a prefetchAll()
3. Iterate over row = EffRow[] getNextRowGroup()
  3.1 Get the element list of each table-cell ? This is where I am 
unsure how I should get the element lists :

   row.getGridUnits().getPrimary().getElements() ?
  3.2 Once I have the element list of the cell I can easily get its 
full length.


As well, is there any reading I can do to get a deeper understanding 
of GridUnits ?


Thank you,

Patrick Paul

Andreas L Delmelle wrote:


On Jul 18, 2006, at 21:30, Patrick Paul wrote:

Now I need a little pointer on how best to fly over table rows  
without touching them. I have some idea but I would prefer to  
check with the experts.




Tricky indeed... the TableRowIterator constructs the very list it is  
supposed to iterate over
--I mean: it creates the elements from another list instead of 
simply  returning them un-touched.
prefetchAll() is unused ATM, exactly because you would touch all  
rows (if I catch your intended meaning of that word correctly?)


OTOH, that method seems to have been added with auto-layout in mind  
anyway, so give it a shot, but mind the large tables...


Seems like, instead of simply prefetchNext(), you could try refining  
it to:


1) prefetchNext() [= get the row *group*, minor yet important detail]
2) doing what you need [= calculate content-length?]
3) immediately dispose of it

Another option would be to use an altered version of prefetchNext()  
altogether.


HTH!

Cheers,

Andreas