Andreas L. Delmelle commented on FOP-2469:
Started looking into both patches, and I must say that at first glance, I do
like the LC approach more, in spite of the increased effort... I am definitely
going to have a closer look into how that LC initialization can be streamlined.
If that triggers even more invasive refactoring somewhere else, _so mote it
I also have a few ideas on the TODOs you have, concerning folding the
getMinIPD() into the element collection loop. Since I am working in a local
sandbox on refactoring KnuthSequence, I wonder whether that folding could go
getMinIPD() could be considered a function of the element list (sequence)
returned by each childLM. If the minimum width required for the largest
ListElement in the sequence is updated automatically with each added (relevant)
element, regardless of which LM is building it, then calling said function on a
completed sequence would again become a constant time operation.
That is, instead of requiring an additional iteration over the sequence, or
maybe a painful integration of this logic into the various getNextKE()
More to follow, probably in the weekend. Stay tuned...
> [PATCH] auto table layout
> Key: FOP-2469
> URL: https://issues.apache.org/jira/browse/FOP-2469
> Project: FOP
> Issue Type: Bug
> Components: layout/unqualified
> Affects Versions: trunk
> Environment: Windows 7, JDK 7
> Reporter: Gregor Berg
> Assignee: Andreas L. Delmelle
> Fix For: trunk
> Attachments: 2015-05-13-auto-table-layout.patch,
> 2015-05-27-LM-to-LC-refactoring.patch, FOP2469-auto-table-layout.xml
> this is a patch which enables table-layout=auto. It is quite robust, it can
> not only handle linebreaks and pagebreaks, but it also copes with auto tables
> in fixed tables in auto tables.
> Essentially, it is the patch of issue FOP-2450 adapted to the trunk version
> of FOP.
> Best regards,
This message was sent by Atlassian JIRA