Question about an old issue

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about an old issue

Peter Landgren
Hi,

I looked through my reported issues and found this:
http://www.gramps-project.org/bugs/view.php?id=2848

Tried to look at it and found that in AsciiDoc.py
    #--------------------------------------------------------------------
    #
    # Writes text.
    #--------------------------------------------------------------------
    def write_text(self,text,mark=None):
        self.text = self.text + text

'text' sometimes contains "\n", which, if printed, should be replaced with 0xa.

However, when printing endnotes the result is
2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)

      a: Engelbrekt b: Vreta Kloster

when is should be
2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)

      a: Engelbrekt
      b: Vreta Kloster

In this case the is a 0xa in the string 'b: Vreta Kloster'
Where does this '\n'  disappear?
Or how do I define end of row/new line for each reference a:, b: c: ...?

/Peter


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Duncan Lithgow-5
This is a fair question, but why do the reports use an extra line for
each of those small additions? Seems silly to me. Nowhere else in the
detailed reports does something that short get a whole line to itself.

Duncan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Peter Landgren
Duncan,

I'm not sure what you mean. The plain text ouput it printed as:

1. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)

      a: Döderhult C:4 1785-1842; GID: 17.28.49600 b: 190.102.41800,
      [Kalmar] Västervik, C.6, Födde,Vigsel,Död, 1805 - 1840, 0-0, Bild
      317 av 465 c: Skepssholmen CI:5, p 37 b# 23 d: Brännkyrka CI:5
      1867 #14 e: Karlshamn 1874-1884 GID: 1759.58.19900? f:
      Skeppsholmen CI:5 p 47 #7 g: Stockholm, Finska, C:14 p 30, #4 h:
      Nacka CI:9, p 50, #110 i: Adolf Fredrik CIA:23 p 110 # 874 j:
      Engelbrekt k: Vreta Kloster

which is very hard to read.

While in Open Office output it's:

1.  Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
    a: Döderhult C:4 1785-1842; GID: 17.28.49600
    b: 190.102.41800, [Kalmar] Västervik, C.6, Födde,Vigsel,Död, 1805 - 1840, 0-0, Bild
317 av 465
    c: Skepssholmen CI:5, p 37 b# 23
    d: Brännkyrka CI:5 1867 #14
    e: Karlshamn 1874-1884 GID: 1759.58.19900?
    f: Skeppsholmen CI:5 p 47 #7
    g: Stockholm, Finska, C:14 p 30, #4
    h: Nacka CI:9, p 50, #110
    i: Adolf Fredrik CIA:23 p 110 # 874
    j: Engelbrekt
    k: Vreta Kloster

which I think it shoul be also in plain text output.

/Peter

> This is a fair question, but why do the reports use an extra line for
> each of those small additions? Seems silly to me. Nowhere else in the
> detailed reports does something that short get a whole line to itself.
>
> Duncan


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Duncan Lithgow-5
2009/8/16 Peter Landgren <[hidden email]>:

> While in Open Office output it's:
>
> 1.  Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
>    a: Döderhult C:4 1785-1842; GID: 17.28.49600
>    b: 190.102.41800, [Kalmar] Västervik, C.6, Födde,Vigsel,Död, 1805 - 1840, 0-0, Bild
> 317 av 465
>    c: Skepssholmen CI:5, p 37 b# 23
>    d: Brännkyrka CI:5 1867 #14
>    e: Karlshamn 1874-1884 GID: 1759.58.19900?
>    f: Skeppsholmen CI:5 p 47 #7
>    g: Stockholm, Finska, C:14 p 30, #4
>    h: Nacka CI:9, p 50, #110
>    i: Adolf Fredrik CIA:23 p 110 # 874
>    j: Engelbrekt
>    k: Vreta Kloster

Okay, for me each of thsoe entries is much shorter so I've wondered
why they get a new line each - but I can see for you that it would be
silly to put them all in aline after each other. So just ignore me and
keep looking fior the answer,

Duncan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Benny Malengier
In reply to this post by Peter Landgren
2009/8/15 Peter Landgren <[hidden email]>:

> Hi,
>
> I looked through my reported issues and found this:
> http://www.gramps-project.org/bugs/view.php?id=2848
>
> Tried to look at it and found that in AsciiDoc.py
>    #--------------------------------------------------------------------
>    #
>    # Writes text.
>    #--------------------------------------------------------------------
>    def write_text(self,text,mark=None):
>        self.text = self.text + text
>
> 'text' sometimes contains "\n", which, if printed, should be replaced with 0xa.
>
> However, when printing endnotes the result is
> 2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
>
>      a: Engelbrekt b: Vreta Kloster
>
> when is should be
> 2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
>
>      a: Engelbrekt
>      b: Vreta Kloster
>
> In this case the is a 0xa in the string 'b: Vreta Kloster'
> Where does this '\n'  disappear?

The error must be somewhere in the end_paragraph method.
It takes the self.text variable, and formats it to print on the file.
As this text has a leader/indent in that paragraph, my guess it the \n
are removed, and should be re-added with the defined leader/indent,
but the \n go lost.
There must be a bug there somewhere.

Benny

> Or how do I define end of row/new line for each reference a:, b: c: ...?
>
> /Peter
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Peter Landgren
Den Monday 17 August 2009 10.11.56 skrev Benny Malengier:

> 2009/8/15 Peter Landgren <[hidden email]>:
> > Hi,
> >
> > I looked through my reported issues and found this:
> > http://www.gramps-project.org/bugs/view.php?id=2848
> >
> > Tried to look at it and found that in AsciiDoc.py
> >    #--------------------------------------------------------------------
> >    #
> >    # Writes text.
> >    #--------------------------------------------------------------------
> >    def write_text(self,text,mark=None):
> >        self.text = self.text + text
> >
> > 'text' sometimes contains "\n", which, if printed, should be replaced
> > with 0xa.
> >
> > However, when printing endnotes the result is
> > 2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
> >
> >      a: Engelbrekt b: Vreta Kloster
> >
> > when is should be
> > 2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
> >
> >      a: Engelbrekt
> >      b: Vreta Kloster
> >
> > In this case the is a 0xa in the string 'b: Vreta Kloster'
> > Where does this '\n'  disappear?
>
> The error must be somewhere in the end_paragraph method.
> It takes the self.text variable, and formats it to print on the file.
> As this text has a leader/indent in that paragraph, my guess it the \n
> are removed, and should be re-added with the defined leader/indent,
> but the \n go lost.
> There must be a bug there somewhere.
>
> Benny
Yes, that's my impression too so I looked at it a bit more and found that in my test case  
with self.text= "a: Engelbrekt\nb: Vreta Kloster" in the method reformat_para will loose
"\n" in the operation words = para.split()

When the line is put together later no "\n" is used.

So, maybe the call to this method should change?

/Peter




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Benny Malengier
2009/8/17 Peter Landgren <[hidden email]>:

