[jira] [Commented] (FOP-2963) Add Option for Safer Hyphenation
[
https://issues.apache.org/jira/browse/FOP-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570093#comment-17570093
]
Nicholas Moser commented on FOP-2963:
-
Just a heads up for anyone interested in using this patch, it does result in
more memory usage since many more Knuth nodes are being created. To help
alleviate memory I created an additional patch that helps reduce the number of
object allocations. Specifically, I found that there are many calls to
log.debug(...) that include String concatenation in them, resulting in creating
a StringBuilder object. This can be alleviated by first checking if debug
logging is enabled. For example:
{code:java}
- log.debug("PLM> break - " +
getBreakClassName(breakPenalty.getBreakClass()));
+ if (log.isDebugEnabled()) {
+ log.debug("PLM> break - " +
getBreakClassName(breakPenalty.getBreakClass()));
+ } {code}
I've attached a patch fixing this to this JIRA: [^perf_improvements.patch]
These debug logs are also a problem in the mainline branch of FOP, but they are
even more of a problem after taking the patch from this Jira since there are
more Knuth nodes and many of these log.debug(...) calls occur in a hot loop
over the Knuth nodes.
I've also attached a .fo file I used to create the original PDFs on this JIRA:
[^example.fo]
> Add Option for Safer Hyphenation
>
>
> Key: FOP-2963
> URL: https://issues.apache.org/jira/browse/FOP-2963
> Project: FOP
> Issue Type: Improvement
>Reporter: Nicholas Moser
>Priority: Major
> Attachments: example-after-disabled.pdf, example-after-enabled.pdf,
> example-before.pdf, example.fo, patch.diff, perf_improvements.patch
>
>
> This is a new proposed setting for FOP I have decided to call *safer
> hyphenation*.
> Currently, FOP may generate PDFs where text can overlap or go off the page.
> The most common scenarios I've seen this occur are:
> # A very small amount of space is allocated for text, such as the cell of
> table. Even if there are valid hyphenation points for words, a sufficiently
> large word may exit the cell as there aren't enough hyphenation points in it.
> # A string of characters such as numbers will exit the space allocated for
> them even if there is plenty of room to line break. This is because
> hyphenation patterns do not set line breaks for strings of numbers, therefore
> it sees no valid hyphenation points.
> Examples of these issues can be seen in the attached PDF
> *example-before.pdf*. The third row on the first table has a really long word
> with many hyphenation points. Despite this, it exits the cell twice due to
> there not being enough hyphenation points. Additionally, The rows below this
> row contain a long series of numbers that have no hyphenation points and go
> off the page.
> My proposed fix for this involves a new configuration setting called *safer
> hyphenation*. It effectively does three things.
> # Places hyphenation points between every character in a string buffer,
> ignoring hyphenation patterns.
> # Moves hyphenation from the second pass to the third pass of
> findOptimalBreakingPoints(...)
> # Massively increases the penalty for hyphenation.
> The first change is fairly simple. A hyphenation can occur anywhere in any
> word in the document. This effectively fixes both of the problems, since now
> they will line break before they exit their allocated space. The issue is
> that now, the line breaking algorithm will attempt to use these new
> hyphenation points even when not necessary. This will result in many ugly
> hyphenations. Since hyphenation patterns are no longer used, I argue that the
> best way to handle this is to avoid hyphenation now unless it is absolutely
> necessary.
> The second and third changes attempt to avoid hyphenation unless it is
> absolutely necessary. The second change only allows hyphenation during the
> third pass of the optimal breaking point search, after the max adjustment has
> been changed to 20. The third change massively increases the penalty for
> using a hyphenation. This results in the algorithm in avoiding hyphenation
> unless there are no other options.
> Since this is a new configuration setting, I've included two additional PDFs,
> *example-after-disabled.pdf* and *example-after-enabled.pdf*. The first PDF
> proves that when the configuration is off, the changes are entirely passive
> and cause no different. The second PDF shows the improvements of using safer
> hyphenation. It also shows the downside, in that old hyphenation (with
> hyphenation patterns) can no longer be used to improve the layout of a
> paragraph.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FOP-2963) Add Option for Safer Hyphenation
[ https://issues.apache.org/jira/browse/FOP-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Moser updated FOP-2963: Attachment: perf_improvements.patch example.fo > Add Option for Safer Hyphenation > > > Key: FOP-2963 > URL: https://issues.apache.org/jira/browse/FOP-2963 > Project: FOP > Issue Type: Improvement >Reporter: Nicholas Moser >Priority: Major > Attachments: example-after-disabled.pdf, example-after-enabled.pdf, > example-before.pdf, example.fo, patch.diff, perf_improvements.patch > > > This is a new proposed setting for FOP I have decided to call *safer > hyphenation*. > Currently, FOP may generate PDFs where text can overlap or go off the page. > The most common scenarios I've seen this occur are: > # A very small amount of space is allocated for text, such as the cell of > table. Even if there are valid hyphenation points for words, a sufficiently > large word may exit the cell as there aren't enough hyphenation points in it. > # A string of characters such as numbers will exit the space allocated for > them even if there is plenty of room to line break. This is because > hyphenation patterns do not set line breaks for strings of numbers, therefore > it sees no valid hyphenation points. > Examples of these issues can be seen in the attached PDF > *example-before.pdf*. The third row on the first table has a really long word > with many hyphenation points. Despite this, it exits the cell twice due to > there not being enough hyphenation points. Additionally, The rows below this > row contain a long series of numbers that have no hyphenation points and go > off the page. > My proposed fix for this involves a new configuration setting called *safer > hyphenation*. It effectively does three things. > # Places hyphenation points between every character in a string buffer, > ignoring hyphenation patterns. > # Moves hyphenation from the second pass to the third pass of > findOptimalBreakingPoints(...) > # Massively increases the penalty for hyphenation. > The first change is fairly simple. A hyphenation can occur anywhere in any > word in the document. This effectively fixes both of the problems, since now > they will line break before they exit their allocated space. The issue is > that now, the line breaking algorithm will attempt to use these new > hyphenation points even when not necessary. This will result in many ugly > hyphenations. Since hyphenation patterns are no longer used, I argue that the > best way to handle this is to avoid hyphenation now unless it is absolutely > necessary. > The second and third changes attempt to avoid hyphenation unless it is > absolutely necessary. The second change only allows hyphenation during the > third pass of the optimal breaking point search, after the max adjustment has > been changed to 20. The third change massively increases the penalty for > using a hyphenation. This results in the algorithm in avoiding hyphenation > unless there are no other options. > Since this is a new configuration setting, I've included two additional PDFs, > *example-after-disabled.pdf* and *example-after-enabled.pdf*. The first PDF > proves that when the configuration is off, the changes are entirely passive > and cause no different. The second PDF shows the improvements of using safer > hyphenation. It also shows the downside, in that old hyphenation (with > hyphenation patterns) can no longer be used to improve the layout of a > paragraph. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (FOP-3069) Empty results in infinite loop when strict-validation is set to false
[
https://issues.apache.org/jira/browse/FOP-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reopened FOP-3069:
> Empty results in infinite loop when strict-validation is set
> to false
> -
>
> Key: FOP-3069
> URL: https://issues.apache.org/jira/browse/FOP-3069
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 1.1, 2.0, 2.1, 2.2, 2.3, 2.4, 2.6, 2.7
>Reporter: Michael Kainzbauer
>Priority: Major
>
> +_Since Apache FOP 1.1 (not reproducible in 1.0)_+
> When disabling strict-validation, ApacheFOP will loop infinitely when a
> is empty, e.g.:
> As a result in class
> {color:#57d9a3}org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(LayoutContext
> context, int alignment);{color}
> (line 111)
> is called infinitely.
> Yes, the XML-FO is incorrect and not according to the standard, but this is
> an issue that can cause real trouble when the given conditions are met.
> Turning on strict-validation will result in an error with a clear and
> understandable error message:
> {quote}{color:#57d9a3}{{Error on line 26 column 29 }}{color}
> {color:#57d9a3}{{ SXCH0003 org.apache.fop.fo.ValidationException:
> "fo:table-body" is missing child}}{color}
> {color:#57d9a3}{{ elements. Required content model: marker*
> (table-row+|table-cell+) (Siehe Position 26:29).}}{color}
> {color:#57d9a3}{{ Caused by org.apache.fop.fo.ValidationException:
> null:26:29: "fo:table-body" is missing}}{color}
> {color:#57d9a3}{{ child elements. Required content model: marker*
> (table-row+|table-cell+) (See position 26:29)}}{color}
> {quote}
> Example XML-FO:
> {quote}{{{color:#57d9a3}{color}}}
> {{{color:#57d9a3} xmlns:fo="http://www.w3.org/1999/XSL/Format;>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} page-width="210mm" page-height="297mm">{color}}}
> {{{color:#57d9a3} margin-right="5mm" margin-top="10mm"/>{color}}}
> {{{color:#57d9a3} region-name="main-reg-before"/>{color}}}
> {{{color:#57d9a3} region-name="main-reg-after"/>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} master-reference="A4-main" page-position="any"/>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3}{color}}}
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FOP-3085) Remove Xalan
[ https://issues.apache.org/jira/browse/FOP-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3085: --- Description: See BATIK-1329 > Remove Xalan > > > Key: FOP-3085 > URL: https://issues.apache.org/jira/browse/FOP-3085 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > > See BATIK-1329 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FOP-3085) Remove Xalan
Simon Steiner created FOP-3085: -- Summary: Remove Xalan Key: FOP-3085 URL: https://issues.apache.org/jira/browse/FOP-3085 Project: FOP Issue Type: Bug Reporter: Simon Steiner Assignee: Simon Steiner -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-2845) File leak to background-image
[
https://issues.apache.org/jira/browse/FOP-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569885#comment-17569885
]
Simon Steiner commented on FOP-2845:
What about setting:
-Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true
> File leak to background-image
> -
>
> Key: FOP-2845
> URL: https://issues.apache.org/jira/browse/FOP-2845
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Björn Kautler
>Assignee: Matthias Reischenbacher
>Priority: Major
>
> I use FOP from within my Gradle build to produce documentation PDFs.
> So the VM usually is not closed, but the Gradle Daemon that executes the
> build stays alive.
> I built some PDF and then tried to delete the folder as it was just a test,
> but one file was still locked by the Gradle process, so FOP seems to leak
> that file resource.
> It was the {{draft.png}} that is set as {{background-image}} in this snippet.
> Also interesting, this page master was not even used, so it is even more
> suspicious why the file was opened for reading at all, but that it stays
> locked is pretty unnice.
> {code:xml}
> margin-bottom="0cm" margin-top="0cm" page-height="297mm" page-width="210mm"
> master-name="my-titlepage-first-draft">
> column-gap="12pt"
> margin-top="0cm"
> margin-bottom="0cm"
>
> background-image="url(../../common/images/decorative/draft.png)"
> background-attachment="fixed"
> background-repeat="no-repeat"
> background-position-horizontal="center"
> background-position-vertical="center"/>
> region-name="xsl-region-before-first"/>
> region-name="xsl-region-after-first"/>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[
https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569878#comment-17569878
]
Simon Steiner commented on FOP-3083:
for linux to test:
{code:java}
@Test
public void x() throws Exception {
try {
FopFactoryBuilder fopFactoryBuilder = new FopFactoryBuilder(new
File(".").toURI());
fopFactoryBuilder.setStrictFOValidation(true);
fopFactoryBuilder.setStrictUserConfigValidation(true);
FopFactory fopFactory = fopFactoryBuilder.build();
try (ByteArrayOutputStream stream = new ByteArrayOutputStream()) {
Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, stream);
TransformerFactory transformerFactory =
TransformerFactory.newInstance();
Transformer transformer = transformerFactory.newTransformer();
Source src = new StreamSource(new File("test.fo"));
Result res = new SAXResult(fop.getDefaultHandler());
transformer.transform(src, res);
}
}
finally {
Assert.assertTrue(isFileClosed(new File("example.jpg")));
}
}
private boolean isFileClosed(File file) throws Exception {
Process plsof = new ProcessBuilder(new String[]{"lsof", "|", "grep",
file.getAbsolutePath()}).start();
BufferedReader reader = new BufferedReader(new
InputStreamReader(plsof.getInputStream()));
String line;
while((line=reader.readLine())!=null) {
if(line.contains(file.getAbsolutePath())) {
reader.close();
plsof.destroy();
return false;
}
}
reader.close();
plsof.destroy();
return true;
}
{code}
> Referenced JPG image is not closed when TransformerException is thrown by
> transform()
> -
>
> Key: FOP-3083
> URL: https://issues.apache.org/jira/browse/FOP-3083
> Project: FOP
> Issue Type: Bug
> Components: renderer/pdf
>Affects Versions: 2.7
> Environment: jdk-17.0.3.7-hotspot (Microsoft)
>Reporter: Paul Sharp
>Priority: Major
> Attachments: Code snippet.txt, example.jpg, xsl-fo.xml
>
>
> We are trying to implement a workflow where the FO file and the images
> referenced within, are stored in a temporary directory which we can clear
> down once complete.
> When we disable strict FO validation, the approach works fine.
> However, when strict FO validation is enabled, a TransformerException is
> thrown (as expected for a poor FO). But it appears to keep the image file
> open until the JVM is shut down.
> I have checked through previous Jira entries and tried many other suggestions
> (clearing the image cache etc.) but we cannot seem to get the file closed.
> The attached example code snippet illustrates the behaviour. We would expect
> the example.jpg file to be deleted after processing.
> I hope I've provided enough here. Let me know if more detail is required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[ https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569876#comment-17569876 ] Simon Steiner commented on FOP-3083: What about setting: -Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true > Referenced JPG image is not closed when TransformerException is thrown by > transform() > - > > Key: FOP-3083 > URL: https://issues.apache.org/jira/browse/FOP-3083 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.7 > Environment: jdk-17.0.3.7-hotspot (Microsoft) >Reporter: Paul Sharp >Assignee: Simon Steiner >Priority: Major > Attachments: Code snippet.txt, example.jpg, xsl-fo.xml > > > We are trying to implement a workflow where the FO file and the images > referenced within, are stored in a temporary directory which we can clear > down once complete. > When we disable strict FO validation, the approach works fine. > However, when strict FO validation is enabled, a TransformerException is > thrown (as expected for a poor FO). But it appears to keep the image file > open until the JVM is shut down. > I have checked through previous Jira entries and tried many other suggestions > (clearing the image cache etc.) but we cannot seem to get the file closed. > The attached example code snippet illustrates the behaviour. We would expect > the example.jpg file to be deleted after processing. > I hope I've provided enough here. Let me know if more detail is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[ https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reassigned FOP-3083: -- Assignee: (was: Simon Steiner) > Referenced JPG image is not closed when TransformerException is thrown by > transform() > - > > Key: FOP-3083 > URL: https://issues.apache.org/jira/browse/FOP-3083 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.7 > Environment: jdk-17.0.3.7-hotspot (Microsoft) >Reporter: Paul Sharp >Priority: Major > Attachments: Code snippet.txt, example.jpg, xsl-fo.xml > > > We are trying to implement a workflow where the FO file and the images > referenced within, are stored in a temporary directory which we can clear > down once complete. > When we disable strict FO validation, the approach works fine. > However, when strict FO validation is enabled, a TransformerException is > thrown (as expected for a poor FO). But it appears to keep the image file > open until the JVM is shut down. > I have checked through previous Jira entries and tried many other suggestions > (clearing the image cache etc.) but we cannot seem to get the file closed. > The attached example code snippet illustrates the behaviour. We would expect > the example.jpg file to be deleted after processing. > I hope I've provided enough here. Let me know if more detail is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[
https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569870#comment-17569870
]
Markus Karg commented on FOP-3084:
--
BTW, I actually tried your proposed solution and it does not work. I provided a
custom schema as the `baseURI` to FopFactoryBuilder (so the resource builder
understands the prefix to replace by the "dynamic" base URI), while keeping
schema-free relative URIs in the FO file (so the GUI tool is happy), so I could
replace the custom schema by a base URI found in a Thread Var. This might work
for external graphics like PNG, but it does not work for _embedded_ SVG. No
resource resolver is invoked for _embedded_ SVG but instead the custom schema
is forwarded to the SVG handling code by FOP internally, which apparently is
unable to deal with custom schema:
{{java.net.MalformedURLException: unknown protocol: foo}}
{{ at java.base/java.net.URL.(Unknown Source)}}
{{ at java.base/java.net.URL.fromURI(Unknown Source)}}
{{ at java.base/java.net.URI.toURL(Unknown Source)}}
{{ at
org.apache.fop.fo.extensions.svg.SVGElement.getDimension(SVGElement.java:77)}}
Hence the _sole_ +completely+ working solution is to allow either the method
`newFop()` or the user user agent to set a base URI specific for the current
rendering job.
Now as that is proven, can we please go on discussing _how_ we change FOP? :)
> Override baseURI per FOP instance
> -
>
> Key: FOP-3084
> URL: https://issues.apache.org/jira/browse/FOP-3084
> Project: FOP
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Markus Karg
>Priority: Major
>
> There is a best practice to reuse FOP Factory instances for optimal
> performance. But doing so effectively applies the same baseURI (the one used
> at factory creation) to all FOP instances, hence to all rendered XSL
> templates.
>
> Given the case one needs to render XSL template `/a/A.xfo` referring to a
> picture file `./A.png` (hence effectively located at `/a/A.png`), and then
> needs to render XSL template `/b/B.xfo`, referring to a picture file
> `./B.png` (hence effectively found at `/b/B.png`), then there is no other
> solution but to create a new FOP Instance per template: On instance for
> `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively
> results in rather bad performance!
>
> To support this use case while keeping optimal performance (hence: use a
> single FOP factory), there should be a way to pass the baseURI of the
> rendered XSL template to the FOP Factory, so creating a new FOP instances
> effectively use different baseURIs to resolve images. In the past, there had
> been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a
> very bad idea, as concurrent callers ended up in a race condition. So
> reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable
> solution!
>
> Proposed solutions could be to either add an optional parameter baseURI to
> `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method
> `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method
> `FOUserAgent.setBaseURI(baseURI)`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[ https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reassigned FOP-3083: -- Assignee: Simon Steiner > Referenced JPG image is not closed when TransformerException is thrown by > transform() > - > > Key: FOP-3083 > URL: https://issues.apache.org/jira/browse/FOP-3083 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.7 > Environment: jdk-17.0.3.7-hotspot (Microsoft) >Reporter: Paul Sharp >Assignee: Simon Steiner >Priority: Major > Attachments: Code snippet.txt, example.jpg, xsl-fo.xml > > > We are trying to implement a workflow where the FO file and the images > referenced within, are stored in a temporary directory which we can clear > down once complete. > When we disable strict FO validation, the approach works fine. > However, when strict FO validation is enabled, a TransformerException is > thrown (as expected for a poor FO). But it appears to keep the image file > open until the JVM is shut down. > I have checked through previous Jira entries and tried many other suggestions > (clearing the image cache etc.) but we cannot seem to get the file closed. > The attached example code snippet illustrates the behaviour. We would expect > the example.jpg file to be deleted after processing. > I hope I've provided enough here. Let me know if more detail is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569828#comment-17569828 ] Markus Karg edited comment on FOP-3084 at 7/22/22 6:19 AM: --- No I cannot. The user must be free to choose the XSL-FO editor of his own choice. The one most of our customer use does not allow to type in arbitrary protocols. The reason is that it is a WYSIWYG editor which loads the image to show it. That will horribly fail when using an arbitrary schema, so it is a no-go. Please do not further try to find quirky workarounds. The idea of this issue is to provide a clean and trick-free FOP API. was (Author: mkarg): No I cannot. The user must be free to choose the XSL-FO editor of his own choice. The one most of our customer use does not allow to type in arbitrary protocols. Please do not further try to find quirky workarounds. The idea of this issue is to provide a clean and trick-free FOP API. > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569828#comment-17569828 ] Markus Karg commented on FOP-3084: -- No I cannot. The user must be free to choose the XSL-FO editor of his own choice. The one most of our customer use does not allow to type in arbitrary protocols. Please do not further try to find quirky workarounds. The idea of this issue is to provide a clean and trick-free FOP API. > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
