Re: [lmi] Variables synthesized in 'pdf_command_wx.cpp'

[Vadim Zeitlin]

On Sat, 2 Feb 2019 23:52:56 +0000 Greg Chicares <address@hidden> wrote:

GC> Here's a complete current list of the other variables synthesized in
GC> 'pdf_command_wx.cpp', sorted into categories, with some comments:
GC> 
GC> nbsp strings:
GC>     "Space1"
GC>     "Space2"
GC>     "Space4"
GC>     "Space8"
GC>     "Space16"
GC>     "Space32"
GC>     "Space64"
GC> Vadim--Only the last two are actually used, and only in very special
GC> contexts. Is there a strong reason for keeping the others? Could html's
GC> 'width=' attribute be used in place of all of these?

 I think other versions used to be used for fine-tuned alignment in the
previous versions of the templates and I still think that if we keep them
at all, it's better to keep all of them for consistency. And while it
would, of course, be even better to get rid of them, I'm not sure how to do
it. The "width" attribute in HTML 3 (supported by wxHTML) can't be used
with e.g. <u> tag and even if it could, I think the width could only be
specified in pixels or in percents (of the parent width) and neither is
appropriate for us when we want to have the width in characters. This would
require using <span> tag with "width" CSS property and it's not supported
by wxHTML. I guess we could add ad hoc support for it too, just as we
already did for a couple of other CSS properties which are too useful not
to provide them even if we know that full CSS support would never be
implementable in wxHTML. But I'm not sure if it's worth it...

GC> shortened strings:
GC>     add_abbreviated_variable("CorpName", 60);
GC>     add_abbreviated_variable("CorpName", 50);
GC>     add_abbreviated_variable("CorpName", 140);
GC>     add_abbreviated_variable("Insured1", 30);
GC>     add_abbreviated_variable("Insured1", 50);
GC>     add_abbreviated_variable("Insured1", 140);
GC>     add_abbreviated_variable("ContractNumber", full_abbrev_length);
GC>     add_abbreviated_variable("ContractNumber", full_abbrev_length / 2);
GC>     add_abbreviated_variable("MasterContractNumber", full_abbrev_length);
GC>     add_abbreviated_variable("MasterContractNumber", full_abbrev_length / 
2);
GC> Similarly, could a 'width=' attribute be used here?

 Again, I'd like to get rid of those, but I don't think this can be done
without changes to wxHTML and here even implementing support for "width"
CSS property and "em" units for it would still risk resulting in truncation
of the string at the character boundary instead of exactly after the N-th
character which would be undesirable, wouldn't it?

 OTOH I did think about adding some generic mechanism for getting first N
characters of any existing variable, e.g. writing the interpolation
function in such a way that requesting "Foo_first_N" would return the
substring of (at most) N leading characters of the result of interpolating
"Foo". But it looked like a hack (probably because it is) and, after all,
there were not that many abbreviated variables that were needed, so I
didn't do it in the end. This could be done in a straightforward way if you
think it would be useful, however. Or we could just implement support for
Mustache lambdas or Handlebars block helpers which both basically allow
applying arbitrary functions to the variable values and then we could use
something like {{First(CorpName, 60)}} instead. But this would require
slightly more effort, of course.

GC> However, I wonder whether the business logic behind some of these
GC> variables is actually sound.

 I suppose this question is not addressed to me, as I'm fully incapable of
answering it, as you know perfectly well.

GC> exotic booleans:
GC>     "HasComplianceTrackingNumber"
GC> What is this intended to accomplish? Its apparent function is to insert
GC> 'imprimatur.mst' iff its contents are not empty:
GC>   {{#HasComplianceTrackingNumber}}
GC>       <p>
GC>       Compliance tracking number: {{>imprimatur}}
GC>       </p>
GC>   {{/HasComplianceTrackingNumber}}
GC> but the definition seems more elaborate than that function requires:
GC>     add_variable
GC>         ("HasComplianceTrackingNumber"
GC>         ,expand_template("imprimatur")
GC>             .as_html().find_first_not_of(" \n")
GC>             != std::string::npos
GC>         );
GC> Or is that just another satanic verse that was inserted in the XSL?

 No, I'm afraid this is an unfortunate consequence of template engine
whitespace-preserving behaviour: we need to check if there is anything but
whitespace in the expansion as it's never going to be really empty, even if
all the ImprimaturXXX variables used in imprimatur.mst are empty.

 We could reimplement this by checking the variable which should be used
for the current illustration, as determined by "Composite" and "In force"
flags, directly, but this would need to be kept in sync with imprimatur.mst
contents and so doesn't seem like a good idea -- hence the ugly expression
above.

 Of course, we could at least add a function is_essentially_empty() and use
it here instead, this doesn't cost anything and would probably make this
code simpler to understand. Should I do this?


GC> The list concludes with handful that I'll probably reimplement:
[...snip...]

 I have no comments about those, just please let me know if you'd like me
to do anything here or if you're going to take care of all this on your
own.

 Thanks,
VZ