> Den Monday 17 August 2009 10.11.56 skrev Benny Malengier:
>> 2009/8/15 Peter Landgren <[hidden email]>:
>> > Hi,
>> >
>> > I looked through my reported issues and found this:
>> > http://www.gramps-project.org/bugs/view.php?id=2848
>> >
>> > Tried to look at it and found that in AsciiDoc.py
>> >    #--------------------------------------------------------------------
>> >    #
>> >    # Writes text.
>> >    #--------------------------------------------------------------------
>> >    def write_text(self,text,mark=None):
>> >        self.text = self.text + text
>> >
>> > 'text' sometimes contains "\n", which, if printed, should be replaced
>> > with 0xa.
>> >
>> > However, when printing endnotes the result is
>> > 2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
>> >
>> >      a: Engelbrekt b: Vreta Kloster
>> >
>> > when is should be
>> > 2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
>> >
>> >      a: Engelbrekt
>> >      b: Vreta Kloster
>> >
>> > In this case the is a 0xa in the string 'b: Vreta Kloster'
>> > Where does this '\n'  disappear?
>>
>> The error must be somewhere in the end_paragraph method.
>> It takes the self.text variable, and formats it to print on the file.
>> As this text has a leader/indent in that paragraph, my guess it the \n
>> are removed, and should be re-added with the defined leader/indent,
>> but the \n go lost.
>> There must be a bug there somewhere.
>>
>> Benny
> Yes, that's my impression too so I looked at it a bit more and found that in my test case
> with self.text= "a: Engelbrekt\nb: Vreta Kloster" in the method reformat_para will loose
> "\n" in the operation words = para.split()
>
> When the line is put together later no "\n" is used.
>
> So, maybe the call to this method should change?

In many places of text output, the text is cleaned before writing.
Apparently the reformat_para does this here.
Some things are not ok:

1/for preformatted text, reformat_para should not be called, it
destroys the preformatting

2/for something that is not a note, reformat_para should not remove \n
or whitespace.

3/only for real notes that are not preformatted should \n and
whitespace be removed.

I would suggest to change things as follows:

1/In write_note, set a self.__note = True, and set self.__format =
format, unset that at end of note
2/in end_paragraph, only if not preformatted note, do as now. For a
preformatted note, do no cleaning of the paragraph, just print it or
add line per line to the cell.
3/if not a note is being written, then split on \n, and print the
line, if in a cell, add line per line to the cell.

So something like:

if not self.__format == 'the preformat format'
   if not self.__note
      old_lines = para.split('\n')
   else:
      old_lines = [para]
   for line in old_lines:
          words = line.split()
          #do as now ...
else:
   for line in para.split(\n)
       lines.append(line)
#continue
if just ==

Benny

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Peter Landgren
Den Monday 17 August 2009 14.20.09 skrev Benny Malengier:

> 2009/8/17 Peter Landgren <[hidden email]>:
> > Den Monday 17 August 2009 10.11.56 skrev Benny Malengier:
> >> 2009/8/15 Peter Landgren <[hidden email]>:
> >> > Hi,
> >> >
> >> > I looked through my reported issues and found this:
> >> > http://www.gramps-project.org/bugs/view.php?id=2848
> >> >
> >> > Tried to look at it and found that in AsciiDoc.py
> >> >  
> >> >  #--------------------------------------------------------------------
> >> > #
> >> >    # Writes text.
> >> >  
> >> >  #--------------------------------------------------------------------
> >> > def write_text(self,text,mark=None):
> >> >        self.text = self.text + text
> >> >
> >> > 'text' sometimes contains "\n", which, if printed, should be replaced
> >> > with 0xa.
> >> >
> >> > However, when printing endnotes the result is
> >> > 2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
> >> >
> >> >      a: Engelbrekt b: Vreta Kloster
> >> >
> >> > when is should be
> >> > 2. Svenska Kyrkan, "Föddebok", Information från föddelängder, (FL)
> >> >
> >> >      a: Engelbrekt
> >> >      b: Vreta Kloster
> >> >
> >> > In this case the is a 0xa in the string 'b: Vreta Kloster'
> >> > Where does this '\n'  disappear?
> >>
> >> The error must be somewhere in the end_paragraph method.
> >> It takes the self.text variable, and formats it to print on the file.
> >> As this text has a leader/indent in that paragraph, my guess it the \n
> >> are removed, and should be re-added with the defined leader/indent,
> >> but the \n go lost.
> >> There must be a bug there somewhere.
> >>
> >> Benny
> >
> > Yes, that's my impression too so I looked at it a bit more and found that
> > in my test case with self.text= "a: Engelbrekt\nb: Vreta Kloster" in the
> > method reformat_para will loose "\n" in the operation words =
> > para.split()
> >
> > When the line is put together later no "\n" is used.
> >
> > So, maybe the call to this method should change?
>
> In many places of text output, the text is cleaned before writing.
> Apparently the reformat_para does this here.
> Some things are not ok:
>
> 1/for preformatted text, reformat_para should not be called, it
> destroys the preformatting
>
> 2/for something that is not a note, reformat_para should not remove \n
> or whitespace.
>
> 3/only for real notes that are not preformatted should \n and
> whitespace be removed.
>
> I would suggest to change things as follows:
>
> 1/In write_note, set a self.__note = True, and set self.__format =
> format, unset that at end of note
> 2/in end_paragraph, only if not preformatted note, do as now. For a
> preformatted note, do no cleaning of the paragraph, just print it or
> add line per line to the cell.
> 3/if not a note is being written, then split on \n, and print the
> line, if in a cell, add line per line to the cell.
>
> So something like:
>
> if not self.__format == 'the preformat format'
>    if not self.__note
>       old_lines = para.split('\n')
>    else:
>       old_lines = [para]
>    for line in old_lines:
>           words = line.split()
>           #do as now ...
> else:
>    for line in para.split(\n)
>        lines.append(line)
> #continue
> if just ==
>
> Benny

OK.
I have assigned
http://www.gramps-project.org/bugs/view.php?id=2848
to me.
I see what I can do.
/Peter


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Peter Landgren
Benny,
(see below)


<snip>


> > In many places of text output, the text is cleaned before writing.
> > Apparently the reformat_para does this here.
> > Some things are not ok:
> >
> > 1/for preformatted text, reformat_para should not be called, it
> > destroys the preformatting
> >
> > 2/for something that is not a note, reformat_para should not remove \n
> > or whitespace.
> >
> > 3/only for real notes that are not preformatted should \n and
> > whitespace be removed.
> >
> > I would suggest to change things as follows:
> >
> > 1/In write_note, set a self.__note = True, and set self.__format =
> > format, unset that at end of note
> > 2/in end_paragraph, only if not preformatted note, do as now. For a
> > preformatted note, do no cleaning of the paragraph, just print it or
> > add line per line to the cell.
> > 3/if not a note is being written, then split on \n, and print the
> > line, if in a cell, add line per line to the cell.
> >
> > So something like:
> >
> > if not self.__format == 'the preformat format'
> > if not self.__note
> > old_lines = para.split('\n')
> > else:
> > old_lines = [para]
> > for line in old_lines:
> > words = line.split()
> > #do as now ...
> > else:
> > for line in para.split(\n)
> > lines.append(line)
> > #continue
> > if just ==
> >
> > Benny
>
> OK.
> I have assigned
> http://www.gramps-project.org/bugs/view.php?id=2848
> to me.
> I see what I can do.
> /Peter


This fall we discussed this issue. I have had it in my backlog since.
Now I took some time to look at it and I think we were talking about two different notes.
Preformatted Notes and the references lines within Endnotes.


So I did a test using individ_complete report to look at these two features.


Preformatted Endnotes;lines with references Comments
----------------------------------------------------------------------------------
HTML, Firefox etc OK NOT OK; all references on one line
Is OK i branch!
----------------------------------------------------------------------------------
ODT, OOWriter OK OK
ODT, Kword OK OK
----------------------------------------------------------------------------------
PDF, Adobe Reader OK OK
PDF, okular OK OK
----------------------------------------------------------------------------------
RTF, OOWriter Not OK OK Many errors
RTF, AbiWord Not OK OK
RTF, KWord OK? OK Many errors
----------------------------------------------------------------------------------
TXT, kwrite Not OK NOT OK; all references on one line
Double spaced
lines
----------------------------------------------------------------------------------


