lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Header pagination PR


From: Vadim Zeitlin
Subject: Re: [lmi] Header pagination PR
Date: Sun, 23 Sep 2018 02:08:23 +0200

On Tue, 18 Sep 2018 19:14:19 +0000 Greg Chicares <address@hidden> wrote:

[...font size has changed since the headers pagination patch...]
GC> The code where the font sizes are set is unchanged:
GC> 
GC>         // Use non-default font sizes that are used to make the new
GC>         // illustrations more similar to the previously existing ones.
GC>         pdf_writer_wx writer
GC>             (output.string()
GC>             ,wxPORTRAIT
GC>             ,{8, 9, 10, 12, 14, 18, 20}
GC>             );
GC> 
GC> so could this be a wxHTML regression?

 No, this is just a bug in my code. The simplest fix for it would be
something like this:

---------------------------------- >8 --------------------------------------
diff --git a/pdf_writer_wx.cpp b/pdf_writer_wx.cpp
index 40ddf873f..f8d12c0bf 100644
--- a/pdf_writer_wx.cpp
+++ b/pdf_writer_wx.cpp
@@ -335,6 +335,10 @@ void 
pdf_writer_wx::initialize_html_parser(wxHtmlWinParser& html_parser)
 
 std::unique_ptr<wxHtmlContainerCell> pdf_writer_wx::parse_html(html::text&& 
html)
 {
+    // We don't really want to change the font, but to preserve the current DC
+    // font which is changed by parsing the HTML contents.
+    wxDCFontChanger preserve_font(pdf_dc_, wxFont());
+
     return std::unique_ptr<wxHtmlContainerCell>
         (static_cast<wxHtmlContainerCell*>
             (html_parser_.Parse
---------------------------------- >8 --------------------------------------

 The underlying problem is that we set the smaller font size (9) in
using_illustration_table::create_table_generator(), but just measuring the
footer later, which calls parse_html(), resets it to its default size
because the footer template contains a <font> tag and wxHTML carefully
restores the previously known font, which is 10 from its point of view,
after its end.

 Of course, fixing it by explicitly restoring the real current font, that
wxHTML doesn't know about, as we change it outside of it, using
wxDCFontChanger doesn't look like an exactly elegant or reliable way of
solving the problem. But I'm not sure what could be better. A natural idea
could be to change the font at wxHTML level and this is easily doable, but
considering that the entire table contents is generated from the code, I
don't know how much sense does it make to change its font from the
template. We could still do it in the code but let wxHTML know about the
font change, but neither pdf_writer_wx nor wxHtmlParser currently provide a
way to do it and it doesn't look like an especially great idea to add it.

 So right now I don't really know what else can we do and while the fix
above is ugly, it's already used in pdf_writer_wx::output_html() and so
maybe it's not such a big problem to live with it in parse_html() too?

 Please let me know what do you think,
VZ


reply via email to

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