Re: [lmi] Can we remove unused elements of the columns title map?

[Greg Chicares]

On 2017-09-27 15:23, Vadim Zeitlin wrote:
> On Wed, 27 Sep 2017 15:13:18 +0000 Greg Chicares <address@hidden> wrote:
> 
> [...]
> GC> Now that I see the list--no, actually, every item was added for a
> GC> reason.
> 
>  OK, but what does it mean for the PDF generation code?

Before I try to answer the question, let me explain why I don't understand
it. Today we have {XSL + C++} code that prints columns to PDF with an
appropriate header for each column. Tomorrow we'll have {Mustache + C++}
code that does the same thing: it works in a different way, but produces
an equivalent PDF with the same columns and the same headers.

The headers are in a map indexed by column name. Those headers and that
map remain the same, don't they? And we were just discussing whether
some potential columns could be removed from that map, but we concluded
that none should be removed.

Doesn't that just mean that there's nothing to do?

> On one hand, I need
> to take the titles of the columns that can appear in the supplemental
> reports from somewhere and the current title map doesn't have them in the
> right format (uses underscores instead of new lines).

So...since your plan is to make a copy of 'ledger_xml_io.cpp' and
modify the copy...just change underscores to newlines in the copy?

It must be harder than s/_/\n/g or you wouldn't ask. But I don't
understand why it's harder. Is it that the way those underscores
were used was flaky, so that a simple character substitution wouldn't
do the right thing? Is it the case that, more than a decade ago, we
just added series of consecutive NBSPs, represented by underscores,
until there were enough to make FOP decide to wrap to a new line?
If so, is there anything we can do to make your task easier, like
try to create a PDF with every possible column so that you can read
the intended line-break positions from a printout instead of trying
to figure out what some awful code does?

> OTOH I only need them
> for these columns and so half of the title map is completely unused.

Yes, but only until we use one of the currently-unused columns.

>  Again, the latter is not a huge problem per se, but it does seem a bit
> strange modifying the labels (to use "\n" instead of "_") which are not
> used anyhow.

Not used...yet, today. But maybe they'll be used tomorrow.

> Should I still do this or should I just keep all this code
> completely unchanged -- and completely unused -- and define the column
> labels in the illustration generation code instead?

I don't think we need to preserve an unchanged copy of the '_' version.
Instead, I think we want a copy that contains the same items and uses
'\n' rather than '_'.

> GC> > GC> >  Final possibility would be to keep all this code completely 
> unchanged
> GC> > GC> > and create another set of column titles in the PDF generation code
> GC> > GC> > itself. This would make the upcoming review simpler, and would 
> allow me to
> GC> > GC> > reuse the same map for all columns used in the illustration 
> tables, whether
> GC> > GC> > they correspond to mcenum_report_column elements or not.
> GC> 
> GC> This simplifying idea is interesting.
> 
>  I'm not sure if this is an advantage or a criticism...

Neither. Giving each column exactly one unique name, and expressing it
in one single place, is an attractive idea, especially since the names
are almost unique already. Giving it due consideration led me to see
that at least some of the deviations from uniqueness arise from
legitimate business requirements. But that insight doesn't tell me
how to implement these deviations within your planned code design.

> Just to make it
> clear, I could -- although it will take some more time -- implement this
> idea while exactly (modulo my mistakes) preserving the current behaviour
> and without touching the existing title map at all. Should I do this?

Now I'm really lost. I hope that something I said above will help you
guess whatever it is that I'm missing.