From: Matt K. <mat...@gm...> - 2011-10-19 11:35:17
|
Hi, Attempting to write a custom Descendant Report with my preferred output to date being ODF. However I'm seeing an issue where alignment is somewhat out because ODF start_paragraph method by default puts a tab white space after the leader (typically numbering system), if the leader is present. I'd like some means of overriding this tab to be a simple space instead., the two most obvious means to achieve this are : 1. Change the default behaviour in plugins/docgen/ODFDoc.py:start_paragraph() to simply print space instead of TAB - self.cntnt.write(leader + '<text:tab/>') + self.cntnt.write(leader + '<text: />') This would change the default behaviour for all ODF documents produced, which admittedly I feel would most likely not suit everybody. 2. Provided a new optional paramater to the start_paragraph() method, allowing for the custom provision of a leader_suffix e.g. Index: plugins/docgen/ODFDoc.py =================================================================== --- plugins/docgen/ODFDoc.py (revision 18351) +++ plugins/docgen/ODFDoc.py (working copy) @@ -1473,7 +1473,7 @@ """ self.cntnt.write('</text:p>\n') - def start_paragraph(self, style_name, leader=None): + def start_paragraph(self, style_name, leader=None, leader_suffix=None): """ open a new paragraph """ @@ -1493,7 +1493,10 @@ ' text:outline-level="%s">' % str(self.level) ) if leader is not None: - self.cntnt.write(leader + '<text:tab/>') + if leader_suffix is not None: + self.cntnt.write(leader + '<text:%s/>' % (str(leader_suffix))) + else: + self.cntnt.write(leader + '<text:tab/>') self.new_cell = 0 In testing this works nicely for me, however changing this just ind ODFDoc.py would not be right, ideally it would have to be added everywhere in gramps where start_paragraph() is defined, which in trunk is currently : gen/plug/docgen/textdoc.py plugins/docgen/HtmlDoc.py plugins/docgen/AsciiDoc.py plugins/docgen/ODFDoc.py plugins/docgen/RTFDoc.py plugins/docgen/LaTeXDoc.py plugins/lib/libcairodoc.py docgen/TextBufDoc.py Wanted to ping the devel list to see if there is a better solution to my conundrum... thoughts ? Matt -- HH Golf Society www.hh-gs.com IFLAF www.iflaf.com |
From: Doug B. <dou...@gm...> - 2011-10-19 11:53:46
|
On Wed, Oct 19, 2011 at 7:35 AM, Matt Keenan <mat...@gm...> wrote: > Hi, > > Attempting to write a custom Descendant Report with my preferred > output to date being ODF. > > However I'm seeing an issue where alignment is somewhat out because > ODF start_paragraph method by default puts a tab white space after > the leader (typically numbering system), if the leader is present. > > I'd like some means of overriding this tab to be a simple space > instead., the two most obvious means to achieve this are : > > 1. Change the default behaviour in > plugins/docgen/ODFDoc.py:start_paragraph() to simply print space > instead of TAB > > - self.cntnt.write(leader + '<text:tab/>') > + self.cntnt.write(leader + '<text: />') > > This would change the default behaviour for all ODF documents > produced, which admittedly I feel would most likely not > suit everybody. > > > 2. Provided a new optional paramater to the start_paragraph() method, > allowing for the custom provision of a leader_suffix > e.g. > > Index: plugins/docgen/ODFDoc.py > =================================================================== > --- plugins/docgen/ODFDoc.py (revision 18351) > +++ plugins/docgen/ODFDoc.py (working copy) > @@ -1473,7 +1473,7 @@ > """ > self.cntnt.write('</text:p>\n') > > - def start_paragraph(self, style_name, leader=None): > + def start_paragraph(self, style_name, leader=None, leader_suffix=None): > """ > open a new paragraph > """ > @@ -1493,7 +1493,10 @@ > ' text:outline-level="%s">' % str(self.level) > ) > if leader is not None: > - self.cntnt.write(leader + '<text:tab/>') > + if leader_suffix is not None: > + self.cntnt.write(leader + '<text:%s/>' % > (str(leader_suffix))) > + else: > + self.cntnt.write(leader + '<text:tab/>') > self.new_cell = 0 > > > In testing this works nicely for me, however changing this just ind > ODFDoc.py would not be right, ideally it would have > to be added everywhere in gramps where start_paragraph() is defined, > which in trunk is currently : > > gen/plug/docgen/textdoc.py > plugins/docgen/HtmlDoc.py > plugins/docgen/AsciiDoc.py > plugins/docgen/ODFDoc.py > plugins/docgen/RTFDoc.py > plugins/docgen/LaTeXDoc.py > plugins/lib/libcairodoc.py > docgen/TextBufDoc.py > > Wanted to ping the devel list to see if there is a better solution to > my conundrum... > > thoughts ? Yes, I think that an override for a particular paragraph is appropriate. It could also be an override that could change any element of the style. For example, some pseudo code: def start_paragraph(self, style_name, **kwargs): style = styles.get_draw_style(style_name) for key in kwargs: setattr(style, key, kwargs[key]) I have no idea if leader, nor leader_suffix are part of the style. But if they were/are, and we add a kwargs option, then one could override any aspect of the start_*() or write_*() methods. If you want to change the paragraph start for all paragraphs, though, it seems that this should just be a style element that you change once. I have no idea of the internals of this... just thinking out loud, and hoping that we don't have to keep adding additional arguments to override different aspects of each start/write. -Doug > Matt > > -- > HH Golf Society > www.hh-gs.com > > IFLAF > www.iflaf.com > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2011-10-19 13:23:51
|
Is this not already possible playing with the indent of the paragraph in the style editor? Eg indent -0.5. Anyway, changing start_paragraph is not ok, as that is the document API, so ODFdoc should leave it alone. You should add something to style instead if this cannot be globally changed. Serge, as main ODF author, what do you think? Is that tab there the correct way of handling this? I assume the idea is that 1 and 100 have a tab, so the text starts at the same position? Benny 2011/10/19 Doug Blank <dou...@gm...> > On Wed, Oct 19, 2011 at 7:35 AM, Matt Keenan <mat...@gm...> > wrote: > > Hi, > > > > Attempting to write a custom Descendant Report with my preferred > > output to date being ODF. > > > > However I'm seeing an issue where alignment is somewhat out because > > ODF start_paragraph method by default puts a tab white space after > > the leader (typically numbering system), if the leader is present. > > > > I'd like some means of overriding this tab to be a simple space > > instead., the two most obvious means to achieve this are : > > > > 1. Change the default behaviour in > > plugins/docgen/ODFDoc.py:start_paragraph() to simply print space > > instead of TAB > > > > - self.cntnt.write(leader + '<text:tab/>') > > + self.cntnt.write(leader + '<text: />') > > > > This would change the default behaviour for all ODF documents > > produced, which admittedly I feel would most likely not > > suit everybody. > > > > > > 2. Provided a new optional paramater to the start_paragraph() method, > > allowing for the custom provision of a leader_suffix > > e.g. > > > > Index: plugins/docgen/ODFDoc.py > > =================================================================== > > --- plugins/docgen/ODFDoc.py (revision 18351) > > +++ plugins/docgen/ODFDoc.py (working copy) > > @@ -1473,7 +1473,7 @@ > > """ > > self.cntnt.write('</text:p>\n') > > > > - def start_paragraph(self, style_name, leader=None): > > + def start_paragraph(self, style_name, leader=None, > leader_suffix=None): > > """ > > open a new paragraph > > """ > > @@ -1493,7 +1493,10 @@ > > ' text:outline-level="%s">' % str(self.level) > > ) > > if leader is not None: > > - self.cntnt.write(leader + '<text:tab/>') > > + if leader_suffix is not None: > > + self.cntnt.write(leader + '<text:%s/>' % > > (str(leader_suffix))) > > + else: > > + self.cntnt.write(leader + '<text:tab/>') > > self.new_cell = 0 > > > > > > In testing this works nicely for me, however changing this just ind > > ODFDoc.py would not be right, ideally it would have > > to be added everywhere in gramps where start_paragraph() is defined, > > which in trunk is currently : > > > > gen/plug/docgen/textdoc.py > > plugins/docgen/HtmlDoc.py > > plugins/docgen/AsciiDoc.py > > plugins/docgen/ODFDoc.py > > plugins/docgen/RTFDoc.py > > plugins/docgen/LaTeXDoc.py > > plugins/lib/libcairodoc.py > > docgen/TextBufDoc.py > > > > Wanted to ping the devel list to see if there is a better solution to > > my conundrum... > > > > thoughts ? > > Yes, I think that an override for a particular paragraph is > appropriate. It could also be an override that could change any > element of the style. For example, some pseudo code: > > def start_paragraph(self, style_name, **kwargs): > style = styles.get_draw_style(style_name) > for key in kwargs: > setattr(style, key, kwargs[key]) > > I have no idea if leader, nor leader_suffix are part of the style. But > if they were/are, and we add a kwargs option, then one could override > any aspect of the start_*() or write_*() methods. > > If you want to change the paragraph start for all paragraphs, though, > it seems that this should just be a style element that you change > once. > > I have no idea of the internals of this... just thinking out loud, and > hoping that we don't have to keep adding additional arguments to > override different aspects of each start/write. > > -Doug > > > Matt > > > > -- > > HH Golf Society > > www.hh-gs.com > > > > IFLAF > > www.iflaf.com > > > > > ------------------------------------------------------------------------------ > > All the data continuously generated in your IT infrastructure contains a > > definitive record of customers, application performance, security > > threats, fraudulent activity and more. Splunk takes this data and makes > > sense of it. Business sense. IT sense. Common sense. > > http://p.sf.net/sfu/splunk-d2d-oct > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Brian M. <br...@gr...> - 2011-10-19 15:01:57
|
Benny, >Is this not already possible playing with the indent of the paragraph in the style editor? Eg indent -0.5. >Anyway, changing start_paragraph is not ok, as that is the document API, so ODFdoc should leave it alone. You should add something to style instead if this cannot be globally changed. I agree. We shouldn't add parameters to the TextDoc interface that only apply to one output type. That wouldn't be good for the other TextDoc implementations. Matt, Modifying the style is the correct way to handle this. And instead of choosing whether the output includes a space or a tab, the selection should be the width of the tab stop. As a stop-gap, you should be able to just open up the ODT document and change the tab stops for that paragraph style to make it work the way you want. ~Brian |
From: Serge N. <Ser...@fr...> - 2011-10-20 19:15:40
|
Le 19/10/2011 13:35, Matt Keenan a écrit : > Hi, > > Attempting to write a custom Descendant Report with my preferred > output to date being ODF. > > However I'm seeing an issue where alignment is somewhat out because > ODF start_paragraph method by default puts a tab white space after > the leader (typically numbering system), if the leader is present. I have several questions to ask for that : Do you use libreoffice or openoffice ? What version ? I saw a similar problem with one report I wrote. It depends on the OO version. Gramps generate an ODT file based on the 1.0 ODF format. since several versions, the default document version for OO and LO is 1.2 so we may have this kind of problems. The solution for me was : OpenOffice or LibreOffice -> Tools -> Options -> Load/Save -> General -> ODF format Choose 1.0/1.1 Does it solve your problem ? > I'd like some means of overriding this tab to be a simple space > instead., the two most obvious means to achieve this are : > > 1. Change the default behaviour in > plugins/docgen/ODFDoc.py:start_paragraph() to simply print space > instead of TAB > > - self.cntnt.write(leader + '<text:tab/>') > + self.cntnt.write(leader + '<text: />') > > This would change the default behaviour for all ODF documents > produced, which admittedly I feel would most likely not > suit everybody. > > > 2. Provided a new optional paramater to the start_paragraph() method, > allowing for the custom provision of a leader_suffix > e.g. > > Index: plugins/docgen/ODFDoc.py > =================================================================== > --- plugins/docgen/ODFDoc.py (revision 18351) > +++ plugins/docgen/ODFDoc.py (working copy) > @@ -1473,7 +1473,7 @@ > """ > self.cntnt.write('</text:p>\n') > > - def start_paragraph(self, style_name, leader=None): > + def start_paragraph(self, style_name, leader=None, leader_suffix=None): > """ > open a new paragraph > """ > @@ -1493,7 +1493,10 @@ > ' text:outline-level="%s">' % str(self.level) > ) > if leader is not None: > - self.cntnt.write(leader + '<text:tab/>') > + if leader_suffix is not None: > + self.cntnt.write(leader + '<text:%s/>' % > (str(leader_suffix))) > + else: > + self.cntnt.write(leader + '<text:tab/>') > self.new_cell = 0 > > > In testing this works nicely for me, however changing this just ind > ODFDoc.py would not be right, ideally it would have > to be added everywhere in gramps where start_paragraph() is defined, > which in trunk is currently : > > gen/plug/docgen/textdoc.py > plugins/docgen/HtmlDoc.py > plugins/docgen/AsciiDoc.py > plugins/docgen/ODFDoc.py > plugins/docgen/RTFDoc.py > plugins/docgen/LaTeXDoc.py > plugins/lib/libcairodoc.py > docgen/TextBufDoc.py > > Wanted to ping the devel list to see if there is a better solution to > my conundrum... > > thoughts ? > > Matt |
From: Matt K. <mat...@gm...> - 2011-10-21 09:45:52
Attachments:
descend-report-bad.png
|
Serge, Thanks for the reply, I'm using OpenOffice 3.3.0 and as you say it defaults to using 1.2. I changed to use 1.0 as you suggest, and re-launched and opened my report but the problem still persists. Attached : - descend-repoort-bad.png : shows the tabs in place where I'd really prefer spaces and you can clearly see the alignment is out. Replacing the tabs for spaces, makes the alignment nice and clean. As the tab is hard coded by default it's always going to get printed in the report, and as I generally agree changing the paramaters to start_paragraph is not the way to go As Adam suggests one possible solutoin is to do a hard replacement when I open the ODF document for s/TAB/space/. I'd prefer a more automated solution. So can styles be used to achieve this ? Can you specify the location of tab stops in a style ? I'm a bit of a newb when it comes to styles so any advice much appreciated. cheers Matt On 10/20/11 20:15, Serge Noiraud wrote: > Le 19/10/2011 13:35, Matt Keenan a écrit : >> Hi, >> >> Attempting to write a custom Descendant Report with my preferred >> output to date being ODF. >> >> However I'm seeing an issue where alignment is somewhat out because >> ODF start_paragraph method by default puts a tab white space after >> the leader (typically numbering system), if the leader is present. > I have several questions to ask for that : > Do you use libreoffice or openoffice ? > What version ? > > I saw a similar problem with one report I wrote. > It depends on the OO version. > Gramps generate an ODT file based on the 1.0 ODF format. > since several versions, the default document version for OO and LO is 1.2 > so we may have this kind of problems. > > The solution for me was : > > OpenOffice or LibreOffice -> Tools -> Options -> Load/Save -> General -> ODF format > Choose 1.0/1.1 > > Does it solve your problem ? > >> I'd like some means of overriding this tab to be a simple space >> instead., the two most obvious means to achieve this are : >> >> 1. Change the default behaviour in >> plugins/docgen/ODFDoc.py:start_paragraph() to simply print space >> instead of TAB >> >> - self.cntnt.write(leader + '<text:tab/>') >> + self.cntnt.write(leader + '<text: />') >> >> This would change the default behaviour for all ODF documents >> produced, which admittedly I feel would most likely not >> suit everybody. >> >> >> 2. Provided a new optional paramater to the start_paragraph() method, >> allowing for the custom provision of a leader_suffix >> e.g. >> >> Index: plugins/docgen/ODFDoc.py >> =================================================================== >> --- plugins/docgen/ODFDoc.py (revision 18351) >> +++ plugins/docgen/ODFDoc.py (working copy) >> @@ -1473,7 +1473,7 @@ >> """ >> self.cntnt.write('</text:p>\n') >> >> - def start_paragraph(self, style_name, leader=None): >> + def start_paragraph(self, style_name, leader=None, leader_suffix=None): >> """ >> open a new paragraph >> """ >> @@ -1493,7 +1493,10 @@ >> ' text:outline-level="%s">' % str(self.level) >> ) >> if leader is not None: >> - self.cntnt.write(leader + '<text:tab/>') >> + if leader_suffix is not None: >> + self.cntnt.write(leader + '<text:%s/>' % >> (str(leader_suffix))) >> + else: >> + self.cntnt.write(leader + '<text:tab/>') >> self.new_cell = 0 >> >> >> In testing this works nicely for me, however changing this just ind >> ODFDoc.py would not be right, ideally it would have >> to be added everywhere in gramps where start_paragraph() is defined, >> which in trunk is currently : >> >> gen/plug/docgen/textdoc.py >> plugins/docgen/HtmlDoc.py >> plugins/docgen/AsciiDoc.py >> plugins/docgen/ODFDoc.py >> plugins/docgen/RTFDoc.py >> plugins/docgen/LaTeXDoc.py >> plugins/lib/libcairodoc.py >> docgen/TextBufDoc.py >> >> Wanted to ping the devel list to see if there is a better solution to >> my conundrum... >> >> thoughts ? >> >> Matt > > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Serge N. <Ser...@fr...> - 2011-10-21 18:58:41
Attachments:
descend-report-ex1.png
|
Le 21/10/2011 11:40, Matt Keenan a écrit : > Serge, > > Thanks for the reply, I'm using OpenOffice 3.3.0 and as you say it defaults to using 1.2. > > I changed to use 1.0 as you suggest, and re-launched and opened my report but the problem still persists. > > Attached : > - descend-repoort-bad.png : shows the tabs in place where I'd really > prefer spaces and you can clearly see the alignment is out. > > Replacing the tabs for spaces, makes the alignment nice and clean. I don't agree. The ODF module generates the document as it is for others format. If we do that, the report will no be the same as pdf or rtf. All documents generate tabs. If we use tabs, this is for numbering which is not always constant in length. I have a png in copy. Perhaps you need to change how you write your report. If you send it to me, I can try to solve this. > > As the tab is hard coded by default it's always going to get printed in the report, and as I generally agree changing the paramaters to start_paragraph is not the way to go > > As Adam suggests one possible solutoin is to do a hard replacement when I open the ODF document for s/TAB/space/. I'd prefer a more automated solution. > > So can styles be used to achieve this ? Can you specify the location of tab stops in a style ? I'm a bit of a newb when it comes to styles so any advice much appreciated. We already use style. I create ODF styles depending on gramps style. > > cheers > > Matt > > On 10/20/11 20:15, Serge Noiraud wrote: >> Le 19/10/2011 13:35, Matt Keenan a écrit : >>> Hi, >>> >>> Attempting to write a custom Descendant Report with my preferred >>> output to date being ODF. >>> >>> However I'm seeing an issue where alignment is somewhat out because >>> ODF start_paragraph method by default puts a tab white space after >>> the leader (typically numbering system), if the leader is present. >> I have several questions to ask for that : >> Do you use libreoffice or openoffice ? >> What version ? >> >> I saw a similar problem with one report I wrote. >> It depends on the OO version. >> Gramps generate an ODT file based on the 1.0 ODF format. >> since several versions, the default document version for OO and LO is 1.2 >> so we may have this kind of problems. >> >> The solution for me was : >> >> OpenOffice or LibreOffice -> Tools -> Options -> Load/Save -> General -> ODF format >> Choose 1.0/1.1 >> >> Does it solve your problem ? >> >>> I'd like some means of overriding this tab to be a simple space >>> instead., the two most obvious means to achieve this are : >>> >>> 1. Change the default behaviour in >>> plugins/docgen/ODFDoc.py:start_paragraph() to simply print space >>> instead of TAB >>> >>> - self.cntnt.write(leader + '<text:tab/>') >>> + self.cntnt.write(leader + '<text: />') >>> >>> This would change the default behaviour for all ODF documents >>> produced, which admittedly I feel would most likely not >>> suit everybody. >>> >>> >>> 2. Provided a new optional paramater to the start_paragraph() method, >>> allowing for the custom provision of a leader_suffix >>> e.g. >>> >>> Index: plugins/docgen/ODFDoc.py >>> =================================================================== >>> --- plugins/docgen/ODFDoc.py (revision 18351) >>> +++ plugins/docgen/ODFDoc.py (working copy) >>> @@ -1473,7 +1473,7 @@ >>> """ >>> self.cntnt.write('</text:p>\n') >>> >>> - def start_paragraph(self, style_name, leader=None): >>> + def start_paragraph(self, style_name, leader=None, leader_suffix=None): >>> """ >>> open a new paragraph >>> """ >>> @@ -1493,7 +1493,10 @@ >>> ' text:outline-level="%s">' % str(self.level) >>> ) >>> if leader is not None: >>> - self.cntnt.write(leader + '<text:tab/>') >>> + if leader_suffix is not None: >>> + self.cntnt.write(leader + '<text:%s/>' % >>> (str(leader_suffix))) >>> + else: >>> + self.cntnt.write(leader + '<text:tab/>') >>> self.new_cell = 0 >>> >>> >>> In testing this works nicely for me, however changing this just ind >>> ODFDoc.py would not be right, ideally it would have >>> to be added everywhere in gramps where start_paragraph() is defined, >>> which in trunk is currently : >>> >>> gen/plug/docgen/textdoc.py >>> plugins/docgen/HtmlDoc.py >>> plugins/docgen/AsciiDoc.py >>> plugins/docgen/ODFDoc.py >>> plugins/docgen/RTFDoc.py >>> plugins/docgen/LaTeXDoc.py >>> plugins/lib/libcairodoc.py >>> docgen/TextBufDoc.py >>> >>> Wanted to ping the devel list to see if there is a better solution to >>> my conundrum... >>> >>> thoughts ? >>> >>> Matt |
From: Matt K. <mat...@gm...> - 2011-11-14 16:58:14
|
Serge, Finally getting back to looking at this again :-) Unfortunately this is not down to how I am writing a custom report, I am seeing this with the default descendant report on trunk. The example png you sent is really not how I like the output to be viewed. In your png you have all the names regardless of level appearing indented directly under each other. I would prefer for each name to be snug against the numbering, and instead have all similar numbered levels indented to the same degree.. I had a play with the Descendant report chaning the "first_indent" for the level styles and discovered that changing from -0.5 up to -0.8 was sufficient enough for me to get something printed in the form that works. Just a shame I have to hack the code for one of the default reports to achieve this though :-( cheers Matt On 21 October 2011 19:58, Serge Noiraud <Ser...@fr...> wrote: > Le 21/10/2011 11:40, Matt Keenan a écrit : >> >> Serge, >> >> Thanks for the reply, I'm using OpenOffice 3.3.0 and as you say it >> defaults to using 1.2. >> >> I changed to use 1.0 as you suggest, and re-launched and opened my report >> but the problem still persists. >> >> Attached : >> - descend-repoort-bad.png : shows the tabs in place where I'd really >> prefer spaces and you can clearly see the alignment is out. >> >> Replacing the tabs for spaces, makes the alignment nice and clean. > > I don't agree. The ODF module generates the document as it is for others > format. > If we do that, the report will no be the same as pdf or rtf. > All documents generate tabs. > If we use tabs, this is for numbering which is not always constant in > length. > I have a png in copy. > Perhaps you need to change how you write your report. > If you send it to me, I can try to solve this. >> >> As the tab is hard coded by default it's always going to get printed in >> the report, and as I generally agree changing the paramaters to >> start_paragraph is not the way to go >> >> As Adam suggests one possible solutoin is to do a hard replacement when I >> open the ODF document for s/TAB/space/. I'd prefer a more automated >> solution. >> >> So can styles be used to achieve this ? Can you specify the location of >> tab stops in a style ? I'm a bit of a newb when it comes to styles so any >> advice much appreciated. > > We already use style. I create ODF styles depending on gramps style. >> >> cheers >> >> Matt >> >> On 10/20/11 20:15, Serge Noiraud wrote: >>> >>> Le 19/10/2011 13:35, Matt Keenan a écrit : >>>> >>>> Hi, >>>> >>>> Attempting to write a custom Descendant Report with my preferred >>>> output to date being ODF. >>>> >>>> However I'm seeing an issue where alignment is somewhat out because >>>> ODF start_paragraph method by default puts a tab white space after >>>> the leader (typically numbering system), if the leader is present. >>> >>> I have several questions to ask for that : >>> Do you use libreoffice or openoffice ? >>> What version ? >>> >>> I saw a similar problem with one report I wrote. >>> It depends on the OO version. >>> Gramps generate an ODT file based on the 1.0 ODF format. >>> since several versions, the default document version for OO and LO is 1.2 >>> so we may have this kind of problems. >>> >>> The solution for me was : >>> >>> OpenOffice or LibreOffice -> Tools -> Options -> Load/Save -> General >>> -> ODF format >>> Choose 1.0/1.1 >>> >>> Does it solve your problem ? >>> >>>> I'd like some means of overriding this tab to be a simple space >>>> instead., the two most obvious means to achieve this are : >>>> >>>> 1. Change the default behaviour in >>>> plugins/docgen/ODFDoc.py:start_paragraph() to simply print space >>>> instead of TAB >>>> >>>> - self.cntnt.write(leader + '<text:tab/>') >>>> + self.cntnt.write(leader + '<text: />') >>>> >>>> This would change the default behaviour for all ODF documents >>>> produced, which admittedly I feel would most likely not >>>> suit everybody. >>>> >>>> >>>> 2. Provided a new optional paramater to the start_paragraph() method, >>>> allowing for the custom provision of a leader_suffix >>>> e.g. >>>> >>>> Index: plugins/docgen/ODFDoc.py >>>> =================================================================== >>>> --- plugins/docgen/ODFDoc.py (revision 18351) >>>> +++ plugins/docgen/ODFDoc.py (working copy) >>>> @@ -1473,7 +1473,7 @@ >>>> """ >>>> self.cntnt.write('</text:p>\n') >>>> >>>> - def start_paragraph(self, style_name, leader=None): >>>> + def start_paragraph(self, style_name, leader=None, >>>> leader_suffix=None): >>>> """ >>>> open a new paragraph >>>> """ >>>> @@ -1493,7 +1493,10 @@ >>>> ' text:outline-level="%s">' % str(self.level) >>>> ) >>>> if leader is not None: >>>> - self.cntnt.write(leader + '<text:tab/>') >>>> + if leader_suffix is not None: >>>> + self.cntnt.write(leader + '<text:%s/>' % >>>> (str(leader_suffix))) >>>> + else: >>>> + self.cntnt.write(leader + '<text:tab/>') >>>> self.new_cell = 0 >>>> >>>> >>>> In testing this works nicely for me, however changing this just ind >>>> ODFDoc.py would not be right, ideally it would have >>>> to be added everywhere in gramps where start_paragraph() is defined, >>>> which in trunk is currently : >>>> >>>> gen/plug/docgen/textdoc.py >>>> plugins/docgen/HtmlDoc.py >>>> plugins/docgen/AsciiDoc.py >>>> plugins/docgen/ODFDoc.py >>>> plugins/docgen/RTFDoc.py >>>> plugins/docgen/LaTeXDoc.py >>>> plugins/lib/libcairodoc.py >>>> docgen/TextBufDoc.py >>>> >>>> Wanted to ping the devel list to see if there is a better solution to >>>> my conundrum... >>>> >>>> thoughts ? >>>> >>>> Matt > > -- HH Golf Society www.hh-gs.com IFLAF www.iflaf.com |
From: Serge N. <Ser...@fr...> - 2011-11-14 22:44:07
|
Le 14/11/2011 17:58, Matt Keenan a écrit : > Finally getting back to looking at this again:-) > > Unfortunately this is not down to how I am writing a custom report, I > am seeing this with the default descendant report on trunk. > > The example png you sent is really not how I like the output to be > viewed. In your png you have all the names regardless of level > appearing indented directly under each other. I would prefer for each > name to be snug against the numbering, and instead have all similar > numbered levels indented to the same degree.. > > I had a play with the Descendant report chaning the "first_indent" for > the level styles and discovered that changing from -0.5 up to -0.8 was > sufficient enough for me to get something printed in the form that > works. Just a shame I have to hack the code for one of the default > reports to achieve this though Did you try to edit styles for the report without hacking the code ? When you select the report, under the file name, you have a style editor. If you select it, you can add a new style. you select DDR-childlist and have the possibility to modify all you need. I never do that. perhaps someone already done this and can give more details ? Serge |
From: Matt K. <mat...@gm...> - 2011-11-14 23:54:35
|
Serge, Thanks for your help. Good point, never knew you could do this, gave a quick look and you can indeed edit the style, but it would require editing all the individual DDRLevel* paragraph styles by hand. Which is a tad cumbersome and you would have to edit them every time you run the report... editing just one live of code, s/0.5/0.8/ is actually much faster :-) in this case and also remains persistent across report runs. So looks like this is what I'll have to do going forward. thanks again Matt On 14 November 2011 22:44, Serge Noiraud <Ser...@fr...> wrote: > Le 14/11/2011 17:58, Matt Keenan a écrit : >> >> Finally getting back to looking at this again:-) >> >> Unfortunately this is not down to how I am writing a custom report, I >> am seeing this with the default descendant report on trunk. >> >> The example png you sent is really not how I like the output to be >> viewed. In your png you have all the names regardless of level >> appearing indented directly under each other. I would prefer for each >> name to be snug against the numbering, and instead have all similar >> numbered levels indented to the same degree.. >> >> I had a play with the Descendant report chaning the "first_indent" for >> the level styles and discovered that changing from -0.5 up to -0.8 was >> sufficient enough for me to get something printed in the form that >> works. Just a shame I have to hack the code for one of the default >> reports to achieve this though > > Did you try to edit styles for the report without hacking the code ? > When you select the report, under the file name, you have a style editor. > If you select it, you can add a new style. > you select DDR-childlist and have the possibility to modify all you need. > I never do that. > perhaps someone already done this and can give more details ? > > Serge > -- HH Golf Society www.hh-gs.com IFLAF www.iflaf.com |
From: Brian M. <br...@gr...> - 2011-11-15 00:54:45
|
Matt, >Good point, never knew you could do this, gave a quick look and you >can indeed edit the style, but it would require editing all the >individual DDRLevel* paragraph styles by hand. Which is a tad >cumbersome and you would have to edit them every time you run the >report... editing just one live of code, s/0.5/0.8/ is actually much >faster :-) in this case and also remains persistent across report >runs. So looks like this is what I'll have to do going forward. The styles can be named, saved and reused in subsequent report runs. There is no need to modify the style with each run. ~Brian |
From: Rob H. <rob...@gm...> - 2011-11-15 17:38:18
|
Dear Serge, Brian, and Matt: I would love to be able to get something available to the users, a way to download and install other style sheets that they may have used or created! It would be something like a skins but style sheets instead! On Tue, Nov 15, 2011 at 9:23 AM, Serge Noiraud <Ser...@fr...>wrote: > Le 15/11/2011 15:02, Brian Matherly a écrit : > > Matt, >> >>> Brian, >>> >>> Thanks for the info, I'll try that out. >>> >>> With regard to provision of different styles. I'm not sure how styles >>> are implemented, can they be loaded automatically on launch etc, Could >>> custom styles be provided in a similar manner as custom reports are >>> currently ? So when gramps launches it could as it does not for >>> reports, check what new styles are available and download/add them if >>> the user so chooses ? >>> >> I suppose they could. Someone would just have to build the infrastructure >> for that. >> > I am sorry, but it seems as if Doug already most of the download/ update code in place with the third- party download/ update code... > >> Currently, custom styles are saved in an XML file in the users ".gramps" >> directory along with all the other settings. So it would be easy to e-mail >> some the styles XML file and have them put it in their .gramps directory. >> > Perhaps we could have like the plugins download a style download ? > I think this would allow the users to get more involved in Gramps by being able to create a style sheet layout and presentation of the different reports... Sincerely yours, Rob G. Healey > >> ~Brian >> > Serge > -- Sincerely yours, Rob G. Healey |