Re: [lmi] wx assertion failure: invalid font

[Greg Chicares]

On 2018-10-02 16:11, Vadim Zeitlin wrote:
> On Tue, 2 Oct 2018 14:30:37 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC>   Assertion '"IsOk"' failed
> GC>   (invalid font).
> GC>   [file cache_for_lmi/vcs/wxWidgets/src/msw/font.cpp, line 981]
> 
>  The previously promised pull request fixing this is here:
> 
>       https://github.com/vadz/lmi/pull/97
> 
>  I think it's simple enough to be applied immediately in order to fix the
> problem, even though I admit that I don't completely understand what's

It prevents the assertion, so I've committed it, rebasing it to precede
my MST changes that require it. I'll push soon, after testing, but already
I see a couple of weird things that I'll mention below.

> going on here, i.e. where exactly is the invalid font being used before
> another one is being set, but it's clear that it is and there doesn't seem
> to be any good reason to set an invalid font in the first place (I had my
> doubts about doing it when writing this code, but somehow convinced myself
> that it was fine because the font was always going to be changed to
> something valid immediately afterwards by wxHTML -- which just shows that I
> shouldn't trust myself). Also, I'm almost sure that the changes to
> pdf_writer_wx.cpp are not actually needed, but I've done them nevertheless
> for consistency with ledger_pdf_generator_wx.cpp.
First of all, let me ask a question about your patch:

-    wxDCFontChanger preserve_font(pdf_dc_, wxFont());
+    wxDCFontChanger preserve_font(pdf_dc_, *wxNORMAL_FONT);

I understand the newer line, but what did the older one do? The online wx
documentation says only that it's a default ctor, and I would have guessed
that it would construct a valid wxFont object, perhaps even using
  wxSystemSettings::GetFont(wxSYS_DEFAULT_GUI_FONT)
as wxNORMAL_FONT does--but obviously it doesn't do that, or the patch would
have no effect. Does the default ctor make a copy of the DC's current font
(that would be my next guess)? Or does it construct a deliberately invalid
object?

If it copies the current font, then...doesn't that mean that the font is
invalid at the point where any line changed by the patch is reached? If so,
then even after this patch don't we still have a defect somewhere?

Here are some concrete observations, with all the changes that I intend
to push soon (if they pass all tests):

 - On the 'wine' console, I see this, which I've never seen before:

   wxPdfFontManagerBase::GetFont: Font 'Tahoma' with style 'Regular' not found.

 - When I use the original instructions to reproduce the reported problem,
a PDF is created, but some lines look wrong. On page five, I see:
  {PolicyMktgName} is a {PolicyLegalName} issued by {InsCoName}. 
{ProductDescription}
in a tinier font than I remember seeing previously, and with strange
spacing between words--e.g., the spacing looks like:
  X     is  a  Y     issued   by  Z.
On page six, these lines exhibit the same symptoms: a tiny font, and
extraordinarily wide spacing that I'll show here as " | ":
  {GuarMortalityFootnote}
  The loan interest | rate may be fixed or adjustable | as elected | by the 
policy owner.
  The illustration | does not assume | any mortality | experience rating.

It seems best to push all of this now, even though it's imperfect, in order
to make sure we're seeing the same thing, and also because I imagine we'll
figure out how to perfect it soon. It could be that I have in effect placed
a <font> tag inside a <header> tag, and the proper fix is to rework my MST
changes.

Interestingly perhaps, the GUI test runs without error, but the "Tahoma" message
appears on the console:

/opt/lmi/bin[0]$/opt/lmi/src/lmi/gui_test.sh
NOTE: starting the test suite
wxPdfFontManagerBase::GetFont: Font 'Tahoma' with style 'Regular' not found.
SUCCESS: 21 tests successfully completed.
NOTE: 4 tests were skipped
/opt/lmi/bin[0]$

But every other test worked:

/opt/lmi/src/lmi[0]$./nychthemeral_test.sh 2>&1 | tee /tmp/lmi/logs/log | sed 
-f errors.sed
Production system built--ready to start GUI test in another session.
Do not forget to run wx_test.

and my cursory inspection of one PDF for each ledger type revealed nothing
except as noted above, so I'll push now.