[reportlab-users] Reportlab issue list

Robin Becker robin at reportlab.com
Sat Jan 16 16:16:53 EST 2021

On 16/01/2021 20:15, Claude Paroz wrote:
> Le 16.01.21 à 20:54, Robin Becker a écrit :
>> On 16/01/2021 19:31, Claude Paroz wrote:
>>> There was such a list at https://bitbucket.org/rptlab/issues
>>> Do you tell us that this list has been deleted without backup anywhere?
> Sorry Robin, this was not meant as a personal accusation. It's not against you, but I find it a bit rough to simply 
> erase existing tickets, considering the benevolent time spent by many contributors to write them. This move might be 
> interpreted as if you don't care about their efforts trying to improve Reportlab.
> Maybe it's not too late to ask bitbucket for a backup of those ticket data?
> Typically, I'd like to read reportlab issue #185 mentioned in this thread:
> https://github.com/deeplook/svglib/issues/193
no offence was taken, I oroginally thought they (Atlassian) would just freeze everything; they gave us a while and then 
removed everything. I missed it and probably wouldn't know how to copy the issues/bugs anyway.

> Mmmmh, this sounds again a bit awkward :-) You know that 99% of open source projects have issue lists, on which anyone 
> can also discuss and contribute if they wish. For example, with a mailing list, how can you keep track of the status of 
> reported issues? Browsing each mailing list thread one by one to know if the discussed issue is resolved or not?
Let 100 flowers bloom :)

> Each VCS has strong and weaker features, and when you are accustomed to one VCS, it's always difficult to change habits. 
> I can tell you that I'm suffering when I have to use Mercurial, not because it is inferior to any other VCS, but simply 
> because I rarely use it. So you can tell that you prefer using this VCS over that one, but telling that one is superior 
> or inferior can sound a bit pretentious.
.........I have used aboout 5 VCS'es and mercurial is by far the most simple. I think git has too many ways to mess up.

Anyhow from your issue 193 I think you just want to allow the graphics strings to have stroke properties (at least in PDF).

I think that's doable with a small change in renderPDF.py; whether it is feasable in renderPS / renderPM I don't know.
Robin Becker

More information about the reportlab-users mailing list