lmi
[Top][All Lists]
Advanced

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

Re: [lmi] wx assertion failure: invalid font


From: Vadim Zeitlin
Subject: Re: [lmi] wx assertion failure: invalid font
Date: Tue, 2 Oct 2018 20:41:30 +0200

On Tue, 2 Oct 2018 17:44:43 +0000 Greg Chicares <address@hidden> wrote:

GC> First of all, let me ask a question about your patch:
GC> 
GC> -    wxDCFontChanger preserve_font(pdf_dc_, wxFont());
GC> +    wxDCFontChanger preserve_font(pdf_dc_, *wxNORMAL_FONT);
GC> 
GC> I understand the newer line, but what did the older one do?

 It sets an invalid, null, font as the current font. In principle, this is
allowed by wxDC API, but the trouble is that you can't use this font then
and wxHTML currently does use it, in the function where the assert used to
happen. It probably could be argued that wxHTML should check if the font is
valid, but this would just hide, not solve, the underlying problem (whatever
it is).

GC> The online wx documentation says only that it's a default ctor, and I
GC> would have guessed that it would construct a valid wxFont object,

 No, it constructs an invalid, uninitialized object. All DC-related objects
except wxColour (i.e. wxPen, wxBrush, wxBitmap, wxFont) are (smart)
pointer-like using COW and their default ctors initialize them to the
"empty" state. 

 Generally speaking, default ctors in wxWidgets rately (and maybe even
never, as I can't think of any counterexample) do anything non-trivial.

GC> Here are some concrete observations, with all the changes that I intend
GC> to push soon (if they pass all tests):
GC> 
GC>  - On the 'wine' console, I see this, which I've never seen before:
GC> 
GC>    wxPdfFontManagerBase::GetFont: Font 'Tahoma' with style 'Regular' not 
found.

 "Tahoma" is wxNORMAL_FONT and wxPdfDoc doesn't support it directly, which
explains the problems below.

GC>  - When I use the original instructions to reproduce the reported problem,
GC> a PDF is created, but some lines look wrong.

 Yes, they do, and I completely failed to notice this even though I did
examine the generated file after my fix. And, of course, it makes perfect
sense: if an invalid font was used before, resulting in an assert, now a
valid but wrong font is used instead. I really should have taken time to
stop and think about what I was doing, sorry...

 I'm going to take time to really understand why does the invalid or wrong
font end up being used and I'll create another PR with a proper fix later.

 Sorry for being too hasty with the previous one,
VZ


reply via email to

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