lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Assert failure in output_super_header()


From: Greg Chicares
Subject: Re: [lmi] Assert failure in output_super_header()
Date: Tue, 28 Aug 2018 12:39:38 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

[...replying on the public list, as you had long ago given me
permission to do...]

On 2018-08-27 20:02, Vadim Zeitlin wrote:
> On Mon, 27 Aug 2018 16:58:38 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-08-25 19:51, Vadim Zeitlin wrote:
> GC> >  Hello,
> GC> > 
> GC> >  While testing PDF illustration changes, I'm getting failures of this
> GC> > assert
> GC> > 
> GC> >         LMI_ASSERT(dc().GetTextExtent(i).x <= rect.width)
> GC> > 
> GC> > in wx_table_generator::output_super_header(). This happens with the
> GC> > large-in-dollars.ill file, when just pressing Ctrl-I to create the PDF.
> GC> > 
> GC> >  Should I look into this or is this something you're already/still 
> working
> GC> > on?
> GC> 
> GC> Yes, please look into it. I cannot reproduce it here now, using this file:
> GC> 
> GC> $ls -o /opt/lmi/input/large-in-dollars.ill 
> GC> -rwxr-x--- 1 greg 9915 Mar  2 13:14 /opt/lmi/input/large-in-dollars.ill
> GC> $md5sum /opt/lmi/input/large-in-dollars.ill
> GC> 0f45f751b9856a33813505c911737c97  /opt/lmi/input/large-in-dollars.ill

Examining my email archives, I couldn't readily find the original I had
shared with you, but the md5sum above matches the one we were discussing
in March, e.g., here:

https://lists.nongnu.org/archive/html/lmi/2018-03/msg00052.html
| Just to be sure:
|
| $md5sum large-in-dollars.ill
| 0f45f751b9856a33813505c911737c97  large-in-dollars.ill

But I think I can figure it out...

> GC> and I don't think I've ever seen it occur anywhere.
> 
>  Strangely enough, my file is 9919 bytes long (and has a different MD5

The PDF you attached presumably reflects an input change:
- sample
+ sample2ipp
which would account for a four-byte difference. (I'm pretty sure
about this because I recognize the "ipp" format in the PDF you
attached, and the numerical contents seem identical to what I
produce here.)

> hash, of course), although I have no memories of changing it. In any case,
> I don't think its contents is really the problem: the asserts happen
> because the width of "x.00% Hypothetical Rate of" superheaders is just
> noticeably greater than the width of the column: by adding wxLog statements
> to the code, I see that the width of the header line is 121px while the
> column width is either 109 or 110px. Besides the attached file shows that
> it is indeed wider, see page 2 for example.

Yes, on your PDF, the easiest way to see this is that the superheader
text is wider than the horizontal dark-blue rule just below it.

>  Worse, IMO, the actual values don't fit neither, notably in the "Death
> Benefit" columns, yet I don't get any warnings about this. Nor do I see any
> way to compress the table in any way, the values just don't fit... I'm not
> really sure what, if anything, would you like me to do here?
> 
>  One thing I'd really like to understand is why are we seeing different
> results. For the record, I'm running lmi built using the official makefiles
> in my lmi-specific MSW 7 VM.
> 
>  Do you have any idea about what could explain the difference?

Perhaps you're using a branch that has a different set of font sizes?
The font in your tables seems larger than the one in narrative text.

I'll send you my PDF, produced with lmi HEAD and with the original
input file (md5sum above) modified only as indicated above. The
layout of mine is fine: the tables are nicely spaced, and the
superheader does fit. I'll also send both your PDF and mine to Kim,
hoping that she can run one that'll look like mine. If not, then I
think we could fix it by changing

- 0.00% Hypothetical Rate of
-          Return

to

+ 0.00% Hypothetical
+   Rate of Return

which seems more attractive anyway. I would imagine that the
original XSL-FO template set as much text as would fit on the
first line, continuing with "Return" on the next line--without
considering whether the result looks good.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]