After step 1, which only influenced AsciiDoc:
----------------------------------------------------------------------------------
TXT, kwrite OK NOT OK; all references on one line
----------------------------------------------------------------------------------


After step 2, which only influenced _Endnotes.py


Preformatted Endnotes;lines with references Comments
----------------------------------------------------------------------------------
HTML, Firefox etc OK OK
----------------------------------------------------------------------------------
ODT, OOWriter OK OK
ODT, Kword OK OK
----------------------------------------------------------------------------------
PDF, Adobe Reader OK OK
PDF, okular OK OK
----------------------------------------------------------------------------------
RTF, OOWriter Not OK OK Many errors
RTF, AbiWord Not OK OK
RTF, KWord Missing OK Many errors
----------------------------------------------------------------------------------
TXT, kwrite OK OK
----------------------------------------------------------------------------------


I have also large generated det_ancestor reports and they look OK with two comments:
RTF is not working well.
HTML some text and image overlap.
Images are made square,looks like projected through a cinemascope lens!


Patch files are attached.


I'm not sure these fixes are in line with Gramps coding practice, however, they are small.
Comments?


/Peter



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

AsciiDoc.patch (1K) Download Attachment
Endnotes.patch (1003 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

jerome
I suppose RTF format will still have unicode issues, maybe because it
was not planned to use unicode encoding ?
http://en.wikipedia.org/wiki/Rich_Text_Format#Character_encoding


Peter Landgren a écrit :

>   Benny,
> (see below)
>
>
> <snip>
>
>
>  > > In many places of text output, the text is cleaned before writing.
>  > > Apparently the reformat_para does this here.
>  > > Some things are not ok:
>  > >
>  > > 1/for preformatted text, reformat_para should not be called, it
>  > > destroys the preformatting
>  > >
>  > > 2/for something that is not a note, reformat_para should not remove \n
>  > > or whitespace.
>  > >
>  > > 3/only for real notes that are not preformatted should \n and
>  > > whitespace be removed.
>  > >
>  > > I would suggest to change things as follows:
>  > >
>  > > 1/In write_note, set a self.__note = True, and set self.__format =
>  > > format, unset that at end of note
>  > > 2/in end_paragraph, only if not preformatted note, do as now. For a
>  > > preformatted note, do no cleaning of the paragraph, just print it or
>  > > add line per line to the cell.
>  > > 3/if not a note is being written, then split on \n, and print the
>  > > line, if in a cell, add line per line to the cell.
>  > >
>  > > So something like:
>  > >
>  > > if not self.__format == 'the preformat format'
>  > > if not self.__note
>  > > old_lines = para.split('\n')
>  > > else:
>  > > old_lines = [para]
>  > > for line in old_lines:
>  > > words = line.split()
>  > > #do as now ...
>  > > else:
>  > > for line in para.split(\n)
>  > > lines.append(line)
>  > > #continue
>  > > if just ==
>  > >
>  > > Benny
>  >
>  > OK.
>  > I have assigned
>  > http://www.gramps-project.org/bugs/view.php?id=2848
>  > to me.
>  > I see what I can do.
>  > /Peter
>
>
> This fall we discussed this issue. I have had it in my backlog since.
> Now I took some time to look at it and I think we were talking about two
> different notes.
> Preformatted Notes and the references lines within Endnotes.
>
>
> So I did a test using individ_complete report to look at these two features.
>
>
> Preformatted Endnotes;lines with references Comments
> ----------------------------------------------------------------------------------
> HTML, Firefox etc OK NOT OK; all references on one line
> Is OK i branch!
> ----------------------------------------------------------------------------------
> ODT, OOWriter OK OK
> ODT, Kword OK OK
> ----------------------------------------------------------------------------------
> PDF, Adobe Reader OK OK
> PDF, okular OK OK
> ----------------------------------------------------------------------------------
> RTF, OOWriter Not OK OK Many errors
> RTF, AbiWord Not OK OK
> RTF, KWord OK? OK Many errors
> ----------------------------------------------------------------------------------
> TXT, kwrite Not OK NOT OK; all references on one line
> Double spaced
> lines
> ----------------------------------------------------------------------------------
>
>
> After step 1, which only influenced AsciiDoc:
> ----------------------------------------------------------------------------------
> TXT, kwrite OK NOT OK; all references on one line
> ----------------------------------------------------------------------------------
>
>
> After step 2, which only influenced _Endnotes.py
>
>
> Preformatted Endnotes;lines with references Comments
> ----------------------------------------------------------------------------------
> HTML, Firefox etc OK OK
> ----------------------------------------------------------------------------------
> ODT, OOWriter OK OK
> ODT, Kword OK OK
> ----------------------------------------------------------------------------------
> PDF, Adobe Reader OK OK
> PDF, okular OK OK
> ----------------------------------------------------------------------------------
> RTF, OOWriter Not OK OK Many errors
> RTF, AbiWord Not OK OK
> RTF, KWord Missing OK Many errors
> ----------------------------------------------------------------------------------
> TXT, kwrite OK OK
> ----------------------------------------------------------------------------------
>
>
> I have also large generated det_ancestor reports and they look OK with
> two comments:
> RTF is not working well.
> HTML some text and image overlap.
> Images are made square,looks like projected through a cinemascope lens!
>
>
> Patch files are attached.
>
>
> I'm not sure these fixes are in line with Gramps coding practice,
> however, they are small.
> Comments?
>
>
> /Peter
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Peter Landgren
No, I have not run into unicode problems with RTF so far.
One problem is that a preformatted note is shown as a non preformatted note.
I have not looked into this yet.

OpenOffice Writer is not as good viewer for RTF as AbiWord.

/Peter

> I suppose RTF format will still have unicode issues, maybe because it
> was not planned to use unicode encoding ?
> http://en.wikipedia.org/wiki/Rich_Text_Format#Character_encoding
>
> Peter Landgren a écrit :
> >   Benny,
> > (see below)
> >
> >
> > <snip>
> >
> >  > > In many places of text output, the text is cleaned before writing.
> >  > > Apparently the reformat_para does this here.
> >  > > Some things are not ok:
> >  > >
> >  > > 1/for preformatted text, reformat_para should not be called, it
> >  > > destroys the preformatting
> >  > >
> >  > > 2/for something that is not a note, reformat_para should not remove
> >  > > \n or whitespace.
> >  > >
> >  > > 3/only for real notes that are not preformatted should \n and
> >  > > whitespace be removed.
> >  > >
> >  > > I would suggest to change things as follows:
> >  > >
> >  > > 1/In write_note, set a self.__note = True, and set self.__format =
> >  > > format, unset that at end of note
> >  > > 2/in end_paragraph, only if not preformatted note, do as now. For a
> >  > > preformatted note, do no cleaning of the paragraph, just print it or
> >  > > add line per line to the cell.
> >  > > 3/if not a note is being written, then split on \n, and print the
> >  > > line, if in a cell, add line per line to the cell.
> >  > >
> >  > > So something like:
> >  > >
> >  > > if not self.__format == 'the preformat format'
> >  > > if not self.__note
> >  > > old_lines = para.split('\n')
> >  > > else:
> >  > > old_lines = [para]
> >  > > for line in old_lines:
> >  > > words = line.split()
> >  > > #do as now ...
> >  > > else:
> >  > > for line in para.split(\n)
> >  > > lines.append(line)
> >  > > #continue
> >  > > if just ==
> >  > >
> >  > > Benny
> >  >
> >  > OK.
> >  > I have assigned
> >  > http://www.gramps-project.org/bugs/view.php?id=2848
> >  > to me.
> >  > I see what I can do.
> >  > /Peter
> >
> > This fall we discussed this issue. I have had it in my backlog since.
> > Now I took some time to look at it and I think we were talking about two
> > different notes.
> > Preformatted Notes and the references lines within Endnotes.
> >
> >
> > So I did a test using individ_complete report to look at these two
> > features.
> >
> >
> > Preformatted Endnotes;lines with references Comments
> > -------------------------------------------------------------------------
> >--------- HTML, Firefox etc OK NOT OK; all references on one line
> > Is OK i branch!
> > -------------------------------------------------------------------------
> >--------- ODT, OOWriter OK OK
> > ODT, Kword OK OK
> > -------------------------------------------------------------------------
> >--------- PDF, Adobe Reader OK OK
> > PDF, okular OK OK
> > -------------------------------------------------------------------------
> >--------- RTF, OOWriter Not OK OK Many errors
> > RTF, AbiWord Not OK OK
> > RTF, KWord OK? OK Many errors
> > -------------------------------------------------------------------------
> >--------- TXT, kwrite Not OK NOT OK; all references on one line
> > Double spaced
> > lines
> > -------------------------------------------------------------------------
> >---------
> >
> >
> > After step 1, which only influenced AsciiDoc:
> > -------------------------------------------------------------------------
> >--------- TXT, kwrite OK NOT OK; all references on one line
> > -------------------------------------------------------------------------
> >---------
> >
> >
> > After step 2, which only influenced _Endnotes.py
> >
> >
> > Preformatted Endnotes;lines with references Comments
> > -------------------------------------------------------------------------
> >--------- HTML, Firefox etc OK OK
> > -------------------------------------------------------------------------
> >--------- ODT, OOWriter OK OK
> > ODT, Kword OK OK
> > -------------------------------------------------------------------------
> >--------- PDF, Adobe Reader OK OK
> > PDF, okular OK OK
> > -------------------------------------------------------------------------
> >--------- RTF, OOWriter Not OK OK Many errors
> > RTF, AbiWord Not OK OK
> > RTF, KWord Missing OK Many errors
> > -------------------------------------------------------------------------
> >--------- TXT, kwrite OK OK
> > -------------------------------------------------------------------------
> >---------
> >
> >
> > I have also large generated det_ancestor reports and they look OK with
> > two comments:
> > RTF is not working well.
> > HTML some text and image overlap.
> > Images are made square,looks like projected through a cinemascope lens!
> >
> >
> > Patch files are attached.
> >
> >
> > I'm not sure these fixes are in line with Gramps coding practice,
> > however, they are small.
> > Comments?
> >
> >
> > /Peter
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> >----- This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support A
> > streamlined, 14 day to market process makes app distribution fast and
> > easy Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Gramps-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/gramps-devel

--
Peter Landgren
Talken Hagen
671 94  BRUNSKOG
0570-530 21
070-345 0964
[hidden email]
Skype: pgl4820.2


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Benny Malengier
In reply to this post by Peter Landgren
Peter,

It hurts my head to think about this again.
About Asciidoc patch, you make __note_format a class variable, it
should be an instance variable as you use it as that, so set it in
__init__.

Otherwise, the patch does no strange things. I'd have to see the bug
in output to know what you want to achieve, but I trust you when you
say there is a mishandling and this fixes it.

Benny

2010/1/6 Peter Landgren <[hidden email]>:

> Benny,
> (see below)
>
> <snip>
>
>> > In many places of text output, the text is cleaned before writing.
>> > Apparently the reformat_para does this here.
>> > Some things are not ok:
>> >
>> > 1/for preformatted text, reformat_para should not be called, it
>> > destroys the preformatting
>> >
>> > 2/for something that is not a note, reformat_para should not remove \n
>> > or whitespace.
>> >
>> > 3/only for real notes that are not preformatted should \n and
>> > whitespace be removed.
>> >
>> > I would suggest to change things as follows:
>> >
>> > 1/In write_note, set a self.__note = True, and set self.__format =
>> > format, unset that at end of note
>> > 2/in end_paragraph, only if not preformatted note, do as now. For a
>> > preformatted note, do no cleaning of the paragraph, just print it or
>> > add line per line to the cell.
>> > 3/if not a note is being written, then split on \n, and print the
>> > line, if in a cell, add line per line to the cell.
>> >
>> > So something like:
>> >
>> > if not self.__format == 'the preformat format'
>> > if not self.__note
>> > old_lines = para.split('\n')
>> > else:
>> > old_lines = [para]
>> > for line in old_lines:
>> > words = line.split()
>> > #do as now ...
>> > else:
>> > for line in para.split(\n)
>> > lines.append(line)
>> > #continue
>> > if just ==
>> >
>> > Benny
>>
>> OK.
>> I have assigned
>> http://www.gramps-project.org/bugs/view.php?id=2848
>> to me.
>> I see what I can do.
>> /Peter
>
> This fall we discussed this issue. I have had it in my backlog since.
> Now I took some time to look at it and I think we were talking about two
> different notes.
> Preformatted Notes and the references lines within Endnotes.
>
> So I did a test using individ_complete report to look at these two features.
>
> Preformatted Endnotes;lines with references Comments
> ----------------------------------------------------------------------------------
> HTML, Firefox etc OK NOT OK; all references on one line
> Is OK i branch!
> ----------------------------------------------------------------------------------
> ODT, OOWriter OK OK
> ODT, Kword OK OK
> ----------------------------------------------------------------------------------
> PDF, Adobe Reader OK OK
> PDF, okular OK OK
> ----------------------------------------------------------------------------------
> RTF, OOWriter Not OK OK Many errors
> RTF, AbiWord Not OK OK
> RTF, KWord OK? OK Many errors
> ----------------------------------------------------------------------------------
> TXT, kwrite Not OK NOT OK; all references on one line
> Double spaced
> lines
> ----------------------------------------------------------------------------------
>
> After step 1, which only influenced AsciiDoc:
> ----------------------------------------------------------------------------------
> TXT, kwrite OK NOT OK; all references on one line
> ----------------------------------------------------------------------------------
>
> After step 2, which only influenced _Endnotes.py
>
> Preformatted Endnotes;lines with references Comments
> ----------------------------------------------------------------------------------
> HTML, Firefox etc OK OK
> ----------------------------------------------------------------------------------
> ODT, OOWriter OK OK
> ODT, Kword OK OK
> ----------------------------------------------------------------------------------
> PDF, Adobe Reader OK OK
> PDF, okular OK OK
> ----------------------------------------------------------------------------------
> RTF, OOWriter Not OK OK Many errors
> RTF, AbiWord Not OK OK
> RTF, KWord Missing OK Many errors
> ----------------------------------------------------------------------------------
> TXT, kwrite OK OK
> ----------------------------------------------------------------------------------
>
> I have also large generated det_ancestor reports and they look OK with two
> comments:
> RTF is not working well.
> HTML some text and image overlap.
> Images are made square,looks like projected through a cinemascope lens!
>
> Patch files are attached.
>
> I'm not sure these fixes are in line with Gramps coding practice, however,
> they are small.
> Comments?
>
> /Peter
>
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Peter Landgren
Benny,

There is no __init__ in AsciiDoc.py.
Is it enough with
def __init__():
    __note_format = None

?

I will provide examples with "before" and "after" my work.

/Peter

> Peter,
>
> It hurts my head to think about this again.
> About Asciidoc patch, you make __note_format a class variable, it
> should be an instance variable as you use it as that, so set it in
> __init__.
>
> Otherwise, the patch does no strange things. I'd have to see the bug
> in output to know what you want to achieve, but I trust you when you
> say there is a mishandling and this fixes it.
>
> Benny
>
> 2010/1/6 Peter Landgren <[hidden email]>:
> > Benny,
> > (see below)
> >
> > <snip>
> >
> >> > In many places of text output, the text is cleaned before writing.
> >> > Apparently the reformat_para does this here.
> >> > Some things are not ok:
> >> >
> >> > 1/for preformatted text, reformat_para should not be called, it
> >> > destroys the preformatting
> >> >
> >> > 2/for something that is not a note, reformat_para should not remove \n
> >> > or whitespace.
> >> >
> >> > 3/only for real notes that are not preformatted should \n and
> >> > whitespace be removed.
> >> >
> >> > I would suggest to change things as follows:
> >> >
> >> > 1/In write_note, set a self.__note = True, and set self.__format =
> >> > format, unset that at end of note
> >> > 2/in end_paragraph, only if not preformatted note, do as now. For a
> >> > preformatted note, do no cleaning of the paragraph, just print it or
> >> > add line per line to the cell.
> >> > 3/if not a note is being written, then split on \n, and print the
> >> > line, if in a cell, add line per line to the cell.
> >> >
> >> > So something like:
> >> >
> >> > if not self.__format == 'the preformat format'
> >> > if not self.__note
> >> > old_lines = para.split('\n')
> >> > else:
> >> > old_lines = [para]
> >> > for line in old_lines:
> >> > words = line.split()
> >> > #do as now ...
> >> > else:
> >> > for line in para.split(\n)
> >> > lines.append(line)
> >> > #continue
> >> > if just ==
> >> >
> >> > Benny
> >>
> >> OK.
> >> I have assigned
> >> http://www.gramps-project.org/bugs/view.php?id=2848
> >> to me.
> >> I see what I can do.
> >> /Peter
> >
> > This fall we discussed this issue. I have had it in my backlog since.
> > Now I took some time to look at it and I think we were talking about two
> > different notes.
> > Preformatted Notes and the references lines within Endnotes.
> >
> > So I did a test using individ_complete report to look at these two
> > features.
> >
> > Preformatted Endnotes;lines with references Comments
> > -------------------------------------------------------------------------
> >--------- HTML, Firefox etc OK NOT OK; all references on one line
> > Is OK i branch!
> > -------------------------------------------------------------------------
> >--------- ODT, OOWriter OK OK
> > ODT, Kword OK OK
> > -------------------------------------------------------------------------
> >--------- PDF, Adobe Reader OK OK
> > PDF, okular OK OK
> > -------------------------------------------------------------------------
> >--------- RTF, OOWriter Not OK OK Many errors
> > RTF, AbiWord Not OK OK
> > RTF, KWord OK? OK Many errors
> > -------------------------------------------------------------------------
> >--------- TXT, kwrite Not OK NOT OK; all references on one line
> > Double spaced
> > lines
> > -------------------------------------------------------------------------
> >---------
> >
> > After step 1, which only influenced AsciiDoc:
> > -------------------------------------------------------------------------
> >--------- TXT, kwrite OK NOT OK; all references on one line
> > -------------------------------------------------------------------------
> >---------
> >
> > After step 2, which only influenced _Endnotes.py
> >
> > Preformatted Endnotes;lines with references Comments
> > -------------------------------------------------------------------------
> >--------- HTML, Firefox etc OK OK
> > -------------------------------------------------------------------------
> >--------- ODT, OOWriter OK OK
> > ODT, Kword OK OK
> > -------------------------------------------------------------------------
> >--------- PDF, Adobe Reader OK OK
> > PDF, okular OK OK
> > -------------------------------------------------------------------------
> >--------- RTF, OOWriter Not OK OK Many errors
> > RTF, AbiWord Not OK OK
> > RTF, KWord Missing OK Many errors
> > -------------------------------------------------------------------------
> >--------- TXT, kwrite OK OK
> > -------------------------------------------------------------------------
> >---------
> >
> > I have also large generated det_ancestor reports and they look OK with
> > two comments:
> > RTF is not working well.
> > HTML some text and image overlap.
> > Images are made square,looks like projected through a cinemascope lens!
> >
> > Patch files are attached.
> >
> > I'm not sure these fixes are in line with Gramps coding practice,
> > however, they are small.
> > Comments?
> >
> > /Peter


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Benny Malengier
2010/1/10 Peter Landgren <[hidden email]>:
> Benny,
>
> There is no __init__ in AsciiDoc.py.
> Is it enough with
> def __init__():
>    __note_format = None

BaseDoc has an init, so

def __init__(self):
    BaseDoc.__init__(self)
    self.__note_format = None

Benny

>
> ?
>
> I will provide examples with "before" and "after" my work.
>
> /Peter
>
>> Peter,
>>
>> It hurts my head to think about this again.
>> About Asciidoc patch, you make __note_format a class variable, it
>> should be an instance variable as you use it as that, so set it in
>> __init__.
>>
>> Otherwise, the patch does no strange things. I'd have to see the bug
>> in output to know what you want to achieve, but I trust you when you
>> say there is a mishandling and this fixes it.
>>
>> Benny
>>
>> 2010/1/6 Peter Landgren <[hidden email]>:
>> > Benny,
>> > (see below)
>> >
>> > <snip>
>> >
>> >> > In many places of text output, the text is cleaned before writing.
>> >> > Apparently the reformat_para does this here.
>> >> > Some things are not ok:
>> >> >
>> >> > 1/for preformatted text, reformat_para should not be called, it
>> >> > destroys the preformatting
>> >> >
>> >> > 2/for something that is not a note, reformat_para should not remove \n
>> >> > or whitespace.
>> >> >
>> >> > 3/only for real notes that are not preformatted should \n and
>> >> > whitespace be removed.
>> >> >
>> >> > I would suggest to change things as follows:
>> >> >
>> >> > 1/In write_note, set a self.__note = True, and set self.__format =
>> >> > format, unset that at end of note
>> >> > 2/in end_paragraph, only if not preformatted note, do as now. For a
>> >> > preformatted note, do no cleaning of the paragraph, just print it or
>> >> > add line per line to the cell.
>> >> > 3/if not a note is being written, then split on \n, and print the
>> >> > line, if in a cell, add line per line to the cell.
>> >> >
>> >> > So something like:
>> >> >
>> >> > if not self.__format == 'the preformat format'
>> >> > if not self.__note
>> >> > old_lines = para.split('\n')
>> >> > else:
>> >> > old_lines = [para]
>> >> > for line in old_lines:
>> >> > words = line.split()
>> >> > #do as now ...
>> >> > else:
>> >> > for line in para.split(\n)
>> >> > lines.append(line)
>> >> > #continue
>> >> > if just ==
>> >> >
>> >> > Benny
>> >>
>> >> OK.
>> >> I have assigned
>> >> http://www.gramps-project.org/bugs/view.php?id=2848
>> >> to me.
>> >> I see what I can do.
>> >> /Peter
>> >
>> > This fall we discussed this issue. I have had it in my backlog since.
>> > Now I took some time to look at it and I think we were talking about two
>> > different notes.
>> > Preformatted Notes and the references lines within Endnotes.
>> >
>> > So I did a test using individ_complete report to look at these two
>> > features.
>> >
>> > Preformatted Endnotes;lines with references Comments
>> > -------------------------------------------------------------------------
>> >--------- HTML, Firefox etc OK NOT OK; all references on one line
>> > Is OK i branch!
>> > -------------------------------------------------------------------------
>> >--------- ODT, OOWriter OK OK
>> > ODT, Kword OK OK
>> > -------------------------------------------------------------------------
>> >--------- PDF, Adobe Reader OK OK
>> > PDF, okular OK OK
>> > -------------------------------------------------------------------------
>> >--------- RTF, OOWriter Not OK OK Many errors
>> > RTF, AbiWord Not OK OK
>> > RTF, KWord OK? OK Many errors
>> > -------------------------------------------------------------------------
>> >--------- TXT, kwrite Not OK NOT OK; all references on one line
>> > Double spaced
>> > lines
>> > -------------------------------------------------------------------------
>> >---------
>> >
>> > After step 1, which only influenced AsciiDoc:
>> > -------------------------------------------------------------------------
>> >--------- TXT, kwrite OK NOT OK; all references on one line
>> > -------------------------------------------------------------------------
>> >---------
>> >
>> > After step 2, which only influenced _Endnotes.py
>> >
>> > Preformatted Endnotes;lines with references Comments
>> > -------------------------------------------------------------------------
>> >--------- HTML, Firefox etc OK OK
>> > -------------------------------------------------------------------------
>> >--------- ODT, OOWriter OK OK
>> > ODT, Kword OK OK
>> > -------------------------------------------------------------------------
>> >--------- PDF, Adobe Reader OK OK
>> > PDF, okular OK OK
>> > -------------------------------------------------------------------------
>> >--------- RTF, OOWriter Not OK OK Many errors
>> > RTF, AbiWord Not OK OK
>> > RTF, KWord Missing OK Many errors
>> > -------------------------------------------------------------------------
>> >--------- TXT, kwrite OK OK
>> > -------------------------------------------------------------------------
>> >---------
>> >
>> > I have also large generated det_ancestor reports and they look OK with
>> > two comments:
>> > RTF is not working well.
>> > HTML some text and image overlap.
>> > Images are made square,looks like projected through a cinemascope lens!
>> >
>> > Patch files are attached.
>> >
>> > I'm not sure these fixes are in line with Gramps coding practice,
>> > however, they are small.
>> > Comments?
>> >
>> > /Peter
>
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Benny Malengier
2010/1/10 Benny Malengier <[hidden email]>:

> 2010/1/10 Peter Landgren <[hidden email]>:
>> Benny,
>>
>> There is no __init__ in AsciiDoc.py.
>> Is it enough with
>> def __init__():
>>    __note_format = None
>
> BaseDoc has an init, so
>
> def __init__(self):
>    BaseDoc.__init__(self)
>    self.__note_format = None

You don't check on None, and set it everytime when you use it to the
correct value, that is why it worked. So perhaps better to set it to
False.

>
> Benny
>>
>> ?
>>
>> I will provide examples with "before" and "after" my work.
>>
>> /Peter
>>
>>> Peter,
>>>
>>> It hurts my head to think about this again.
>>> About Asciidoc patch, you make __note_format a class variable, it
>>> should be an instance variable as you use it as that, so set it in
>>> __init__.
>>>
>>> Otherwise, the patch does no strange things. I'd have to see the bug
>>> in output to know what you want to achieve, but I trust you when you
>>> say there is a mishandling and this fixes it.
>>>
>>> Benny
>>>
>>> 2010/1/6 Peter Landgren <[hidden email]>:
>>> > Benny,
>>> > (see below)
>>> >
>>> > <snip>
>>> >
>>> >> > In many places of text output, the text is cleaned before writing.
>>> >> > Apparently the reformat_para does this here.
>>> >> > Some things are not ok:
>>> >> >
>>> >> > 1/for preformatted text, reformat_para should not be called, it
>>> >> > destroys the preformatting
>>> >> >
>>> >> > 2/for something that is not a note, reformat_para should not remove \n
>>> >> > or whitespace.
>>> >> >
>>> >> > 3/only for real notes that are not preformatted should \n and
>>> >> > whitespace be removed.
>>> >> >
>>> >> > I would suggest to change things as follows:
>>> >> >
>>> >> > 1/In write_note, set a self.__note = True, and set self.__format =
>>> >> > format, unset that at end of note
>>> >> > 2/in end_paragraph, only if not preformatted note, do as now. For a
>>> >> > preformatted note, do no cleaning of the paragraph, just print it or
>>> >> > add line per line to the cell.
>>> >> > 3/if not a note is being written, then split on \n, and print the
>>> >> > line, if in a cell, add line per line to the cell.
>>> >> >
>>> >> > So something like:
>>> >> >
>>> >> > if not self.__format == 'the preformat format'
>>> >> > if not self.__note
>>> >> > old_lines = para.split('\n')
>>> >> > else:
>>> >> > old_lines = [para]
>>> >> > for line in old_lines:
>>> >> > words = line.split()
>>> >> > #do as now ...
>>> >> > else:
>>> >> > for line in para.split(\n)
>>> >> > lines.append(line)
>>> >> > #continue
>>> >> > if just ==
>>> >> >
>>> >> > Benny
>>> >>
>>> >> OK.
>>> >> I have assigned
>>> >> http://www.gramps-project.org/bugs/view.php?id=2848
>>> >> to me.
>>> >> I see what I can do.
>>> >> /Peter
>>> >
>>> > This fall we discussed this issue. I have had it in my backlog since.
>>> > Now I took some time to look at it and I think we were talking about two
>>> > different notes.
>>> > Preformatted Notes and the references lines within Endnotes.
>>> >
>>> > So I did a test using individ_complete report to look at these two
>>> > features.
>>> >
>>> > Preformatted Endnotes;lines with references Comments
>>> > -------------------------------------------------------------------------
>>> >--------- HTML, Firefox etc OK NOT OK; all references on one line
>>> > Is OK i branch!
>>> > -------------------------------------------------------------------------
>>> >--------- ODT, OOWriter OK OK
>>> > ODT, Kword OK OK
>>> > -------------------------------------------------------------------------
>>> >--------- PDF, Adobe Reader OK OK
>>> > PDF, okular OK OK
>>> > -------------------------------------------------------------------------
>>> >--------- RTF, OOWriter Not OK OK Many errors
>>> > RTF, AbiWord Not OK OK
>>> > RTF, KWord OK? OK Many errors
>>> > -------------------------------------------------------------------------
>>> >--------- TXT, kwrite Not OK NOT OK; all references on one line
>>> > Double spaced
>>> > lines
>>> > -------------------------------------------------------------------------
>>> >---------
>>> >
>>> > After step 1, which only influenced AsciiDoc:
>>> > -------------------------------------------------------------------------
>>> >--------- TXT, kwrite OK NOT OK; all references on one line
>>> > -------------------------------------------------------------------------
>>> >---------
>>> >
>>> > After step 2, which only influenced _Endnotes.py
>>> >
>>> > Preformatted Endnotes;lines with references Comments
>>> > -------------------------------------------------------------------------
>>> >--------- HTML, Firefox etc OK OK
>>> > -------------------------------------------------------------------------
>>> >--------- ODT, OOWriter OK OK
>>> > ODT, Kword OK OK
>>> > -------------------------------------------------------------------------
>>> >--------- PDF, Adobe Reader OK OK
>>> > PDF, okular OK OK
>>> > -------------------------------------------------------------------------
>>> >--------- RTF, OOWriter Not OK OK Many errors
>>> > RTF, AbiWord Not OK OK
>>> > RTF, KWord Missing OK Many errors
>>> > -------------------------------------------------------------------------
>>> >--------- TXT, kwrite OK OK
>>> > -------------------------------------------------------------------------
>>> >---------
>>> >
>>> > I have also large generated det_ancestor reports and they look OK with
>>> > two comments:
>>> > RTF is not working well.
>>> > HTML some text and image overlap.
>>> > Images are made square,looks like projected through a cinemascope lens!
>>> >
>>> > Patch files are attached.
>>> >
>>> > I'm not sure these fixes are in line with Gramps coding practice,
>>> > however, they are small.
>>> > Comments?
>>> >
>>> > /Peter
>>
>>
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Peter Landgren
> 2010/1/10 Benny Malengier <[hidden email]>:
> > 2010/1/10 Peter Landgren <[hidden email]>:
> >> Benny,
> >>
> >> There is no __init__ in AsciiDoc.py.
> >> Is it enough with
> >> def __init__():
> >>    __note_format = None
> >
> > BaseDoc has an init, so
> >
> > def __init__(self):
> >    BaseDoc.__init__(self)
> >    self.__note_format = None
>
> You don't check on None, and set it everytime when you use it to the
> correct value, that is why it worked. So perhaps better to set it to
> False.

My mind was thinking False, but my fingers wrote None.

The main problem with this issue is that the method "write_note" is used to write both Notes and
Endnotes references in AsciiDoc and RTFDoc. All other output formats use "write_styled_note" for
notes. All formats use "write_note" for end notes references.

To make in clear what is done by whom, I have renamed "write_note" to "write-endnotes_ref", which
describes what it does and added "write_styled_note" to AsciiDoc and RTFDoc.

The remaining problem now is the notes and end notes references for LaTex output. The left margin is
big. I will look at this some more.

I also found that the end notes references uses a monospace font in HTML and ODT output. Any special
reason for this?
I can change it in ODTDoc, but my HTML knowledge is not good enough to do that in HTMLDoc
 
/Peter

> >>> Peter,
> >>>
> >>> It hurts my head to think about this again.
> >>> About Asciidoc patch, you make __note_format a class variable, it
> >>> should be an instance variable as you use it as that, so set it in
> >>> __init__.
> >>>
> >>> Otherwise, the patch does no strange things. I'd have to see the bug
> >>> in output to know what you want to achieve, but I trust you when you
> >>> say there is a mishandling and this fixes it.
> >>>
> >>> Benny
> >>>
> >>> 2010/1/6 Peter Landgren <[hidden email]>:
> >>> > Benny,
> >>> > (see below)
> >>> >
> >>> > <snip>
> >>> >
> >>> >> > In many places of text output, the text is cleaned before writing.
> >>> >> > Apparently the reformat_para does this here.
> >>> >> > Some things are not ok:
> >>> >> >
> >>> >> > 1/for preformatted text, reformat_para should not be called, it
> >>> >> > destroys the preformatting
> >>> >> >
> >>> >> > 2/for something that is not a note, reformat_para should not
> >>> >> > remove \n or whitespace.
> >>> >> >
> >>> >> > 3/only for real notes that are not preformatted should \n and
> >>> >> > whitespace be removed.
> >>> >> >
> >>> >> > I would suggest to change things as follows:
> >>> >> >
> >>> >> > 1/In write_note, set a self.__note = True, and set self.__format =
> >>> >> > format, unset that at end of note
> >>> >> > 2/in end_paragraph, only if not preformatted note, do as now. For
> >>> >> > a preformatted note, do no cleaning of the paragraph, just print
> >>> >> > it or add line per line to the cell.
> >>> >> > 3/if not a note is being written, then split on \n, and print the
> >>> >> > line, if in a cell, add line per line to the cell.
> >>> >> >
> >>> >> > So something like:
> >>> >> >
> >>> >> > if not self.__format == 'the preformat format'
> >>> >> > if not self.__note
> >>> >> > old_lines = para.split('\n')
> >>> >> > else:
> >>> >> > old_lines = [para]
> >>> >> > for line in old_lines:
> >>> >> > words = line.split()
> >>> >> > #do as now ...
> >>> >> > else:
> >>> >> > for line in para.split(\n)
> >>> >> > lines.append(line)
> >>> >> > #continue
> >>> >> > if just ==
> >>> >> >
> >>> >> > Benny
> >>> >>
> >>> >> OK.
> >>> >> I have assigned
> >>> >> http://www.gramps-project.org/bugs/view.php?id=2848
> >>> >> to me.
> >>> >> I see what I can do.
> >>> >> /Peter
> >>> >
> >>> > This fall we discussed this issue. I have had it in my backlog since.
> >>> > Now I took some time to look at it and I think we were talking about
> >>> > two different notes.
> >>> > Preformatted Notes and the references lines within Endnotes.
> >>> >
> >>> > So I did a test using individ_complete report to look at these two
> >>> > features.
> >>> >
> >>> > Preformatted Endnotes;lines with references Comments
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- HTML, Firefox etc OK NOT OK; all references on one line
> >>> > Is OK i branch!
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- ODT, OOWriter OK OK
> >>> > ODT, Kword OK OK
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- PDF, Adobe Reader OK OK
> >>> > PDF, okular OK OK
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- RTF, OOWriter Not OK OK Many errors
> >>> > RTF, AbiWord Not OK OK
> >>> > RTF, KWord OK? OK Many errors
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- TXT, kwrite Not OK NOT OK; all references on one line
> >>> > Double spaced
> >>> > lines
> >>> > ---------------------------------------------------------------------
> >>> >---- ---------
> >>> >
> >>> > After step 1, which only influenced AsciiDoc:
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- TXT, kwrite OK NOT OK; all references on one line
> >>> > ---------------------------------------------------------------------
> >>> >---- ---------
> >>> >
> >>> > After step 2, which only influenced _Endnotes.py
> >>> >
> >>> > Preformatted Endnotes;lines with references Comments
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- HTML, Firefox etc OK OK
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- ODT, OOWriter OK OK
> >>> > ODT, Kword OK OK
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- PDF, Adobe Reader OK OK
> >>> > PDF, okular OK OK
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- RTF, OOWriter Not OK OK Many errors
> >>> > RTF, AbiWord Not OK OK
> >>> > RTF, KWord Missing OK Many errors
> >>> > ---------------------------------------------------------------------
> >>> >---- --------- TXT, kwrite OK OK
> >>> > ---------------------------------------------------------------------
> >>> >---- ---------
> >>> >
> >>> > I have also large generated det_ancestor reports and they look OK
> >>> > with two comments:
> >>> > RTF is not working well.
> >>> > HTML some text and image overlap.
> >>> > Images are made square,looks like projected through a cinemascope
> >>> > lens!
> >>> >
> >>> > Patch files are attached.
> >>> >
> >>> > I'm not sure these fixes are in line with Gramps coding practice,
> >>> > however, they are small.
> >>> > Comments?
> >>> >
> >>> > /Peter

--
Peter Landgren
Talken Hagen
671 94  BRUNSKOG
0570-530 21
070-345 0964
[hidden email]
Skype: pgl4820.2


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question about an old issue

Benny Malengier
2010/1/13 Peter Landgren <[hidden email]>:

>> 2010/1/10 Benny Malengier <[hidden email]>:
>> > 2010/1/10 Peter Landgren <[hidden email]>:
>> >> Benny,
>> >>
>> >> There is no __init__ in AsciiDoc.py.
>> >> Is it enough with
>> >> def __init__():
>> >>    __note_format = None
>> >
>> > BaseDoc has an init, so
>> >
>> > def __init__(self):
>> >    BaseDoc.__init__(self)
>> >    self.__note_format = None
>>
>> You don't check on None, and set it everytime when you use it to the
>> correct value, that is why it worked. So perhaps better to set it to
>> False.
>
> My mind was thinking False, but my fingers wrote None.
>
> The main problem with this issue is that the method "write_note" is used to write both Notes and
> Endnotes references in AsciiDoc and RTFDoc. All other output formats use "write_styled_note" for
> notes. All formats use "write_note" for end notes references.
>
> To make in clear what is done by whom, I have renamed "write_note" to "write-endnotes_ref", which
> describes what it does and added "write_styled_note" to AsciiDoc and RTFDoc.

ok
write_note was the old method, before styled notes exist. It was
present for compatibility reasons. It is indeed better to or use a
specific name for note objects, or use a specific name for reference
endnotes. Now we have both :-)

