pythonreports-devel Mailing List for PythonReports
Brought to you by:
a1s
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(6) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Alexey L. <lu...@an...> - 2011-11-10 16:08:18
|
http://pypi.python.org/pypi/Python-fontconfig/ -- Луч |
From: SourceForge.net <no...@so...> - 2007-12-22 15:19:43
|
Bugs item #1856408, was opened at 2007-12-23 02:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896376&aid=1856408&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bruce Schultz (halfcat) Assigned to: Nobody/Anonymous (nobody) Summary: Update SYSFONTPATH for Ubuntu Initial Comment: On Ubuntu (Feisty), the builder can't find arial.ttf. The fonts are installed in /usr/share/fonts/truetype/msttcorefonts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896376&aid=1856408&group_id=181233 |
From: SourceForge.net <no...@so...> - 2007-12-09 08:28:28
|
Feature Requests item #1846878, was opened at 2007-12-08 17:06 Message generated for change (Comment added) made by a1s You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1846878&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Format specifications Group: None Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Bruce Schultz (halfcat) Assigned to: Nobody/Anonymous (nobody) Summary: Group header replicated on each new page Initial Comment: Currently the group title element is only printed once, at the top of the group. If the group is split across a page or column break, it should be possible to optionally reproduce the title on the new page (or column). Maybe this could be done by allowing the <header> element to be used within a group. Also it would be useful to be able to determine inside the header if it is the first or a subsequent group header, so that some indication of continuation can be printed. (eg a field to print continued using a 'printwhen' style to disable it on the first header, at the top of the group). ---------------------------------------------------------------------- >Comment By: alexander smishlajev (a1s) Date: 2007-12-09 10:28 Message: Logged In: YES user_id=8719 Originator: NO i think the following could work: each element in report template gets an optional attribute 'id'. all non-empty ids must be unique across the template. (this is required by FR 1611603 also.) new element type is added to all section elements: <link target="whatever">, where the 'target' attribute refers to existing id of another template element (section element or body element). the 'link' element may contain one 'box' element, overriding the target box, and a sequence of 'style' elements, combined with the target styles (preceding them). if link target is a section, it's eject specifications are ignored. PythonReports builder in it's constructor makes a private copy of the template, and unrolls all links by copying their targets in place. during this operation we should check for autorecursion. perhaps the Section class will need to be modified to allow embedded sections. patches are welcome. ---------------------------------------------------------------------- Comment By: Bruce Schultz (halfcat) Date: 2007-12-08 18:34 Message: Logged In: YES user_id=784165 Originator: YES Ok, thanks. That solution works, and my only gripe now is that I have to duplicate fields in the page header that are already in the group title, but I can live with that. ---------------------------------------------------------------------- Comment By: alexander smishlajev (a1s) Date: 2007-12-08 17:17 Message: Logged In: YES user_id=8719 Originator: NO page and column headings are meant to be fully described by the 'header' elements. you can use <group>_COUNT variable to conditionally skip parts of the header in the middle of a group. i am closing this request now. if the above technique does not work for you, please reopen the issue with example (data and template) demonstrating your problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1846878&group_id=181233 |
From: SourceForge.net <no...@so...> - 2007-12-08 16:36:38
|
Feature Requests item #1846878, was opened at 2007-12-09 02:06 Message generated for change (Comment added) made by halfcat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1846878&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Format specifications Group: None >Status: Open Resolution: Rejected Priority: 5 Private: No Submitted By: Bruce Schultz (halfcat) Assigned to: Nobody/Anonymous (nobody) Summary: Group header replicated on each new page Initial Comment: Currently the group title element is only printed once, at the top of the group. If the group is split across a page or column break, it should be possible to optionally reproduce the title on the new page (or column). Maybe this could be done by allowing the <header> element to be used within a group. Also it would be useful to be able to determine inside the header if it is the first or a subsequent group header, so that some indication of continuation can be printed. (eg a field to print continued using a 'printwhen' style to disable it on the first header, at the top of the group). ---------------------------------------------------------------------- >Comment By: Bruce Schultz (halfcat) Date: 2007-12-09 03:34 Message: Logged In: YES user_id=784165 Originator: YES Ok, thanks. That solution works, and my only gripe now is that I have to duplicate fields in the page header that are already in the group title, but I can live with that. ---------------------------------------------------------------------- Comment By: alexander smishlajev (a1s) Date: 2007-12-09 02:17 Message: Logged In: YES user_id=8719 Originator: NO page and column headings are meant to be fully described by the 'header' elements. you can use <group>_COUNT variable to conditionally skip parts of the header in the middle of a group. i am closing this request now. if the above technique does not work for you, please reopen the issue with example (data and template) demonstrating your problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1846878&group_id=181233 |
From: SourceForge.net <no...@so...> - 2007-12-08 15:17:31
|
Feature Requests item #1846878, was opened at 2007-12-08 17:06 Message generated for change (Comment added) made by a1s You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1846878&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Format specifications Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Bruce Schultz (halfcat) Assigned to: Nobody/Anonymous (nobody) Summary: Group header replicated on each new page Initial Comment: Currently the group title element is only printed once, at the top of the group. If the group is split across a page or column break, it should be possible to optionally reproduce the title on the new page (or column). Maybe this could be done by allowing the <header> element to be used within a group. Also it would be useful to be able to determine inside the header if it is the first or a subsequent group header, so that some indication of continuation can be printed. (eg a field to print continued using a 'printwhen' style to disable it on the first header, at the top of the group). ---------------------------------------------------------------------- >Comment By: alexander smishlajev (a1s) Date: 2007-12-08 17:17 Message: Logged In: YES user_id=8719 Originator: NO page and column headings are meant to be fully described by the 'header' elements. you can use <group>_COUNT variable to conditionally skip parts of the header in the middle of a group. i am closing this request now. if the above technique does not work for you, please reopen the issue with example (data and template) demonstrating your problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1846878&group_id=181233 |
From: SourceForge.net <no...@so...> - 2007-12-08 15:06:09
|
Feature Requests item #1846878, was opened at 2007-12-09 02:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1846878&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Format specifications Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bruce Schultz (halfcat) Assigned to: Nobody/Anonymous (nobody) Summary: Group header replicated on each new page Initial Comment: Currently the group title element is only printed once, at the top of the group. If the group is split across a page or column break, it should be possible to optionally reproduce the title on the new page (or column). Maybe this could be done by allowing the <header> element to be used within a group. Also it would be useful to be able to determine inside the header if it is the first or a subsequent group header, so that some indication of continuation can be printed. (eg a field to print continued using a 'printwhen' style to disable it on the first header, at the top of the group). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1846878&group_id=181233 |
From: SourceForge.net <no...@so...> - 2007-12-07 11:27:46
|
Bugs item #1846113, was opened at 2007-12-07 22:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896376&aid=1846113&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Report building Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bruce Schultz (halfcat) Assigned to: Nobody/Anonymous (nobody) Summary: XML entity references are not encoded Initial Comment: I have a record in my database which has an ampersand character '&' in it. Building the report seems to go ok, but when parsing the report for printing, it throws an exception. If I manually change the & to & in the .prp file, it parses ok. I think the solution is to make sure that the XML is correctly escaped, and I'm attaching a patch which does that. The exception which got thrown in the parser when generating the pdf: Traceback (most recent call last): File "PythonReports/pdf.py", line 435, in ? run() File "PythonReports/pdf.py", line 432, in run write(_printout, _pdf) File "PythonReports/pdf.py", line 420, in write PdfWriter(report).write(filepath) File "PythonReports/pdf.py", line 68, in __init__ self.report = prp.load(report) File "/home/bruce/projects/pythonreports/PythonReports-0.3.1/PythonReports/printout.py", line 131, in load _et.parse(source) File "/home/bruce/projects/pythonreports/PythonReports-0.3.1/PythonReports/datatypes.py", line 1233, in parse _root = ET.ElementTree.parse(self, source, parser) File "<string>", line 32, in parse SyntaxError: not well-formed (invalid token): line 3869, column 38 Line 3869 in the .prp was a <data> element which contained the '&' in it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896376&aid=1846113&group_id=181233 |
From: alexander s. <al...@ty...> - 2007-08-24 05:02:10
|
Michael Hipp wrote, at 23.08.2007 16:03: > Hello, just "discovered" PythonReports. Looks good. Well thought out. thank you. > Question #1: What is the project status? Is it alive and well? i think so. i don't use PythonReports myself just now, but as far as i know my other colleagues do, and i didn't get any problem reports since last release. > Question #2: Is this fixable? (from wxPrint.py) > > """wxPython print classes > > Warning: this module is malfunctional. Print preview is badly broken > due to wxDC limitations. Printer output may be broken too. > > """ > > Or is it a a limitation of wxWidgets/MSW that can't be overcome? i cannot find the solution, if there is any. i don't think the fix is possible at the python side, but i don't want to be categorical about it. the problem with print preview is that the relative size of the text strings varies with zoom level change. i heard that someone worked around it by disabling the zoom, but, of course, that is not a solution. the problem is not specific to the windows platform; wxGTK acts in the same way. besides, the bar code rendering is badly broken. the display is quite astounding, and i have absolutely no idea what's happening. i have tried several different approaches to work around that (including Blit()ing of a correct bitmap to the output DC), but none of them resulted in satisfactory output. > Question #3: Are contributions from outsiders welcome? yes. contributions to either project design, the code, or - especially - the documentation are welcome. warn you, however, that the patches are probable to be edited before applying. best wishes, alex. |
From: Michael H. <Michael@Hipp.com> - 2007-08-23 13:02:04
|
Hello, just "discovered" PythonReports. Looks good. Well thought out. Question #1: What is the project status? Is it alive and well? Question #2: Is this fixable? (from wxPrint.py) """wxPython print classes Warning: this module is malfunctional. Print preview is badly broken due to wxDC limitations. Printer output may be broken too. """ Or is it a a limitation of wxWidgets/MSW that can't be overcome? Question #3: Are contributions from outsiders welcome? Thank you, Michael Hipp Heber Springs, Arkansas, USA |
From: SourceForge.net <no...@so...> - 2006-12-08 16:23:23
|
Feature Requests item #1611603, was opened at 2006-12-08 18:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1611603&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Format specifications Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: alexander smishlajev (a1s) Assigned to: Nobody/Anonymous (nobody) Summary: linked boxes for body elements Initial Comment: some of the printable elements in report templates would not have their own box definitions but instead use boxes from another printable elements of the same section. use case: rectangle drawn around a text field with aut-sized box. solution: each element in report template gets an optional attribute "id". all non-empty ids must be unique across the template. box elements get an optional attribute "refid". if refid is set, it's value must be an id of another box element in the same report section. for such boxes, all attributes except id and refid are ignored, and controlled element will be laid out using position and size of the referred box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1611603&group_id=181233 |
From: SourceForge.net <no...@so...> - 2006-11-07 15:31:21
|
Feature Requests item #1592008, was opened at 2006-11-07 15:51 Message generated for change (Comment added) made by a1s You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1592008&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Format specifications Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Oleg Deribas (older) Assigned to: Nobody/Anonymous (nobody) Summary: Report Definition Language Specification Initial Comment: As PythonReports use XML for report storage, maybe it is better to support MS Report Definition Language Specification instead of inventing its own format? It would allow some interoperability with other implementations of this specification. ---------------------------------------------------------------------- >Comment By: alexander smishlajev (a1s) Date: 2006-11-07 17:31 Message: Logged In: YES user_id=8719 glad you asked. RDL was one of the specs i browsed through when i was working on PRT specification. the problem with RDL is that it includes quite a fiew things that are of no interest to PythonReports. if you look at figure 1 of the RDL specifications document you can see that nearly half of it is dedicated to data activities: fetching, filtering and sorting your report data set. i do not need things like that personally (my application is working on object-oriented database model), and it is my strong opinion that such activities lay out of PythonReports scope: it is easier and much more convenient to prepare report data with Python code than to learn Yet Another Data Manipulation Language. you may also use third party tools to automate data retrieval if you wish. besides, i didn't catch on to the visual model of Report Definition Language. it seems to be a bit overblown and on the other hand somewhat difficult to implement primitive reporting operations like data grouping and totals calculations. all in all i wouldn't be able to implement this specification. on the other hand, PRT is exactly what has been implemented. i did my best to make it easy to comprehend, especially if you have some experience with existing database reporting tools, windows- and java-based. there still remain some grey areas i'd like to discuss with interested people, but i'm quite happy with what it is already. and finally, i believe that you can make PRT from RDL with more or less straightforward XML transformation. ---------------------------------------------------------------------- Comment By: Oleg Deribas (older) Date: 2006-11-07 15:53 Message: Logged In: YES user_id=281684 Sorry, forgot to mention that Report Definition Language Specification is freely available at http://www.microsoft.com/sql/technologies/reporting/rdlspec.mspx ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1592008&group_id=181233 |
From: SourceForge.net <no...@so...> - 2006-11-07 13:53:29
|
Feature Requests item #1592008, was opened at 2006-11-07 15:51 Message generated for change (Comment added) made by older You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1592008&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Format specifications Group: None Status: Open Priority: 5 Private: No Submitted By: Oleg Deribas (older) Assigned to: Nobody/Anonymous (nobody) Summary: Report Definition Language Specification Initial Comment: As PythonReports use XML for report storage, maybe it is better to support MS Report Definition Language Specification instead of inventing its own format? It would allow some interoperability with other implementations of this specification. ---------------------------------------------------------------------- >Comment By: Oleg Deribas (older) Date: 2006-11-07 15:53 Message: Logged In: YES user_id=281684 Sorry, forgot to mention that Report Definition Language Specification is freely available at http://www.microsoft.com/sql/technologies/reporting/rdlspec.mspx ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1592008&group_id=181233 |
From: SourceForge.net <no...@so...> - 2006-11-07 13:51:56
|
Feature Requests item #1592008, was opened at 2006-11-07 15:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1592008&group_id=181233 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Format specifications Group: None Status: Open Priority: 5 Private: No Submitted By: Oleg Deribas (older) Assigned to: Nobody/Anonymous (nobody) Summary: Report Definition Language Specification Initial Comment: As PythonReports use XML for report storage, maybe it is better to support MS Report Definition Language Specification instead of inventing its own format? It would allow some interoperability with other implementations of this specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=896379&aid=1592008&group_id=181233 |