Re: [lmi] help with orphan-control in xsl-fo

[Greg Chicares]

On 2009-05-16 19:36Z, Vaclav Slavik wrote:
> 
> On Fri, 2009-05-15 at 16:48 -0400, Boutin, Wendy wrote:
>> It fixes the collision of column values and footer text, but it caused 
>> a grave problem for reg_d_individual.xsl and text in other *.xsl files 
>> to change regressively. For the most grave example:
>> 
>> cd /opt/lmi/data
>> cp reg_d_individual.xsl illustration_reg.xsl
>> 
>> cd /opt/lmi/bin
>> ./lmi_cli_shared \
>>   --accept \
>>   --cnsfile=/opt/lmi/src/lmi/sample.cns \
>>   --data_path=/opt/lmi/data \
>>   --emit=emit_pdf_file \
>>   2>&1 |less
> 
> I can't even run this

Exactly.

>, I get errors with fop-0.95 (and it doesn't make
> to use <0.95 with my patch):
> 
>         javax.xml.transform.TransformerException:
>         org.apache.fop.fo.ValidationException:
>         file:/tmp/sample.000000001.fo.xml:144:68: Error(144/68):
>         fo:page-sequence is missing child elements. 
> 
> Is this what I am supposed to see or is the problem something else?

Yes, it's java exceptions, though I observe a different one--see below.

> BTW, this is unrelated to my patch, I get the same errors with
> unmodified sources and fop-0.95.

I had suggested that Wendy present the issue that way, but I fear that
I've only made things less clear, so let me try explaining in detail.
This has nothing to do with your latest patch; indeed, I get similar
catastrophic errors with the earliest version of this '.xsl' file,
from years ago, when I use it with fop-0.95 .

For production in msw, we're using:
    long int exit_code = wxExecute(command_line, output, errors);
to invoke apache's 'fop.bat'. If 'exit_code' is 0L, then we discard
both 'output' and 'errors'--and, thus, as far as the user can see,
the command simply succeeded. Otherwise, no pdf file is produced,
and lmi displays the 'output' and 'errors' array-strings in a
messagebox (but most likely no messagebox is big enough to hold all
of them). (That's why I suggested using the command-line version.)

But '0L == exit_code' doesn't necessarily mean that 'fop.bat' gave
no diagnostics, or even that it gave no "SEVERE" diagnostics.
AFAICT, the exit code is zero iff a pdf file was produced.

We considered filtering 'output' and 'errors' instead of just using
the exit code. However, 'fop.bat' seems to write all output to fd1
(at least for fop-0.20.5), combining routine stuff like this:

  [INFO] FOP 0.20.5
  [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
  [INFO] building formatting object tree
  [INFO] setting up fonts
  [INFO] [1]

with any errors. I decided not to parse the output, and perhaps that
was unwise, because the GUI system therefore suppresses any real fop
diagnostics. (We could run the command-line program 'lmi_cli' as above
to look for diagnostics whenever we change any '.xsl' file, but that
has not been our practice; probably it should be.) So, now, we have
numerous '.xsl' files, some of which give serious diagnostics that we
have always ignored, and we upgrade to fop-0.95 and...

...and now one of those files, 'reg_d_individual.xsl', fails to
produce any pdf output with fop-0.95 . That's not the only obstacle
to upgrading fop, but it's the worst: we can't even detect whatever
latent defects the 0.95 upgrade might reveal in this file, because
we can't get a pdf from it. So I'm guessing that's the first thing we
need to fix. There's no "clean" way to cause 'reg_d_individual.xsl'
to be used with the 'sample' (default) product, so Wendy offered this
workaround:

>> cd /opt/lmi/data
>> cp reg_d_individual.xsl illustration_reg.xsl

But before we apply that workaround, let's try producing a pdf file
from the original 'illustration_reg.xsl', so that we know what
diagnostics we might overlook for the moment. I'll use a slightly
different command (which produces only one pdf file instead of two):

cd /opt/lmi/bin
./lmi_cli_shared --accept --illfile=/opt/lmi/src/lmi/sample.ill
 --data_path=/opt/lmi/data --emit=emit_pdf_file 1>dev1 2>dev2

With
  <xsl_fo_command>CMD /c C:/opt/lmi/third_party/fop-0.95/fop</xsl_fo_command>
in 'configurable_settings.xml' (so that fop-0.95 is used), I get
  SEVERE: Image not found: company_logo.png
numerous times, on fd2 (so 0.95 uses stderr appropriately). That's
fairly benign--we get pdf output nonetheless, and we always
distribute a (proprietary) logo to end users--but let's get rid of
it because it clutters our diagnostics:

  cd /opt/lmi/bin
  cp /opt/lmi/data/help.png ./company_logo.png

With that workaround, I get only this diagnostic (on fd2):
  WARNING: static-content overflows the available area.
repeated three times. But now let's switch to the "bad" '.xsl' file:

  pushd /opt/lmi/data
  cp reg_d_individual.xsl illustration_reg.xsl
  popd

and rerun the command:

./lmi_cli_shared --accept --illfile=/opt/lmi/src/lmi/sample.ill
 --data_path=/opt/lmi/data --emit=emit_pdf_file 1>dev1 2>dev2

Now, I get several less-grave diagnostics like
  In collapsing border model a table does not have padding
and
  table-layout="fixed" and width="auto", but auto-layout not supported
but then it fails with:
  SEVERE: Exception
  javax.xml.transform.TransformerException: \
  org.apache.fop.fo.ValidationException: Error(4889/27): \
  column-number or number of cells in the row overflows the number of \
  fo:table-column specified for the table.
followed by what appears (to me) to be a java stack trace; and no pdf
file is produced.

That '.xsl' file is only about 2^10 lines long, so I naively tried
<!-- commenting out --> various parts of it in order to localize the
error. But my ignorance of xslt got in the way, and my efforts either
induced new errors or caused the xsl transformation to fail.

At this point I think it prudent to ask for help. If we can produce
pdf output (for each '.xsl' file), then we can examine it carefully
and explain how to reproduce each regression we observe; and I hear
that there are quite a few. Alternatively, would it be better to ask
you to resolve the errors that fop itself diagnoses first, and then
perform our regression testing? Perhaps with your help we can hope
to get "clean" fop runs for all these files, with no diagnostics.
First, though, I suppose we should ask you to look into the fatal
'reg_d_individual.xsl' error.

Given that the fop upgrade seems to unmask many latent problems in
our xsl, I think we should dismiss any thought of putting fop-0.95
into lmi production at the end of this month, and aim for the end
of June (if possible) instead.