Eliminate xml table conflict - #4884
Merged
Merged
Conversation
This is an AI analysis of errors reported by Apache fop.
A conflict arises when building PDFs of docs - informaltable elements want
to use proportional columns, FOP doesn't support these, so it falls back
to fixed widths which are incompatible with some Docbook syntax - this
isn't SCons' problem per se, just a hole we fall into because of using
fop, plus wrapping lxml - something that wasn't the default until quite
a bit after this code was merged in the first place.
[ERROR] FOUserAgent - Invalid property value encountered in column-width="proportional-column-width(1)": org.apache.fop.fo.expr.PropertyException: file:/home/mats/github/scons/build/doc/user/scons-user.fo:12435:16: proportional-column-width() function may only be used when fo:table has table-layout="fixed".; property:'column-width' (See position 12435:95)
Various approaches were explored - some work in this direction had
been partially done, as $DOCBOOK_XSLTFLAGS provides a way to pass
flags through, but the docbook tool doesn't actually parse that setting
("parampass" is initialized to an empty dict but never populated with
parse results - it now has a comment to that effect in case it turns up
needed in future)). Fixing that the "obvious" way opens up some other
holes, so instead a fairly simplminded postprocessing step is added to
the docbook tool.
Various approaches were explored - some work in this direction had
been partially done, as `$DOCBOOK_XSLTPROCFLAGS` provides a way to pass
flags through, but while the docbook tool recognizes that in general,
it doesn't actually parse it when the lxml wrapping is used: `parampass`
is initialized to an empty dict but never populated with parse results
- it now has a comment to that effect in case it turns up needed in
future. lxml usage wasn't the default before, it became so after the
older approach was retired by upstream. Fixing that the "obvious" way,
by adding the flags in each doc SConstruct and parsing the value, opens
up some other holes, so instead a fairly simplminded postprocessing step
is added to the docbook tool.
Signed-off-by: Mats Wichmann <mats@linux.com>
Assisted-by: OpenCode 1.18.5 driving Qwen 3.8
bdbaddog
reviewed
Jul 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an AI analysis of errors reported by Apache fop, in this style:
A conflict arises when building PDFs of docs -
informaltableelements default to proportional columns,fopdoesn't support these, so it falls back to fixed widths which are incompatible with some Docbook syntax - this isn't SCons' problem per se, just a hole we fall into because of usingfop, plus wrappinglxml- something that wasn't the default until quite a bit after this code was merged in the first place.Various approaches were explored - some work in this direction had been partially done, as
$DOCBOOK_XSLTPROCFLAGSprovides a way to pass flags through, but while the docbook tool recognizes that in general, it doesn't actually parse it when the lxml wrapping is used:parampassis initialized to an empty dict but never populated with parse results - it now has a comment to that effect in case it turns up needed in future. lxml usage wasn't the default before, it became so after the older approach was retired by upstream. Fixing that the "obvious" way, by adding the flags in each doc SConstruct and parsing the value, opens up some other holes, so instead a fairly simplminded postprocessing step is added to the docbook tool.Signed-off-by: Mats Wichmann mats@linux.com
Assisted-by: OpenCode 1.18.5 driving Qwen 3.86
Remove this paragraph
Please have a look at our developer documentation before submitting your Pull Request.
https://scons.org/guidelines.html
Contributor Checklist:
CHANGES.txtandRELEASE.txt(and read theREADME.rst).