Re: [lmi] MST: adding paragraph breaks to {{ProductDescription}}

[Greg Chicares]

On 2018-02-20 14:27, Vadim Zeitlin wrote:
> On Tue, 20 Feb 2018 14:03:36 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> std::string ProductDescription =
> GC>   "This is the XYZZY product."
> GC>   "" // There should be a paragraph break here.
> GC>   "It has several death benefit options, viz. ..."
> GC>   "" // There should be a paragraph break here.
> GC>   "Here's another blurb that wants to be a separate paragraph."
> GC>   ;
> GC> 
> GC> C++ doesn't use the empty string as a paragraph break, of course, but
> GC> I thought maybe I could accomplish that by writing "\n" instead. Alas,
> GC> that has no effect on the generated PDF.
> 
>  Well, yes, newlines are not significant in HTML, we really need to use <p>
> tags to have multiple paragraphs.


And writing literal or escaped '<p>' tags in the C++ string:
  "<p>"
  "&lt;p&gt;"
gives:
  subject to change.<p>This illustration
  details.&lt;p&gt;Premiums
so I guess the paragraphs have to be laid out in an MST file (or we
need to write C++ code to html-ify these strings, inserting '<p>').

> GC> Would it be in good taste to make embedded newlines serve that purpose?
> GC> Or do we really need:
> GC> 
> GC> std::string ProductDescription0 = "This is the XYZZY product.";
> GC> std::string ProductDescription1 = "It has several death benefit options."
> GC> 
> GC> and so on, with one variable per paragraph?
> 
>  This wouldn't even really work that well, unfortunately, because if any
> of ProductDescriptionN are empty, we'd still end up with "<p></p>" in the
> generated HTML which would take up space in the output, so it's not a
> solution.


Agreed.

>  We either need to extend the template syntax to either support functions
> in general (so that we could use "{{#para ProductDescription}}" in the
> template) or some ad hoc syntax for just this functionality (e.g.
> "{{=ProductDescription}}" or whatever) or define a function converting
> multiline text to paragraphs in code.
> 
>  The latter should be simpler but, arguably, the former is "better" as the
> templates should be responsible for converting the values to HTML, not the
> code. I'm not sure what would I prefer, but I'd probably do it in the code
> just for the reasons of expediency.
> 
>  What would be your preference here?


Let's mark it with a "PDF !!" tag in the repository, and return to it
later. I have a pending commit that does that.