Benny

>
> The remaining problem now is the notes and end notes references for LaTex output. The left margin is
> big. I will look at this some more.
>
> I also found that the end notes references uses a monospace font in HTML and ODT output. Any special
> reason for this?
> I can change it in ODTDoc, but my HTML knowledge is not good enough to do that in HTMLDoc
>
> /Peter
>
>> >>> Peter,
>> >>>
>> >>> It hurts my head to think about this again.
>> >>> About Asciidoc patch, you make __note_format a class variable, it
>> >>> should be an instance variable as you use it as that, so set it in
>> >>> __init__.
>> >>>
>> >>> Otherwise, the patch does no strange things. I'd have to see the bug
>> >>> in output to know what you want to achieve, but I trust you when you
>> >>> say there is a mishandling and this fixes it.
>> >>>
>> >>> Benny
>> >>>
>> >>> 2010/1/6 Peter Landgren <[hidden email]>:
>> >>> > Benny,
>> >>> > (see below)
>> >>> >
>> >>> > <snip>
>> >>> >
>> >>> >> > In many places of text output, the text is cleaned before writing.
>> >>> >> > Apparently the reformat_para does this here.
>> >>> >> > Some things are not ok:
>> >>> >> >
>> >>> >> > 1/for preformatted text, reformat_para should not be called, it
>> >>> >> > destroys the preformatting
>> >>> >> >
>> >>> >> > 2/for something that is not a note, reformat_para should not
>> >>> >> > remove \n or whitespace.
>> >>> >> >
>> >>> >> > 3/only for real notes that are not preformatted should \n and
>> >>> >> > whitespace be removed.
>> >>> >> >
>> >>> >> > I would suggest to change things as follows:
>> >>> >> >
>> >>> >> > 1/In write_note, set a self.__note = True, and set self.__format =
>> >>> >> > format, unset that at end of note
>> >>> >> > 2/in end_paragraph, only if not preformatted note, do as now. For
>> >>> >> > a preformatted note, do no cleaning of the paragraph, just print
>> >>> >> > it or add line per line to the cell.
>> >>> >> > 3/if not a note is being written, then split on \n, and print the
>> >>> >> > line, if in a cell, add line per line to the cell.
>> >>> >> >
>> >>> >> > So something like:
>> >>> >> >
>> >>> >> > if not self.__format == 'the preformat format'
>> >>> >> > if not self.__note
>> >>> >> > old_lines = para.split('\n')
>> >>> >> > else:
>> >>> >> > old_lines = [para]
>> >>> >> > for line in old_lines:
>> >>> >> > words = line.split()
>> >>> >> > #do as now ...
>> >>> >> > else:
>> >>> >> > for line in para.split(\n)
>> >>> >> > lines.append(line)
>> >>> >> > #continue
>> >>> >> > if just ==
>> >>> >> >
>> >>> >> > Benny
>> >>> >>
>> >>> >> OK.
>> >>> >> I have assigned
>> >>> >> http://www.gramps-project.org/bugs/view.php?id=2848
>> >>> >> to me.
>> >>> >> I see what I can do.
>> >>> >> /Peter
>> >>> >
>> >>> > This fall we discussed this issue. I have had it in my backlog since.
>> >>> > Now I took some time to look at it and I think we were talking about
>> >>> > two different notes.
>> >>> > Preformatted Notes and the references lines within Endnotes.
>> >>> >
>> >>> > So I did a test using individ_complete report to look at these two
>> >>> > features.
>> >>> >
>> >>> > Preformatted Endnotes;lines with references Comments
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- HTML, Firefox etc OK NOT OK; all references on one line
>> >>> > Is OK i branch!
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- ODT, OOWriter OK OK
>> >>> > ODT, Kword OK OK
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- PDF, Adobe Reader OK OK
>> >>> > PDF, okular OK OK
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- RTF, OOWriter Not OK OK Many errors
>> >>> > RTF, AbiWord Not OK OK
>> >>> > RTF, KWord OK? OK Many errors
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- TXT, kwrite Not OK NOT OK; all references on one line
>> >>> > Double spaced
>> >>> > lines
>> >>> > ---------------------------------------------------------------------
>> >>> >---- ---------
>> >>> >
>> >>> > After step 1, which only influenced AsciiDoc:
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- TXT, kwrite OK NOT OK; all references on one line
>> >>> > ---------------------------------------------------------------------
>> >>> >---- ---------
>> >>> >
>> >>> > After step 2, which only influenced _Endnotes.py
>> >>> >
>> >>> > Preformatted Endnotes;lines with references Comments
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- HTML, Firefox etc OK OK
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- ODT, OOWriter OK OK
>> >>> > ODT, Kword OK OK
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- PDF, Adobe Reader OK OK
>> >>> > PDF, okular OK OK
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- RTF, OOWriter Not OK OK Many errors
>> >>> > RTF, AbiWord Not OK OK
>> >>> > RTF, KWord Missing OK Many errors
>> >>> > ---------------------------------------------------------------------
>> >>> >---- --------- TXT, kwrite OK OK
>> >>> > ---------------------------------------------------------------------
>> >>> >---- ---------
>> >>> >
>> >>> > I have also large generated det_ancestor reports and they look OK
>> >>> > with two comments:
>> >>> > RTF is not working well.
>> >>> > HTML some text and image overlap.
>> >>> > Images are made square,looks like projected through a cinemascope
>> >>> > lens!
>> >>> >
>> >>> > Patch files are attached.
>> >>> >
>> >>> > I'm not sure these fixes are in line with Gramps coding practice,
>> >>> > however, they are small.
>> >>> > Comments?
>> >>> >
>> >>> > /Peter
>
> --
> Peter Landgren
> Talken Hagen
> 671 94  BRUNSKOG
> 0570-530 21
> 070-345 0964
> [hidden email]
> Skype: pgl4820.2
>
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel