[reportlab-users] Table rendering with HTML colspan and rowspan
Dirk Holtwick
reportlab-users@reportlab.com
Fri, 02 Jul 2004 15:10:24 +0200
This is a multi-part message in MIME format.
--------------020204080307050907020206
Content-Type: multipart/alternative;
boundary="------------020407090109070209090905"
--------------020407090109070209090905
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
I think you are talking about something we have already developed. It's
our product called "pisa". I attached a simple example with source and
result.
Get more informations on http://pisa.by.spirito.de (older demonstration)
or http://www.spirito.de
Yours Dirk
Bogdan M. Maryniuck wrote:
>On Mon, Jun 21, 2004 at 06:34:27AM -0700, andy@reportlab.com wrote:
>
>
>>IMHO a full HTML-like table rendering algorithm like this will be slow
>>and have different goals to our current tables.
>>
>>
>
>Agree. But current tables are just pain pain pain, when I do something like:
>OpenOffice.org XML -> RML -> PDF. Then I need to do lot of magic with XSL.
>And, those still ugly and unusable when somebody merges cells and/or rows...
>Yes, I know, I can do complex tables with nested tables, but this is
>exactly:
>
> painLevel = pow(painLevel, painLevel)
>
>Again, current tables are good, but only if you _know_ how your table
>should look like (you write a code to render PDF, or this is a bill your code
>produces or so). Instead, when you do lots XML transform from "unknown"
>sources, made by who knows whom by nobody knows what rules (basically
>Microsloth Word -> OpenOffice.org), than one moment you will see wrong
>output... But when I do the same with HTML -- tables are just excellent
>(with magic of CSS2 here/there).
>
>
>
>>It would make perfect sense to have two different kinds of tables
>>with different design goals.
>>
>>
>
>Agree! Besides, I haven't said: "replace that old implementation". ;-)
>
>
>
--
Mit freundlichen Grüßen
Dirk Holtwick
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
spirito GmbH
Dirk Holtwick (CEO)
Grünstraße 6
D-47051 Duisburg
fon: +49 203 3187778
mbx: holtwick@spirito.de
web: http://www.spirito.de
GnuPG fingerprint (http://www.gnupg.org)
A5A1 54E1 C82E 02AD 4804 0547 66F4 3FB0 C790 EBAB
--------------020407090109070209090905
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I think you are talking about something we have already developed. It's
our product called "pisa". I attached a simple example with source and
result.<br>
<br>
Get more informations on <a href="http://pisa.by.spirito.de">http://pisa.by.spirito.de</a>
(older demonstration) or <a href="http://www.spirito.de">http://www.spirito.de</a><br>
<br>
Yours Dirk<br>
<br>
Bogdan M. Maryniuck wrote:<br>
<blockquote cite="mid20040621141444.GC28957@bitute.b4net.lt" type="cite">
<pre wrap="">On Mon, Jun 21, 2004 at 06:34:27AM -0700, <a class="moz-txt-link-abbreviated" href="mailto:andy@reportlab.com">andy@reportlab.com</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">IMHO a full HTML-like table rendering algorithm like this will be slow
and have different goals to our current tables.
</pre>
</blockquote>
<pre wrap=""><!---->
Agree. But current tables are just pain pain pain, when I do something like:
OpenOffice.org XML -> RML -> PDF. Then I need to do lot of magic with XSL.
And, those still ugly and unusable when somebody merges cells and/or rows...
Yes, I know, I can do complex tables with nested tables, but this is
exactly:
painLevel = pow(painLevel, painLevel)
Again, current tables are good, but only if you _know_ how your table
should look like (you write a code to render PDF, or this is a bill your code
produces or so). Instead, when you do lots XML transform from "unknown"
sources, made by who knows whom by nobody knows what rules (basically
Microsloth Word -> OpenOffice.org), than one moment you will see wrong
output... But when I do the same with HTML -- tables are just excellent
(with magic of CSS2 here/there).
</pre>
<blockquote type="cite">
<pre wrap="">It would make perfect sense to have two different kinds of tables
with different design goals.
</pre>
</blockquote>
<pre wrap=""><!---->
Agree! Besides, I haven't said: "replace that old implementation". ;-)
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Mit freundlichen Grüßen
Dirk Holtwick
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
spirito GmbH
Dirk Holtwick (CEO)
Grünstraße 6
D-47051 Duisburg
fon: +49 203 3187778
mbx: <a class="moz-txt-link-abbreviated" href="mailto:holtwick@spirito.de">holtwick@spirito.de</a>
web: <a class="moz-txt-link-freetext" href="http://www.spirito.de">http://www.spirito.de</a>
GnuPG fingerprint (<a class="moz-txt-link-freetext" href="http://www.gnupg.org">http://www.gnupg.org</a>)
A5A1 54E1 C82E 02AD 4804 0547 66F4 3FB0 C790 EBAB
</pre>
</body>
</html>
--------------020407090109070209090905--
--------------020204080307050907020206
Content-Type: application/pdf;
name="test.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="test.pdf"
JVBERi0xLjMNCiWTjIueIFJlcG9ydExhYiBHZW5lcmF0ZWQgUERGIGRvY3VtZW50IGh0dHA6
Ly93d3cucmVwb3J0bGFiLmNvbQ0KJSAnQmFzaWNGb250cyc6IGNsYXNzIFBERkRpY3Rpb25h
cnkgDQoxIDAgb2JqDQolIFRoZSBzdGFuZGFyZCBmb250cyBkaWN0aW9uYXJ5DQo8PCAvRjEg
MiAwIFINCiAvRjIgMyAwIFIgPj4NCmVuZG9iag0KJSAnRjEnOiBjbGFzcyBQREZUeXBlMUZv
bnQgDQoyIDAgb2JqDQolIEZvbnQgSGVsdmV0aWNhDQo8PCAvQmFzZUZvbnQgL0hlbHZldGlj
YQ0KIC9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQogL05hbWUgL0YxDQogL1N1YnR5cGUg
L1R5cGUxDQogL1R5cGUgL0ZvbnQgPj4NCmVuZG9iag0KJSAnRjInOiBjbGFzcyBQREZUeXBl
MUZvbnQgDQozIDAgb2JqDQolIEZvbnQgVGltZXMtUm9tYW4NCjw8IC9CYXNlRm9udCAvVGlt
ZXMtUm9tYW4NCiAvRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0KIC9OYW1lIC9GMg0KIC9T
dWJ0eXBlIC9UeXBlMQ0KIC9UeXBlIC9Gb250ID4+DQplbmRvYmoNCiUgJ1BhZ2UxJzogY2xh
c3MgUERGUGFnZSANCjQgMCBvYmoNCiUgUGFnZSBkaWN0aW9uYXJ5DQo8PCAvQ29udGVudHMg
OCAwIFINCiAvTWVkaWFCb3ggWyAwDQogIDANCiAgNTk1LjI3NTYNCiAgODQxLjg4OTggXQ0K
IC9QYXJlbnQgNyAwIFINCiAvUmVzb3VyY2VzIDw8IC9Gb250IDEgMCBSDQogIC9Qcm9jU2V0
IFsgL1BERg0KICAgL1RleHQNCiAgIC9JbWFnZUINCiAgIC9JbWFnZUMNCiAgIC9JbWFnZUkg
XSA+Pg0KIC9Sb3RhdGUgMA0KIC9UcmFucyA8PCAgPj4NCiAvVHlwZSAvUGFnZSA+Pg0KZW5k
b2JqDQolICdSNSc6IGNsYXNzIFBERkNhdGFsb2cgDQo1IDAgb2JqDQolIERvY3VtZW50IFJv
b3QNCjw8IC9PdXRsaW5lcyA5IDAgUg0KIC9QYWdlTW9kZSAvVXNlTm9uZQ0KIC9QYWdlcyA3
IDAgUg0KIC9UeXBlIC9DYXRhbG9nID4+DQplbmRvYmoNCiUgJ1I2JzogY2xhc3MgUERGSW5m
byANCjYgMCBvYmoNCjw8IC9BdXRob3IgKCkNCiAvQ3JlYXRpb25EYXRlICgyMDA0MDcwMjE1
MDcwMCkNCiAvUHJvZHVjZXIgKFJlcG9ydExhYiBodHRwOi8vd3d3LnJlcG9ydGxhYi5jb20p
DQogL1N1YmplY3QgKCkNCiAvVGl0bGUgKCkgPj4NCmVuZG9iag0KJSAnUjcnOiBjbGFzcyBQ
REZQYWdlcyANCjcgMCBvYmoNCiUgcGFnZSB0cmVlDQo8PCAvQ291bnQgMQ0KIC9LaWRzIFsg
NCAwIFIgXQ0KIC9UeXBlIC9QYWdlcyA+Pg0KZW5kb2JqDQolICdSOCc6IGNsYXNzIFBERlN0
cmVhbSANCjggMCBvYmoNCiUgcGFnZSBzdHJlYW0NCjw8IC9GaWx0ZXIgWyAvQVNDSUk4NURl
Y29kZQ0KICAvRmxhdGVEZWNvZGUgXQ0KIC9MZW5ndGggODIwID4+DQpzdHJlYW0NCkdhdUhK
OWxKTjgmQTpUVkohX0gnWG1wVXUuaFdwaj5hQGs3Pk0oLW5ERkZwR3ItVGhkQzYrUyMyVVJd
RA0KWSQvQWJvOkJTV1I2MVdjSW9RNEFvYSNKPkdsOkJnZGE2aiZaR0pzKiQvVyslblBDITlK
RWc7VGxgR3FHDQopV0BiUChnJU9qVzxjUlAlIkJOYklSY2o6OGQ3Y0BuVnUtUmc/WTY/IjEz
aGpeTCc+KSIwPDlIa3I/QlwNCmtybDRWKTNyX0FhPDU0My51U2ItPEpabSlXMERNMUV1bEE1
RTtPQydkYE1rKT0rTDA7KWtoKi5AQWlIKg0KMywhYWxNYSEtSG4lN1xSODpPOzdcQFI8bklM
IWQ0JV4rZWRMbHBiKjFuS11LIVYqWmsvY21fWkEhWUdUDQpNJDBLSS80MG8nQVAtVS4wYSte
SUpzKkRKM1BaT15DQD5qV0JGRnBDT0omQyM2T24oNCg5WjQnMzxQNmENCkovJl1dUFwhc0do
LFtHU1kja2w4QjVgdUJhOHNMLkJhYiRET0omQyNfdCNYLDlgX2I1KSg7JCJKbWxfJA0Kbk1a
ZGxfYUs8Mm9ROERNLFFLLSUpMCxeVVchRVpPTGsoYC9OJ21fRDtPMWE6V0MlXG4xaWlrNSRy
WU8mDQpLbUdaJUUvIlhjQHBobyc4UWdkSFA8WVBNaiotMzFrckAiZ0IoZiNjMTdQWS9xPUJv
Q2BvbTU9TURALFUNCjoiZE1gUGBebU1wUiw1MCtfNidXSikyTyRwdVFAVyVJaEA3UF03VlZJ
clphKEhPMlNeMmMxZmBMQF9lWg0KY0tKXElIUl5EM2BdRlBpJUQhLjptYyJKcFpYNzsoLCNg
R3EnMnMsSm9EME5CIkBMZixiU1dBZWxmIlxpDQpTOEJQTyMhIlguKkwuYCc0ZSMoXkQkUTkw
XFdmTi1naj1uJlY7YmNgR0huYXVVcklnNmNZbTQqQU8hODANCj1aa1E7YitQZCtWPTtxXS1f
S2UmbTUnWWhyI189WUhwWTkuX1RIL2NFMThBc2sxYSxpTm0jXDQ7TVQxYg0KS082LWNJaSk3
MjVRfj5lbmRzdHJlYW0NCg0KZW5kb2JqDQolICdSOSc6IGNsYXNzIFBERk91dGxpbmVzIA0K
OSAwIG9iag0KPDwgL0NvdW50IDANCiAvVHlwZSAvT3V0bGluZXMgPj4NCmVuZG9iag0KeHJl
Zg0KMCAxMA0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMTEzIDAwMDAwIG4NCjAwMDAw
MDAyMjEgMDAwMDAgbg0KMDAwMDAwMDM4NiAwMDAwMCBuDQowMDAwMDAwNTUzIDAwMDAwIG4N
CjAwMDAwMDA4NDIgMDAwMDAgbg0KMDAwMDAwMDk3NiAwMDAwMCBuDQowMDAwMDAxMTQ0IDAw
MDAwIG4NCjAwMDAwMDEyNDkgMDAwMDAgbg0KMDAwMDAwMjIxNCAwMDAwMCBuDQp0cmFpbGVy
DQo8PCAvSUQgDQogICUgUmVwb3J0TGFiIGdlbmVyYXRlZCBQREYgZG9jdW1lbnQgLS0gZGln
ZXN0IChodHRwOi8vd3d3LnJlcG9ydGxhYi5jb20pIA0KICBbKEx2OVwzNDNcMjEzXDMyM1wy
MTMrXDMwMFk+XDIzNlwwMDVcMzQ0UlwzNzIpIChMdjlcMzQzXDIxM1wzMjNcMjEzK1wzMDBZ
PlwyMzZcMDA1XDM0NFJcMzcyKV0gDQogDQogL0luZm8gNiAwIFINCiAvUm9vdCA1IDAgUg0K
IC9TaXplIDEwID4+DQpzdGFydHhyZWYNCjIyNjUNCiUlRU9GDQo=
--------------020204080307050907020206
Content-Type: text/html; charset=ISO-8859-1;
name="test.html"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="test.html"
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv
bmFsLy9FTiI+CjxodG1sPgo8aGVhZD4KPHRpdGxlPlRhYmxlIFRlc3Q8L3RpdGxlPgo8bWV0
YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1pc28tODg1OS0xIj4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KPCEtLQp0aCB7CgliYWNr
Z3JvdW5kLWNvbG9yOiAjRkZGRkNDOwp9Ci0tPgo8L3N0eWxlPgo8L2hlYWQ+Cgo8Ym9keT4K
PHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjEiPgogIDx0cj4KICAgIDx0aCByb3dzcGFu
PSI0IiBhbGlnbj0icmlnaHQiIHZhbGlnbj0idG9wIj5TcGFuIFY8L3RoPgogICAgPHRkPng8
L3RkPgogICAgPHRkPng8L3RkPgogICAgPHRkPng8L3RkPgogICAgPHRkPng8L3RkPgogIDwv
dHI+CiAgPHRyPgogICAgPHRkPng8L3RkPgogICAgPHRoIGNvbHNwYW49IjMiPlNwYW4gSDwv
dGg+CiAgPC90cj4KICA8dHI+CiAgICA8dGQ+eDwvdGQ+CiAgICA8dGQgY29sc3Bhbj0iMiIg
cm93c3Bhbj0iMiI+eHh4eDwvdGQ+CiAgICA8dGQ+eDwvdGQ+CiAgPC90cj4KICA8dHI+CiAg
ICA8dGQ+eDwvdGQ+CiAgICA8dGQ+eDwvdGQ+CiAgPC90cj4KICA8dHI+CiAgICA8dGQ+eDwv
dGQ+CiAgICA8dGQ+eDwvdGQ+CiAgICA8dGQ+eDwvdGQ+CiAgICA8dGQ+eDwvdGQ+CiAgICA8
dGQ+eDwvdGQ+CiAgPC90cj4KPC90YWJsZT4KPC9ib2R5Pgo8L2h0bWw+Cg==
--------------020204080307050907020206--