[jira] [Assigned] (FOP-2472) Allow to clear the hyphenation tree cache at runtime
[
https://issues.apache.org/jira/browse/FOP-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas L. Delmelle reassigned FOP-2472:
Assignee: Andreas L. Delmelle
Allow to clear the hyphenation tree cache at runtime
Key: FOP-2472
URL: https://issues.apache.org/jira/browse/FOP-2472
Project: FOP
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Marc Wiest
Assignee: Andreas L. Delmelle
Priority: Minor
Labels: cache, hyphenation
Original Estimate: 0.5h
Remaining Estimate: 0.5h
I suggest adding the following method (or similar) to the
org.apache.fop.hyphenation.Hyphenator class.
I had to hack FOP and create a custom build for myself, because I need to
alter and reload the hyphenation files at runtime.
The use case is, that I have a web application that allows editors - on an
admin page - to add hyphenation exceptions on-the-fly. In that case the
hyphenation pattern files are re-created including the new exceptions, but
need to be reloaded by FOP. The below worked for me, please consider adding
to the trunk.
{code:title=Hyphenator.java|borderStyle=solid}
/**
* Clear the hyphenation tree cache, in case the underlying data files have
changed at runtime.
*/
public static synchronized void clearHyphenationTreeCache()
{
hTreeCache = new HyphenationTreeCache();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FOP-2472) Allow to clear the hyphenation tree cache at runtime
[
https://issues.apache.org/jira/browse/FOP-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas L. Delmelle resolved FOP-2472.
--
Resolution: Done
Fix Version/s: trunk
See comment added yesterday
Allow to clear the hyphenation tree cache at runtime
Key: FOP-2472
URL: https://issues.apache.org/jira/browse/FOP-2472
Project: FOP
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Marc Wiest
Assignee: Andreas L. Delmelle
Priority: Minor
Labels: cache, hyphenation
Fix For: trunk
Original Estimate: 0.5h
Remaining Estimate: 0.5h
I suggest adding the following method (or similar) to the
org.apache.fop.hyphenation.Hyphenator class.
I had to hack FOP and create a custom build for myself, because I need to
alter and reload the hyphenation files at runtime.
The use case is, that I have a web application that allows editors - on an
admin page - to add hyphenation exceptions on-the-fly. In that case the
hyphenation pattern files are re-created including the new exceptions, but
need to be reloaded by FOP. The below worked for me, please consider adding
to the trunk.
{code:title=Hyphenator.java|borderStyle=solid}
/**
* Clear the hyphenation tree cache, in case the underlying data files have
changed at runtime.
*/
public static synchronized void clearHyphenationTreeCache()
{
hTreeCache = new HyphenationTreeCache();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FOP-2343) Using incorrect inline image leads to strange exception
[
https://issues.apache.org/jira/browse/FOP-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas L. Delmelle reassigned FOP-2343:
Assignee: Andreas L. Delmelle
Using incorrect inline image leads to strange exception
---
Key: FOP-2343
URL: https://issues.apache.org/jira/browse/FOP-2343
Project: FOP
Issue Type: Bug
Reporter: Frank Spies
Assignee: Andreas L. Delmelle
When using an empty inline image (like url('data:image/png;base64,')), an
java.lang.reflect.UndeclaredThrowableException is thrown (instead of just
ignoring the empty image or throwing a more meaningful exception)
?xml version=1.0 encoding=UTF-8?
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
xmlns:fn=http://www.w3.org/2006/xpath-functions;
fo:layout-master-set
fo:simple-page-master margin-top=15mm margin-right=4mm
margin-left=20mm margin-bottom=10mm page-height=297mm
page-width=210mm master-name=pageMaster.ersteSeite
fo:region-body margin-top=60mm margin-right=0mm margin-left=0mm
margin-bottom=10mm /
fo:region-before region-name=regionBeforeErsteSeite
precedence=false extent=60mm /
fo:region-after region-name=regionAfterOhneBarcode
precedence=false extent=6mm /
fo:region-start extent=0mm /
fo:region-end extent=45mm /
/fo:simple-page-master
fo:page-sequence-master master-name=pageMaster.gsubBericht
fo:repeatable-page-master-alternatives
fo:conditional-page-master-reference page-position=first
master-reference=pageMaster.ersteSeite /
fo:conditional-page-master-reference page-position=rest
master-reference=pageMaster.ersteSeite /
/fo:repeatable-page-master-alternatives
/fo:page-sequence-master
/fo:layout-master-set
fo:page-sequence master-reference=pageMaster.gsubBericht
fo:static-content flow-name=regionBeforeErsteSeite
fo:block /
/fo:static-content
fo:static-content flow-name=regionAfterOhneBarcode
fo:block /
/fo:static-content
fo:flow margin-left=5cm margin-top=1em text-align=justify
flow-name=xsl-region-body
fo:block
fo:external-graphic content-width=scale-down-to-fit
content-height=scale-to-fit height=20mm width=35mm
src=url('data:image/png;base64,') /
/fo:block
/fo:flow
/fo:page-sequence
/fo:root
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FOP-2399) External graphics that return 403 error, make FOP crash
[ https://issues.apache.org/jira/browse/FOP-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle reassigned FOP-2399: Assignee: Andreas L. Delmelle External graphics that return 403 error, make FOP crash --- Key: FOP-2399 URL: https://issues.apache.org/jira/browse/FOP-2399 Project: FOP Issue Type: Bug Components: image/unqualified Affects Versions: 1.1 Reporter: Konstantin Milyutin Assignee: Andreas L. Delmelle Labels: external-graphic Attachments: stack I use external-graphics tag in my template. When a graphic is not found (404 response code), the pdf is rendered without a graphic. On the other hand, when the response code is 403 (not authorized), then the FOP crashes with EOF exception somewhere in graphics library. The referenced resource doesn't have to be an image. It can even be just simple page, returning 403 error code. I think the same error also happens when response code is 401. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (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 reassigned FOP-2276: Assignee: Andreas L. Delmelle 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 If an exception is thrown during org.apache.fop.fo.FOTreeBuilder.MainFOHandler.endElement(String, String, String), then the line currentFObj = currentFObj.getParent(); does not get executed. If the SAX event source decides to store the exception and continue, then subsequent endElement calls can generate SAXExceptions of the form: Caused by: org.xml.sax.SAXException: Mismatch: page-sequence (http://www.w3.org/1999/XSL/Format) vs. root (http://www.w3.org/1999/XSL/Format) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:338) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:181) ... Some implementations of javax.xml.transform.Transformer that we have used will attempt to perform further endElement calls in this way and the SAXException can hide the original Throwable, making diagnosis of problems difficult. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
FOP - POI
Dear All, 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. 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. Why do I even need this? It is a real requirement to distrubute our slides (XML - PDF by default) also in PPTX to tailor the given training to the target audience (by trainers on site). The best solution I've found so far is Acrobat's PDF - PPTX conversion. But even this is sometimes buggy. I think this would be a killer feature not available even in professional formatters. Thanks, Jan attachment: winmail.dat
Re: FOP - POI
On 25 May 2015, at 21:16, Jan Tosovsky j.tosov...@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. Not sure what POI can handle as input, though, or how difficult it would be to make it handle FOP's IF... Not sure if that goes in the direction of what you were looking for, but hope this helps! Andreas
[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-tabpanelfocusedCommentId=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}
blockAAA/block
blockwrapper id=empty-wrapper//block
blockAAA/block
{code}
would lead to only 2 visible lines in the output, like so:
AAA
AAA
Empty wrapper in otherwise empty block results in an extra inline area
--
Key: FOP-2268
URL: https://issues.apache.org/jira/browse/FOP-2268
Project: FOP
Issue Type: Bug
Components: renderer/pdf
Affects Versions: 1.1
Environment: Windows (probably occurs regardless of the OS)
Reporter: Nick Heyworth
Priority: Minor
Attachments: test.fo
The attached FO contains
1) an empty block
2) an empty wrapper
3) an empty wrapper in a block
I was expecting none of these to render an area, but 3) causes some empty
space to be rendered. Am I expecting the wrong thing, or is this a bug?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
