Re: [lmi] Replacing xsl-fo with wxPdfDoc

[Greg Chicares]

On 2016-03-22 21:56, Vadim Zeitlin wrote:
> On Tue, 22 Mar 2016 21:25:32 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> You may be wondering about the new specimen product I just committed
> GC> for this purpose.
[...]
>  Yes, indeed, I was.
> 
> GC> The inline documentation says:
> GC> 
> GC> /// [...] any output substring like "{contract}" here:
> GC> ///   "This {contract} provides valuable protection"
> GC> /// necessarily represents a substitutable value, while everything
> GC> /// else in a report is just literal text.
> GC> 
> GC> Kim already prepared a complete set of PDF reports, but when we
> GC> discussed them, I perceived the problem above
> 
>  I don't know if it's important, but I'm not sure to understand what is the
> actual problem here -- and, a fortiori, how does sample2 solve it. Maybe
> I'll see it once I start really working on this...

The goal, of course, is to replace XSL-FO for generating PDF output.
This output consists of numbers and strings. The numbers are tractable
because they necessarily come from class Ledger and its related classes;
they're almost certain to vary from one illustration to the next, so lmi
has to calculate them, and the calculations can be traced and understood.

The strings are a tougher nut to crack. Ideally, hardly any text would
have been hard-coded in the XSL files, and most text would be specified
in class product_data; in fact, way too much of it is specified in the
XSL files. If you saw (in the samples I just forwarded to you) text like:
  "This contract provides valuable protection"
you wouldn't be able to discern that the word "contract" is the variable
product_data::ContractName. To make that plain, product 'sample2' sets
the value of each product_data member to its name, so you'll see
  "This {ContractName} provides valuable protection"
which at least indicates where we've already done the right thing and
abstracted text content into class product_data.

A rather large universe of possible PDF reports can be created by
  File | New | Illustration
  File | Print to PDF
and the most obvious, direct way to replace the PDF-generation
technology would be to translate the XSL code. But that's a forbidding
task: that code is ill-written, largely incomprehensible, and probably
riddled with errors. It seems far better to start with a limited number
of examples from which you may discern a "kernel" that embodies most
variations. It won't span the whole universe, but it's a practical way
to start; later, we can tell you what important things need to be added.