[reportlab-users] RE: reportlab-users digest, Vol 2 #140 - 4 msgs
Marc Stober
reportlab-users@reportlab.com
Tue, 22 Jun 2004 09:00:15 -0400
Hello Andy,
Just wanted to give you a vote of confidence for the switch to Subversion --
I have been using it for Python and ASP.NET (which I am doing more of now)
development and look forward to using it with ReportLab.
Thanks, Marc
-----Original Message-----
From: reportlab-users-request@reportlab.com
[mailto:reportlab-users-request@reportlab.com]
Sent: Tuesday, June 22, 2004 2:06 AM
To: reportlab-users@reportlab.com
Subject: reportlab-users digest, Vol 2 #140 - 4 msgs
Send reportlab-users mailing list submissions to
reportlab-users@reportlab.com
To subscribe or unsubscribe via the World Wide Web, visit
http://two.pairlist.net/mailman/listinfo/reportlab-users
or, via email, send a message with subject or body 'help' to
reportlab-users-request@reportlab.com
You can reach the person managing the list at
reportlab-users-admin@reportlab.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of reportlab-users digest..."
Today's Topics:
1. Unicode, subversion and Version 2.0 (Andy Robinson)
2. Re: Unicode, subversion and Version 2.0 (Bogdan M. Maryniuck)
3. Re: Unicode, subversion and Version 2.0 (andy@reportlab.com)
4. Re: Unicode, subversion and Version 2.0 (Bogdan M. Maryniuck)
--__--__--
Message: 1
From: "Andy Robinson" <andy@reportlab.com>
To: "Reportlab-Users@Reportlab. Com" <reportlab-users@reportlab.com>
Date: Mon, 21 Jun 2004 10:15:06 +0100
Subject: [reportlab-users] Unicode, subversion and Version 2.0
Reply-To: reportlab-users@reportlab.com
3 important notices...
Subversion Switchover
=====================
Here is a very belated update on our subversion switch,
which we originally wanted to do in May. (For those who
missed the chat, we are moving to a new version control
system).
It turned out to be quite hard creating a tool to move across
our repositories and to configure it right, and we found a few
security holes we needed to plug. Took about five
weeks. We then decided we should develop against it for a
few weeks as "User Acceptance Testing" before making an irrevocable
switch, which we are now doing. It looks good so far although
it does have its quirks. We're doing some work on our SVN
reportlab repository now, without the added burden of external users
but you'll see the cumulative changes soon in SVN or CVS.
If all goes well we will publish access details in the first few
days of July, and mark the CVS tree as "dormant" (i.e disable all
SF checkins, maybe rename __init__.py so it's unusable, and add a large
readme saying where it moved). In the next ten days have a customer
deadline so it has to wait until after then.
Overall it's clearly a nicer system.
Unicode
=======
We had to get some emergency Unicode patches in place for a customer
last month (basically, accepting UTF8 in RML and auto-converting to
the relevant font on output). We managed it, but it's hacky with
suboptimal performance. Having started this, there is basically
no going back; some old (and arguably wrong) behaviours have to be broken
and we have to move to Unicode internally in platypus and RML. So, I am
going to treat this as "the road to Version 2.0".
When the new repository is publicly up, the first thing we will do is
make a 'stable branch', with a 1.19.x named release, and attempt to
maintain bug fixes on this for a while.
The trunk will then be a 'pre version 2', which currently runs but
may bite you on things like bullet characters from time to time.
Version 2.0
===========
This fixes the scope nicely for Version 2.0. We also have a joint
project on with a local university this summer on a better system
for authoring documentation, so the two driving forces will be
"unicode" and "better documentation". Rough goal is "this summer".
In scope:
- Unicode internally where possible
- clean up font registration, families and caching
- remove old xmllib-based paraparser and ensure that
- lots more test cases
- defined what's the public API and what's private
- new system for documentation authoring
- better packaging and deployment
Deferred (i.e. "version 3.0":
- changes to layout or paragraph algorithm
- merge of graphics and platypus
Things which may change:
- anyone doing very specific hackery with
That's my rough plan. Comments welcome. Volunteers welcome too
(after July 1st). Take it with a large pinch of salt as usual and
disregard any target dates until you see it happening ;-)
- Andy
Andy Robinson
CEO/Chief Architect
ReportLab Europe Ltd.
mobile +44-7976-355742
office +44-20-8544-8049
--__--__--
Message: 2
Date: Mon, 21 Jun 2004 14:30:16 +0300
To: "Reportlab-Users@Reportlab. Com" <reportlab-users@reportlab.com>
Subject: Re: [reportlab-users] Unicode, subversion and Version 2.0
From: bo@bitute.b4net.lt (Bogdan M. Maryniuck)
Reply-To: reportlab-users@reportlab.com
On Mon, Jun 21, 2004 at 10:15:06AM +0100, Andy Robinson wrote:
> Comments welcome.
Unicode -- is what all RL users are waiting for. ;-)
But if somebody would like to implement correct Platypus Table
cellspan without overpainting vertical lines from other cells
above/below and correctly recalculate rowheight while textwrapped
paragraph is in the cell, than it would be really nice.
P.S. Ah, and table split vertically (currently there is just
NonImplemented error)...
--
aes(r)
How much net work could a network work, if a network could net work?
--__--__--
Message: 3
Date: Mon, 21 Jun 2004 06:34:27 -0700
From: <andy@reportlab.com>
Subject: Re: [reportlab-users] Unicode, subversion and Version 2.0
To: reportlab-users@reportlab.com
Reply-To: reportlab-users@reportlab.com
Bogdan M. Maryniuck <bo@bitute.b4net.lt> wrote:
> Unicode -- is what all RL users are waiting for. ;-)
> But if somebody would like to implement correct Platypus Table
> cellspan without overpainting vertical lines from other cells
> above/below and correctly recalculate rowheight while textwrapped
> paragraph is in the cell, than it would be really nice.
It would be nice, but logically it's not critical and can be done
separately
at any time. We would do it if a commercial RML customer had a need,
but this has never caused us any trouble. So, I'd say we are waiting
for a volunteer or volunteers to roll their sleeves up and work on it
:-)
IMHO a full HTML-like table rendering algorithm like this will be slow
and have
different goals to our current tables. It would make perfect sense to
have
two different kinds of tables with different design goals.
--__--__--
Message: 4
Date: Mon, 21 Jun 2004 17:14:44 +0300
To: reportlab-users@reportlab.com
Subject: Re: [reportlab-users] Unicode, subversion and Version 2.0
From: bo@bitute.b4net.lt (Bogdan M. Maryniuck)
Reply-To: reportlab-users@reportlab.com
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". ;-)
--
aes(r)
If you are angry with someone, you should walk a mile in their shoes... then
you'll be a mile away from them, and you'll have their shoes.
--__--__--
_______________________________________________
reportlab-users mailing list
reportlab-users@reportlab.com
http://two.pairlist.net/mailman/listinfo/reportlab-users
End of reportlab-users Digest