[reportlab-users] Reportlab issue list
Claude Paroz
From the bitbucket leave, I wasn't able to find the new location for
seeing/reporting Reportlab issues. Could you please point us to that new
location?
Regards,
Claude
--
www.2xlibre.net
_______________________________________________
reportlab-users mailing list
reportl...@lists2.reportlab.com
https://pairlist2.pair.net/mailman/listinfo/reportlab-users
Robin Becker
> There was such a list at https://bitbucket.org/rptlab/issues
> Do you tell us that this list has been deleted without backup anywhere?
>
I did not decide to remove support for the bitbucket area that was done by another agent.
> > For best results ...
>
> Do you mean that a mailing list is replacing an issue list, and that it's better to manage issues?
>
yes a mailing list is better. It gives others a chance to discuss / contribute if they wish to and serves as bug
reporter, issues list and discussion forum all in one place.
At some point we'll probably be forced to move to github and use an inferior VCS which has all the web based features.
> Claude
>
.......
--
Robin Becker
Claude Paroz
> 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?
>>
>
> I did not decide to remove support for the bitbucket area that was done
> by another agent.
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
>> > For best results ...
>>
>> Do you mean that a mailing list is replacing an issue list, and that
>> it's better to manage issues?
>>
> yes a mailing list is better. It gives others a chance to discuss /
> contribute if they wish to and serves as bug reporter, issues list and
> discussion forum all in one place.
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?
> At some point we'll probably be forced to move to github and use an
> inferior VCS which has all the web based features.
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.
If you were to decide to use Git at some point and need help, feel free
to ask. I'm no expert but maybe I could still help.
Claude
Robin Becker
> 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
>
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
Claude Paroz
> On 16/01/2021 20:15, Claude Paroz wrote:
>> 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.
I'll see if I can ask Atlassian to get an archive of those.
>> ............
>> 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 :)
Ha, ha, ha, indeed!!
> 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.
It would be a step forward, even if it's only for PDF rendering.
Claude
Robin Becker
>>
>> I think that's doable with a small change in renderPDF.py; whether it is feasable in renderPS / renderPM I don't know.
>
> It would be a step forward, even if it's only for PDF rendering.
>
> Claude
>
I have some code that might be worth testing to see if it will work for your purposes. Effectively I have the String
class with an extra attribute textRenderMode as oneof 0,1,2,3,4,5,6,7. This follows the PDF canvas drawString mechanism.
I have modified as well the src/reportlab/graphics/renderPDF/PM/PS.py modules to do the right thing(s). I am not certain
I know about modes >3 in postscript, but I have have done enough in the PM backend with changes in
src/rl_addons/renderPM/_renderPM.c. I haven't done anything on the renderSVG front.
I will check these in on a branch to avoid problems on the trunk if it's all wrong or just supply a patch if that's what
you need for testing.
#So this works for PDF, PNG & PS output
#Autogenerated by ReportLab guiedit do not edit
from reportlab.graphics.shapes import Drawing, _DrawingEditorMixin, String, Line, Path, definePath
from reportlab.lib.colors import blue, red, green, yellow
from os import environ
class Drawing_000(_DrawingEditorMixin,Drawing):
def __init__(self,width=400,height=200,*args,**kw):
Drawing.__init__(self,width,height,*args,**kw)
trm = int(environ.get('TRM','2'))
self._add(self,String(70,10,'text',fontSize=80,fontName='Helvetica',fillColor=blue,strokeColor=red,
strokeWidth=1.5,textRenderMode=trm),name='S0',validate=None,desc=None)
self._add(self,Line(40,40,70,70,strokeWidth=0.5,strokeColor=green),name='L0',validate=None,desc=None)
self._add(self,definePath([('moveTo',80,80),('lineTo',110,110),
('lineTo',80,110),'closePath'],fillColor=None,strokeWidth=2,strokeColor=yellow),
name='P0',validate=None,desc=None)
if __name__=="__main__": #NORUNTESTS
Drawing_000().save(formats=['pdf','png', 'ps'],outDir='.',fnRoot=None)
I guess svglib could leverage this to fix your issue.
--
Robin Becker
Robin Becker
At any rate I have checked in and published version 3.5.60 which addresses the issue regarding stroking and drawing
text. I'm almost certain it has broken the text clipping functionality, but it does seem to work for stroking+filling,
stroking alone and filling alone the last being the default.
--
Robin Becker
Claude Paroz
> Hi Claude, well done regarding the issue list. I didn't manage to
> discover an easy way to display it though.
Sure, the content is not meant to be read by humans. My hope now is that
you choose a new ticket system for Reportlab, and then I'll gladly help
to convert the current JSON archive to the new system (provided it has
some open API).
> At any rate I have checked in and published version 3.5.60 which
> addresses the issue regarding stroking and drawing text. I'm almost
> certain it has broken the text clipping functionality, but it does seem
> to work for stroking+filling, stroking alone and filling alone the last
> being the default.
Thanks a lot! I'll update the ticket on svglib.
Claude
--
www.2xlibre.net
Claude Paroz
> addresses the issue regarding stroking and drawing text. I'm almost
> certain it has broken the text clipping functionality, but it does seem
> to work for stroking+filling, stroking alone and filling alone the last
> being the default.
The renderPM part of 3.5.60 seems to be broken now. In another related
project, the resulting images are bad (many artifacts) and the rendering
does output many "x_order_2: colinear!" lines.
I don't know if it's due to this change.
Claude
--
www.2xlibre.net
Robin Becker
thanks for the exampl; your png looks awful :(
I just ran this on my machine using the thirdparty version of svglib we have in rlextra and the png output looks fine. I
think this svglib was last synced at with 0.8.1, but changes were made last in 2018/11/15
So
1) what version of svglib are you using? I can then replicate almost surely.
2) I attach the result of running my svglib to produce a python file which represents exactly which rl graphics ops are
being used, claude-example.py; when I run it I see a good png.
3) Can you try to produce a python output with your svglib. Direct comparison with mine will show where the svglib is
producing differences.
4) Also what OS, python versions are being used? I am using python 3.9.1 archlinux x86_amd64.
On 26/01/2021 15:48, Claude Paroz wrote:
> Le 26.01.21 à 14:48, Robin Becker a écrit :
>>> Le 22.01.21 à 14:59, Robin Becker a écrit :
>>>> At any rate I have checked in and published version 3.5.60 which addresses the issue regarding stroking and drawing
>>>> text. I'm almost certain it has broken the text clipping functionality, but it does seem to work for
>> easier. If unable to find what's wrong I will just revert all the changes.
>
> You can reproduce it by running the example code of:
> https://github.com/claudep/swiss-qr-bill#outputting-as-pdf-or-bitmap
>
> Hereby a sample SVG, and the renderPM output with ReportLab 3.5.59 and 3.5.60.
>
> Regards,
>
> Claude
--
Robin Becker
Robin Becker
changes in 3.5.60 was to actually set the passed value of fixMode and it seems that although that works for pdf it
doesn't work for renderPM.
Obviously the _renderPM.c code for this case is busted, libart_lgpl is very old and no-one is ever going to fix or
explain it.
Not sure how this will be fixed as setting in Path fixed a filling bug in PDF
On 26/01/2021 15:48, Claude Paroz wrote:
> Le 26.01.21 à 14:48, Robin Becker a écrit :
>> On 26/01/2021 08:57, Claude Paroz wrote:
............
> You can reproduce it by running the example code of:
> https://github.com/claudep/swiss-qr-bill#outputting-as-pdf-or-bitmap
>
> Hereby a sample SVG, and the renderPM output with ReportLab 3.5.59 and 3.5.60.
>
> Regards,
>
> Claude
--
Robin Becker