Re: problems with decimal number display by PSPP

[John Darrington]

Can you please try the version at https://filebin.net/bstuzsoqrx04mo7w

and tell us whether this version also shows the problem.

Thanks.

On Sat, Apr 17, 2021 at 12:28:14PM +0000, hector morada wrote:
      Guys,
     
     Given my age (71 years) and academic and work background, I won't be able 
to keep pace with you.
     
     I had one of my sons install PSPP 1.4.1 in his notebook that run under 
Windows 10. We  ran the same set of data I furnished John earlier. To my 
pleasant surprise, the ghost special character did not appear!
     
     I uninstalled the PSPP in my notebook, an old DELL running under Windows 
7. 
     
     I installed an older PSPP version as indicated below:
     
     pspp-20181109-setup
     GNU pspp 1.2.0-g0fb4db
     
     which I downloaded from https://www.tonyknowles.com/pspp-statistics/
     
     I tested it with same set of data. The ghost special character is nowhere 
to be found.
     
     I am very proud to have met the two of you. Your kind of guys form part of 
my "classroom" examples of unselfish professionals who share their knowledge 
and skill to others.
     
     I will not speculate on the current problem.  Some of my students are 
submitting PSPP outputs with that special character attached to numbers with 
ABS(value) < than 1.
     
     Thank you very much and I am praying that the said "bug" could be found 
and eventually be exorcised out of the PSPP system!
     
     
     
     
         On Saturday, April 17, 2021, 2:55:23 PM GMT+8, John Darrington 
<john@darrington.wattle.id.au> wrote:  
      
      Thanks Ben,
     
     Looking at this, I'm inclined to think you're right.
     
     We're still however speculating about the cause.  For most users this
     problem does not manifest itself, so I guess there is some particular
     combination of platform, operating system, (locale?), cairo version,
     which gives rise to it.  So I think the onus is on the people who are
     actually experiencing the issue to demonstrate a reproducible set of
     conditions under which it occurs.
     
     When we can reproduce the problem, we have a chance of finding the cause
     and fixing it.
     
     J'
     
     
     On Fri, Apr 16, 2021 at 10:58:07AM -0700, Ben Pfaff wrote:
         I think it's more likely to be the following code in cairo-fsm.c that
         tries to avoid wordwrapping.
         I don't know why U+2060 WORD JOINER is showing up as U+0000 on Windows.
         I guess we could add #ifndef __WIN32__ and see if it goes away.
         
             if (decimal[0]
                   && c_isdigit (decimal[1])
                   && (decimal == text || !c_isdigit (decimal[-1])))
                 {
                   struct string tmp = DS_EMPTY_INITIALIZER;
                   ds_extend (&tmp, ds_length (&body) + 16);
                   markup_escape (&tmp, markup, text, decimal - text + 1);
                   ds_put_unichar (&tmp, 0x2060 /* U+2060 WORD JOINER */);
                   markup_escape (&tmp, markup, decimal + 1, -1);
                   ds_swap (&tmp, &body);
                   ds_destroy (&tmp);
                 }
         
         On Fri, Apr 16, 2021 at 8:26 AM John Darrington
         <john@darrington.wattle.id.au> wrote:
         >
         > After a fair bit of effort, I have been unable to reproduce this 
problem.
         >
         > So if this issue is to have any chance of getting fixed someone who 
is
         > experiencing it is going to  need to give us a backtrace.
         >
         > Looking through the code, I consider the most likely function of 
interest
         > is  output_decimal in src/data/data-out.c - in particular this bit 
of code
         > seems most relevant:
         >
         >      if (decimals > 0)
         >        {
         >          *p++ = style->decimal;
         >          p = mempcpy (p, &magnitude[integer_digits + 1], decimals);
         >        }
         >
         > However I can't see anything actually wrong here.  I suggest that you
         > put a breakpoint here conditional upon *p == 0 ... hopefully that 
might
         > provide something of interest.
         >
         > J'