lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Header pagination PR


From: Greg Chicares
Subject: Re: [lmi] Header pagination PR
Date: Sun, 23 Sep 2018 14:45:05 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 2018-09-23 00:08, Vadim Zeitlin wrote:
> 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 --------------------------------------

Okay, I've applied exactly that change, and it fixes everything except
the 'sample2ipp' format. I have committed a number of changes, so I'll
push everything now to make sure we're using exactly the same code.

After pulling, you should have this:
  $git log -1 --oneline 
  682f7050 (HEAD -> master) Set a line in boldface
Now apply the experimental patch first given here:
  https://lists.nongnu.org/archive/html/lmi/2018-09/msg00038.html
(reproduced below for convenience) in order to generate PDFs even when
a superheader seems to be too wide:

---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
diff --git a/wx_table_generator.cpp b/wx_table_generator.cpp
index 4ec91b87..7c9491e7 100644
--- a/wx_table_generator.cpp
+++ b/wx_table_generator.cpp
@@ -23,6 +23,7 @@
 
 #include "wx_table_generator.hpp"
 
+#include "alert.hpp"
 #include "assert_lmi.hpp"
 #include "miscellany.hpp"               // count_newlines(), split_into_lines()
 #include "ssize_lmi.hpp"
@@ -247,7 +248,15 @@ void wx_table_generator::output_super_header
 
     for(auto const& i : lines)
         {
-        LMI_ASSERT(dc().GetTextExtent(i).x <= rect.width);
+if(rect.width < dc().GetTextExtent(i).x)
+  warning()
+    << rect.width << " rect.width\n"
+    << dc().GetTextExtent(i).x << " dc().GetTextExtent(i).x\n"
+    << i << " i\n"
+    << LMI_FLUSH
+    ;
+
+//      LMI_ASSERT(dc().GetTextExtent(i).x <= rect.width);
         dc_.DrawLabel(i, rect, wxALIGN_CENTER_HORIZONTAL);
         rect.y += row_height_;
         pos_y  += row_height_;
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------

And now, to reproduce the anomaly:

  File | New | Illustration
    "Policy": choose "sample2ipp"
  OK
  File | Print to PDF

Result: the font used for tables is too large, seemingly as though your
wxDCFontChanger patch above had not been applied. However, now modify
the same illustration, in the same lmi session:

  Illustration | Edit cell...
  "Reports" tab:
    check "Create supplemental report"
    "Column 0": select "CorridorFactor"
      [it probably doesn't matter which columns are selected]
  OK
  File | Print to PDF

Result: the font problem has been suppressed, and everything looks great.

>  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.

Looking futilely for a solution, I noticed two interesting things:

First, the line
         numbered_page::start_numbering();
appears right after add<cover_page> for all other formats, but for
reg_d_indiv, it appears *before* the cover page. (And reg_d_indiv
has its own custom cover page, whereas every other format uses a
standard one.) I think this is actually unintended: the XSL-FO
system prints "Page 1 of 10" on this cover page. (I tried moving
the start_numbering() line down in this instance, but that just
triggered an assertion failure elsewhere, in code that I haven't
yet studied.)

Second, I tried suppressing several pages, leaving only one that
contains a table (sorry, these aren't proper patches, just git-diff
output copied from terminal scrollback, but they're so simple that
they should be comprehensible):

--- a/ledger_pdf_generator_wx.cpp
+++ b/ledger_pdf_generator_wx.cpp
@@ -3093,9 +3093,9 @@ class pdf_illustration_reg_d_indiv : public 
pdf_illustration
 
         // Add all the pages.
         numbered_page::start_numbering();
-        add<standard_page>("reg_d_indiv_cover_page");
-        add<reg_d_indiv_guar_irr>();
-        add<reg_d_indiv_curr_irr>();
+//      add<standard_page>("reg_d_indiv_cover_page");
+//      add<reg_d_indiv_guar_irr>();
+//      add<reg_d_indiv_curr_irr>();
         add<reg_d_indiv_curr>();
         add<standard_page>("reg_d_indiv_notes1");
         add<standard_page>("reg_d_indiv_notes2");

and, noting that there's a <font> tag in the remaining tabular
page's HTML, I suppressed it:

--- a/reg_d_indiv_curr.mst
+++ b/reg_d_indiv_curr.mst
@@ -21,7 +21,9 @@
 
 {{>reg_d_indiv_header}}
 
+{{!
 <font size="-1">
+}}

but those changes didn't seem to affect the anomaly.



reply via email to

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