Andreas L. Delmelle (JIRA | 27 May 17:51 2015
Picon

[jira] [Assigned] (FOP-2469) [PATCH] auto table layout


     [
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas L. Delmelle reassigned FOP-2469:
----------------------------------------

    Assignee: Andreas L. Delmelle

> [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
>
>
> Hi,
> 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.
(Continue reading)

Gregor Berg (JIRA | 27 May 15:51 2015
Picon

[jira] [Updated] (FOP-2469) [PATCH] auto table layout


     [
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gregor Berg updated FOP-2469:
-----------------------------
    Attachment: 2015-05-27-LM-to-LC-refactoring.patch

illustration of how a switch from LM bottom-up (O(n)) to LC top-down (O(1)) might look like

> [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
>             Fix For: trunk
>
>         Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, FOP2469-auto-table-layout.xml
>
>
> Hi,
> 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.
(Continue reading)

Gregor Berg (JIRA | 27 May 15:49 2015
Picon

[jira] [Commented] (FOP-2469) [PATCH] auto table layout


    [
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560986#comment-14560986
] 

Gregor Berg commented on FOP-2469:
----------------------------------

I tried to pass the information (whether the current LM is contained in an element using automatic layout
and whether the current invocation is part of the preprocessing step) *down* using LayoutContexts
(LCs). 
What I found is:

* I had to propagate the two corresponding booleans at least 5 times to a new childLC (= LayoutContext.newInstance())
** if this propagation is skipped/forgotten at any point in the LC chain, the results are catastrophic
** since any LM should be able to contain any other LM, each LM's individual version of creating a new LC (e.g.
BlockStackingLM's makeChildLayoutContext(LC)) needs to be adapted to *always* propagate these two
new values
* in the current version of the patch, most decisions of how to continue or which value to return are based on
the LM  and its bottom-up lookup instead of the LC 
** the LM is almost always explicitly accessible, while the LC neets to be passed down (up to 5 times, through
stacks of other methods) into individual methods were the decision is made

While I think that the second point might be solved through refactoring, changing the way LCs are
initialized throughout FOP (first point) may not be feasible for this context.
A patch file illustrating such a refactoring (2015-05-27-LM-to-LC-refactoring.patch: covers some
cases, others will produce incorrect results) will be attached shortly - it will show how much additional
effort would have to go into LC initialization.

> [PATCH] auto table layout
(Continue reading)

Gregor Berg (JIRA | 27 May 08:48 2015
Picon

[jira] [Commented] (FOP-2469) [PATCH] auto table layout


    [
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560501#comment-14560501
] 

Gregor Berg commented on FOP-2469:
----------------------------------

I finished some documentation over the last week and already got sidetracked into some changes I'm
currently working on. Anyway, the documentation (of the current version of the patch) is available under https://wiki.apache.org/xmlgraphics-fop/AutoTableLayout.

> [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
>             Fix For: trunk
>
>         Attachments: 2015-05-13-auto-table-layout.patch, FOP2469-auto-table-layout.xml
>
>
> Hi,
> 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.
(Continue reading)

Andreas L. Delmelle (JIRA | 26 May 22:27 2015
Picon

[jira] [Assigned] (FOP-1488) [PATCH] orphans/widows not respected in some cases


     [
https://issues.apache.org/jira/browse/FOP-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas L. Delmelle reassigned FOP-1488:
----------------------------------------

    Assignee: Andreas L. Delmelle

> [PATCH] orphans/widows not respected in some cases
> --------------------------------------------------
>
>                 Key: FOP-1488
>                 URL: https://issues.apache.org/jira/browse/FOP-1488
>             Project: FOP
>          Issue Type: Bug
>          Components: unqualified
>    Affects Versions: trunk
>         Environment: Operating System: All
> Platform: All
>            Reporter: Andrew McFarland
>            Assignee: Andreas L. Delmelle
>         Attachments: FOP-1488-code.patch, FOP-1488-test.patch, b44328.patch, b44328.patch,
b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328_test.patch,
block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo,
block_orphans_widows.fo, block_orphans_widows.fo, widow.fo
>
>
> When I process the following fo, I get a PDF with a one-line widow at the start
> of the second page, even though widows for that fo:block is set to 4.
(Continue reading)

Andreas Delmelle | 26 May 22:10 2015
Picon

Quick JIRA question

Hi all

I recently discovered two JIRA issues logged against FOP that I think are actually one and the same issue in
XGC (see: https://issues.apache.org/jira/browse/FOP-2343)

I still have to verify locally that my proposed fix in XGC would fix the issue in FOP, but was wondering how to proceed.

Does one usually

a) create a new JIRA issue, against XGC, and then link the other two to that one, or
b) reassign those issues to XGC (if that is even possible?)

?

TIA!

KR

Andreas

Andreas L. Delmelle (JIRA | 26 May 21:48 2015
Picon

[jira] [Updated] (FOP-2276) currentFObj is not updated if Throwable is thrown


     [
https://issues.apache.org/jira/browse/FOP-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas L. Delmelle updated FOP-2276:
-------------------------------------
    Attachment: FOP-2276.patch

Attached a small patch proposal.

Problem is, I currently do not immediately have an idea how to test whether this would really solve the
issue... 
I would have to create a test case that somehow simulates this behaviour, i.e. forced throwing of a
SAXException and attempt to continue processing. If anyone has ideas, even if very vague, feel free to
speak up.

> currentFObj is not updated if Throwable is thrown
> -------------------------------------------------
>
>                 Key: FOP-2276
>                 URL: https://issues.apache.org/jira/browse/FOP-2276
>             Project: FOP
>          Issue Type: Bug
>          Components: fo/unqualified
>    Affects Versions: 1.1
>            Reporter: Daniel Dracott
>            Assignee: Andreas L. Delmelle
>         Attachments: FOP-2276.patch
>
>
(Continue reading)

Andreas Delmelle | 26 May 21:23 2015
Picon

Q - Internal API preference? (It started with a 'simple' TODO...)

Hi FOP devs and other interested parties,

Apologies in advance for the rather long post...

Note - If code structure and style is not your thing, feel free to ignore the whole post, otherwise, you may
just want to go get a drink and some snacks, and bear with me. ;)

A few weeks ago, as I started browsing the codebase to re-familiarize myself, I noticed a TODO in a comment in
the layoutmgr.KnuthSequence class, decided to have a crack at resolving it, and... 
Well, after spending some hours reshuffling things, I have already triggered and dealt with enough
cascading changes that I am seriously thinking about committing it all to a branch.

One of the things that got me wondering is the extensive usage of the "standard" Java Collections API.
Admitted, it's all very convenient to add new code for newcomers. It is relatively easy to donate patches
if you are familiar with the basic Java API and have 'example' code blocks a few lines up or in the
superclass... 
On the other hand, over time, as more and more new pieces got added, and these patterns got basically
copy-pasted all over the place, I feel this convenience may have actually made the code *less*
comprehensible overall.

What I was thinking --and what may have prompted someone[*] else to put that TODO there in the first place--
is that the layout engine, internally, could be refactored to rely *entirely* upon KnuthSequences, in
turn extracted as an interface.
Explicitly avoid implementing or extending the List interface there, and instead, just create a basic
AbstractKnuthSequence implementation that serves as a wrapper around a java.util.List,
encapsulating all the List interactions into proprietary methods, rather than implementing the List
interface itself.

That way, the methods defined in the interface and the base class can be (re)designed and named such, that
FOP's own code in the LayoutManagers may eventually become easier to read and follow (?)
(Continue reading)

Simon Steiner | 26 May 10:33 2015
Picon

[VOTE] Release XML Graphics FOP 2.0 (2nd attempt)


Hi,

This is a vote to release XML Graphics FOP 2.0. Findbugs is passing.

Artifacts can be found there:
https://people.apache.org/~ssteiner/fop-2.0

The release is signed with the key: 
https://people.apache.org/~ssteiner/KEYS

The vote will end on 2/6/2015

+1 from me.

Thanks

Andreas L. Delmelle (JIRA | 25 May 23:24 2015
Picon

[jira] [Commented] (FOP-2268) Empty wrapper in otherwise empty block results in an extra inline area


    [
https://issues.apache.org/jira/browse/FOP-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14558534#comment-14558534
] 

Andreas L. Delmelle commented on FOP-2268:
------------------------------------------

Confirmed, this is definitely a bug, and one that has been with us for quite a while, apparently... I tried a
few older FOP versions, and they showed a similar result.

It seems to be an unintended side effect of the way wrappers are processed in the layout engine. When the
element list is collected by the parent block's LineLayoutManager, a dummy area is generated to make sure
that the wrapper is not lost, in case it has an id.
This seems to 'confuse' the LineLayoutManager so that it returns one line-box, which results in the empty
lineArea that can be seen in the area tree XML. 
If the wrapper does have an id, the lineArea gets one child area to hold the "prod-id", so that it can be
referenced via page-number-citations, basic-links or bookmarks.
If it does not, the lineArea should actually be thrown away, but currently, it still gets added to the area tree.
Even if the empty wrapper did have an id, I still think the more correct result would be a zero-height
lineArea, so that input like

{code:xml}
<block>AAA</block>
<block><wrapper id="empty-wrapper"/></block>
<block>AAA</block>
{code}

would lead to only 2 visible lines in the output, like so:

(Continue reading)

Andreas Delmelle | 25 May 22:26 2015
Picon

Re: FOP -> POI

> On 25 May 2015, at 21:16, Jan Tosovsky <j.tosovsky <at> email.cz> wrote:
> 

Hi Jan

> can you hypothetically imagine any way how to convert virtual page objects
> to the office document structure? I actually I think of 'Slides' to PPTX
> (XSLF) conversion.

Very interesting question...
Somewhat related, as I recall, a suggestion/feature request has been raised in the past to add
OpenOffice's document format as a potential new output format to FOP.

> There is not an easy way to produce paginated PPTX content using pure XSLT.
> But FOP has all the required info somewhere in the memory before serializing
> it into PDF, which could be somehow pushed to POI.

I must admit that I am unfamiliar with the most recent Apache POI API. Last time I looked at POI must have been
almost 10 years ago.

That said, it seems like it may just be possible to achieve something like this by means of FOP's
Intermediate Formats[*], which can already be utilised to split up the basic formatting and rendering processes.

[*] see: http://xmlgraphics.apache.org/fop/trunk/intermediate.html

While it is still an XML format, the benefit would be that it is already paginated, which may make it easier to
generate PPTX slide-decks from. 
Basically, you would use FOP to create an IF file (or stream) from XSL-FO input, as a basis for PDF rendering
on the one hand, and then somehow feed that same intermediate file to POI for creation of the PPTX. Basic
formatting and pagination would be done once, through FOP's layout engine.
(Continue reading)


Gmane