Re: [lmi] Generating pages with tables in the new PDF generation code

[Greg Chicares]

On 2017-08-17 16:13, Vadim Zeitlin wrote:
[...]
> get the direct-pdf-gen branch from my GitHub repository (you don't
> need a GitHub account for this) and build it yourself

I'm trying to devise a high-level strategy for merging this into lmi master.

I did this:

mkdir --parents /opt/lmi/pdf/
cd /opt/lmi/pdf/
git clone https://github.com/vadz/lmi.git --branch direct-pdf-gen 
--single-branch
cd lmi

and I presume I can ignore the generated files as well as '.gitignore':

rm *vcx* *.sln *.bkl .gitignore

Then, comparing to the master branch in /opt/lmi/src/lmi/ I see:
 - 28 changed files
 - 27 new files
 - 3 deleted files

Given 58 files to merge, my usual approach is to merge the easiest
ones first, thereby reducing the size of the problem in at least that
particular dimension and perhaps others. For instance, some files are
added or changed only to make it easier to build with msvc:
  config.hpp
  config_msvc.hpp
  cpp_main.cpp
and merging those reduces the number of files and also the number of
objectives. Do you already have incremental patchsets for changes
like these, which you would want me to apply with 'git am'?

Several of the changed files are just slightly out of date (e.g.,
'install_cygwin.bat'). I assume that these won't be automatically
updated in the development branch, right? If so, I can simply ignore
them (erasing them from my copy of the branch): that's easy enough
because I recognize the changes I've recently made.

The three deleted files cannot be removed from master until all the
old PDF-generation code is removed--at which time we can also remove
most of the XSL templates. But that can't be done until all of the
old PDF-generation code has been replaced and has passed acceptance
testing. Is there a convenient way to let both the old and the new
PDF code exist at the same time, so that we can maintain a linear
repository for both production and testing?

BTW, we will still need one XSL template, 'sort_cell_subelements.xsl',
and therefore I suspect that 'ledger_xsl.?pp' cannot be removed. The
reason is that one external vendor provides XML input files whose
elements are not sorted, which causes XSD validation to fail.