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

[Dinu Gherman]

Robin Becker:


> We try to wrap a height 40 paragraph in available height 30. That  

> fails, but the split cannot reduce the height. We flip to the next  

> frame (also with available height 30) and try again; that fails so  

> we give up. You probably wonder why we won't split into two lines.  

> That is a hack in Paragraph.py where we always fail to split if  

> trying to return a first split with only one line in. The intention  

> is to avoid an orphan. If you intend to split lines into frames with  

> only one line in them we need a different concept of layout.


It's a pitty that such behaviour is not documented anywhere.


>> 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.

>

>

> .......

> I suspect this error comes because you're being a bit clever about  

> the split paragraphs. Remember that the outer packing loop tries to  

> be as stupid as possible. The split purported to return a first  

> flowable for which the wrap would succeed. Apparently in this case  

> although the split returned 2 flowables the attempt to re-add the  

> first with the existing frame parameters failed.


I'm not sure that makes sense to me. I would really like to see a  
working
example of a new paragraph, as minimal as possible, and not be forced to
make assumptions about hacks, undocumented behaviour and whatever. Is  
that
too much to ask for?

There is a nice study by Anthony Senyard and Martin Michlmayr showing  
the
importance of modularity for the success of Open Source projects:
http://www.cyrius.com/publications/senyard_michlmayr-successful_project.html
I'm citing their criteria here (see point 2):

1. A prototype with plausible promise must have been created.
2. The design of the prototype must be modular.
3. The source code of the prototype must be available and workable
    (ie. compiles and executes).
4. A community of users and developers must be attracted to the project.
5. The project author must be motivated to manage the project or find
    a replacement.
6. Project communication and contribution mechanisms must be in place.
7. The scope of the project must be well defined.
8. A coding standard or style must be established.
9. Development versions of software must have short release cycles while
    user versions must be stable and consistent.
10. A license must be chosen which is attractive to developers.
11. A suitable management style must be selected.
12. An appropriate amount of project documentation must exist.

So, again, I would really really like to see precize documentation and/ 
or
code that allows me to write a working paragraph that behaves well in
the ReportLab universe.

Regards,

Dinu