[reportlab-users] Experimenting with new paragraphs, splitting issue

[Dinu Gherman]

Robin Becker:


> the splitting protocol is supposed to work as follows.

>

> Given space W x X in which to fit W and a flowable f

>

> 1) f.split(W,H) should return a list.

> 2) if the list is empty then f refuses to split into that space.

> 3) if the list is non-empty then the first element should be a  

> flowable that is guaranteed to be wrappable into the available space  

> ie f.wrap(W,H) <= (W,H) (<= means fits into).

> 4) any other elements of the returned list should be flowables. What  

> they contain is entirely the responsibility of the called split  

> method.

>

> In the platypus doctemplate framework the frame acts as container  

> and calls the wrap and split methods of the flowable f. The frame is  

> supposed to take care of the space appropriately. The danger here is  

> that f.wrap(W,H) --> w0,h0 is too large, but errors cause f0 =  

> f.split(W,H)[0] to be such that f0.wrap(W,H) doesn't fit in the W,H  

> box. The frame usually applies fuzz so arithmetic errors won't cause  

> problems. However, we rely on the flowables being honest.


Ok, I've stripped down my sample code even further. It now should
generate only one line of text spread over two little frames. When
I use the RL paragraph class for doing this I get the following
traceback:

	$ py251 test_twoframes.py
	Traceback (most recent call last):
	  File "test_twoframes.py", line 49, in <module>
	    main()
	  File "test_twoframes.py", line 45, in main
	    doc.build(story)
	  File "/usr/local/lib/python2.5/site-packages/reportlab/platypus/ 
doctemplate.py", line 740, in build
	    self.handle_flowable(flowables)
	  File "/usr/local/lib/python2.5/site-packages/reportlab/platypus/ 
doctemplate.py", line 671, in handle_flowable
	    raise LayoutError(ident)
	reportlab.platypus.doctemplate.LayoutError: Flowable <Paragraph at  
0x10f54e0 frame=F2>aaaaaaa bbbbbbb ccccccc ON_NEX too large on page 1

When I use my own (attached) paragraph class, I get the following
traceback (preceeded by some debugging info):

	$ py251 test_twoframes.py
	*** parse aaaaaaa bbbbbbb ccccccc ON_NEXT_LINE
	*** wrap (240.000000, 30.000000)
	*** wrap (240.000000, 40.000000) needed
	*** parse aaaaaaa bbbbbbb ccccccc ON_NEXT_LINE
	*** split (240.000000, 30.000000)
	p1 aaaaaaa bbbbbbb ccccccc
	p2 ON_NEXT_LINE
	*** parse aaaaaaa bbbbbbb ccccccc
	*** wrap (240.000000, 30.000000)
	*** wrap (240.000000, 20.000000) needed
	*** parse ON_NEXT_LINE
	*** wrap (240.000000, 4.000000)
	*** wrap (240.000000, 20.000000) needed
	*** parse ON_NEXT_LINE
	*** split (240.000000, 4.000000)
	p1
	p2 ON_NEXT_LINE
	*** parse
	*** wrap (240.000000, 4.000000)
	*** wrap (240.000000, 20.000000) needed
	Traceback (most recent call last):
	  File "test_twoframes.py", line 49, in <module>
	    main()
	  File "test_twoframes.py", line 45, in main
	    doc.build(story)
	  File "/usr/local/lib/python2.5/site-packages/reportlab/platypus/ 
doctemplate.py", line 740, in build
	    self.handle_flowable(flowables)
	  File "/usr/local/lib/python2.5/site-packages/reportlab/platypus/ 
doctemplate.py", line 663, in handle_flowable
	    raise LayoutError(ident)
	reportlab.platypus.doctemplate.LayoutError: Splitting error(n==2) on  
page 1 in
	<Paragraph at 0x10f5738 frame=F1>ON_NEXT_LINE

To me it seems like RL is already doing the wrong thing, given the
first traceback above. And apart from that, I don't understand why
RL calls my pararaph's split method the second time with an y value
of 4.0 as you cen see in the debugging info above? I've run this
with RL-SVN, BTW.

Regards,

Dinu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mini2.tgz
Type: application/octet-stream
Size: 2478 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20071203/db12145a/attachment.obj>
-------------- next part --------------