[reportlab-users] From intra-paragraph images to drawings?

[Andy Robinson]

> Actually, why not call it a <canvas> element, like in HTML5? Or maybe even create an HTML5-Renderer?


<canvas> is a good idea for the tag name in a paragraph which flips
you back to drawing on the canvas.

HTML rendering is a tough call.  We don't have a CSS-like box model in
there. Our general experience is that the more you copy HTML, the more
people get irked by the inevitable slight differences and think it's
broken.  Probably the right thing to do is start again.

With our own internal resources (which are very heavily stretched next
two months), I need to stick to Plan A:  clean up the test suite, make
use of the modern standard library and deployment tools better, slim
things down then start on Python 3 compatibility.  This will be a
significant enough task.     We also need to do a lot of lower level
work on things like font formats and strict PDF 1.7 support as well.

If anyone wants to work separately on a Paragraph re-implementation,
this is the time; the code is there in BitBucket, and forks are easy
to follow, and I would contemplate any changes.  However we have to
bear in mind that paragraph-wrapping is the key bottleneck in many
applications and it's easy to write a really slow implementation in
Python.    Possibly this can be handled by having a fast 'special
case' implementation for when there are no separate fragments.

- Andy




On 9 May 2013 13:09, Dinu Gherman <gherman at darwin.in-berlin.de> wrote:

> Robin Becker:

>

>> On 08/05/2013 10:53, Dinu Gherman wrote:

>>> Hi,

>>>

>>> I wonder if anybody has tried to generalize the concept of intra-para-

>>> graph images to drawings? This would enable nice features like something

>>> called "sparklines", which have been introduced by Edward R. Tufte, if

>>> I'm not mistaken. See also this nice jQuery package:

>>>

>>

>> I don't think it would be too hard to make a drawing produce an image that could be injected into a paragraph. The main problem would be how to identify the chart code and data in a sensible way. The img tags have a lot of control over height / width etc etc, but they don't need much more than a uri to identify them. Presumably one could inject a namespace into the parser somehow as is done for various other cases eg callbacks are identified by name and are assumed to live directly on the canvas

>>

>>>      func = getattr(tx._canvas,name,None)

>>>      if not func:

>>>              raise AttributeError("Missing %s callback attribute '%s'" % (kind,name))

>>>              tx._canvas._curr_tx_info=dict(tx=tx,cur_x=cur_x,cur_y=cur_y,leading=leading,xs=tx.XtraState)

>>>              try:

>>>                      func(tx._canvas,kind,cbDefn.label)

>>>              finally:

>>>                      del tx._canvas._curr_tx_info

>>

>> that might work for a drawable object

>>

>>

>>>   http://omnipotent.net/jquery.sparkline

>>

>> I looked at the front page and it looks OK, but I wasn't able to see how data/chart type were selected for the charts; one of the paras is described thus

>>

>>> <p>

>>> Inline

>>> <span class="sparkline">

>>> <canvas style="display: inline-block; width: 21px; height: 16px; vertical-align: top;" width="21" height="16"></canvas>

>>> </span>

>>> line graphs

>>> <span class="sparkline">

>>> <canvas style="display: inline-block; width: 63px; height: 16px; vertical-align: top;" width="63" height="16"></canvas>

>>> </span>

>>> </p>

>>

>> but the two charts are different so I guess the data / chart is being pushed into them via the class.

>

> The docs give a better explanation:

>

>   http://omnipotent.net/jquery.sparkline/#s-docs

>

> When not set dynamically via JS, chart attributes can be given as HTML attributes of the span tag and the chart data as its text node.

>

> Since the current intra-paragraph images need to have a fixed size, I thought this concept could be applied ot drawings, too. Something like this:

>

>   <img src="../images/testimg.gif" />

>

>   <drawing src="my.pkg.mod.klass" />

>

> Then we basically need to find the code to draw the thing and pass it some arguments including data. I don't quite see any rocket science in that.

>

> Actually, why not call it a <canvas> element, like in HTML5? Or maybe even create an HTML5-Renderer? That would stir up some people's interest in cross-publishing with Reportlab, maybe, who are turning now to other solutions.

>

> Regards,

>

> Dinu

>

> _______________________________________________

> reportlab-users mailing list

> reportlab-users at lists2.reportlab.com

> http://two.pairlist.net/mailman/listinfo/reportlab-users




-- 
Andy Robinson
Managing Director
ReportLab Europe Ltd.
Thornton House, Thornton Road, Wimbledon, London SW19 4NG, UK
Tel +44-20-8405-6420