PostScript problem / DCDecodeFilter
Hi everybody, I've been having great progress with the image treatment for my PostScript output, succeeding in inserting black and white PNG images, but still have in issue with color JPEG ones. The resulting PostScript file is both opened and viewed correctly in GhostView (Linux), but not on the Preview application from OSX, on this one you get the error from the attached image. It says: Error: ioerror; OffendingCommand: image; Errorinfo: DCTDecodeFilter Source error on end in marker before scan 1 8x8 block 552. Is there any special configuration that I need to enable? Or anything else to make this compatible across most platforms. Reference files at: http://bit.ly/1g8i3xk The zip file includes: - Offending image - PDF Output (for reference only) - PS output - FO(images inserted as inline base64 for caching) - Error Screenshot Regards, Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com
Extension issue
Hi there,
After checking the image problems related to PostScript output, I'm trying to
refactor my extension to produce an external-graphic instead of an svg
document, and the first one does render properly both in PDF and PostScript,
but not the later.
This snippet in the XSL-FO:
fo:instream-foreing-object
barbecue:barbecue type=Code128 drawText=false checksumRequired=false
x=0 y=0 width=90 height=18
barbecue:codeExpression00/barbecue:codeExpression
/fo:instream-foreing-object
Is getting translated into:
fo:instream-foreing-object
fo:external-graphic content-height=scale-to-fit content-width=scale-to-fit
height=18
src=url('data:image/png;base64,iVBORw0KGgoNSUhEUgAAAMYAAABLCAMcawhpAAADAFBMVEUAADMAAGYAAJkAAMwAAP8AMwAAMzMAM2YAM5kAM8wAM/8AZgAAZjMAZmYAZpkAZswAZv8AmQAAmTMAmWYAmZkAmcwAmf8AzAAAzDMAzGYAzJkAzMwAzP8A/wAA/zMA/2YA/5kA/8wA//8zAAAzADMzAGYzAJkzAMwzAP8zMwAzMzMzM2YzM5kzM8wzM/8zZgAzZjMzZmYzZpkzZswzZv8zmQAzmTMzmWYzmZkzmcwzmf8zzAAzzDMzzGYzzJkzzMwzzP8z/wAz/zMz/2Yz/5kz/8wz//9mAABmADNmAGZmAJlmAMxmAP9mMwBmMzNmM2ZmM5lmM8xmM/9mZgBmZjNmZmZmZplmZsxmZv9mmQBmmTNmmWZmmZlmmcxmmf9mzABmzDNmzGZmzJlmzMxmzP9m/wBm/zNm/2Zm/5lm/8xm//+ZAACZADOZAGaZAJmZAMyZAP+ZMwCZMzOZM2aZM5mZM8yZM/+ZZgCZZjOZZmaZZpmZZsyZZv+ZmQCZmTOZmWaZmZmZmcyZmf+ZzACZzDOZzGaZzJmZzMyZzP+Z/wCZ/zOZ/2aZ/5mZ/8yZ///MAADMADPMAGbMAJnMAMzMAP/MMwDMMzPMM2bMM5nMM8zMM//MZgDMZjPMZmbMZpnMZszMZv/MmQDMmTPMmWbMmZnMmczMmf/MzADMzDPMzGbMzJnMzMzMzP/M/wDM/zPM/2bM/5nM/8zMAAD/ADP/AGb/AJn/AMz/AP//MwD/MzP/M2b/M5n/M8z/M///ZgD/ZjP/Zmb/Zpn/Zsz/Zv//mQD/mTP/mWb/mZn/mcz/mf//zAD/zDP/zGb/zJn/zMz/zP///wD//zP//2b//5n//8z///8SEhIYGBgeHh4kJCQqKiowMDA2NjY8PDxCQkJISEhOTk5UVFRaWlpgYGBmZmZsbGxycnJ4eHh+fn6EhISKioqQkJCWlpacnJyioqKoqKiurq60tLS6urrAwMDGxsbMzMzS0tLY2Nje3t7k5OTq6urw8PD29vb8/PwgKWLDfklEQVR42u3PwQnAIAwF0LTbdP9hsk5FUFJ76aEneR9MQhThHRnvXO1kq9nnnNvsNzH7mEaNpX/drv/VV1E2dfvMGVsEAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA+Pn3IXwF22rnLWgAElFTkSuQmCC')
width=90
/fo:external-graphic
/fo:instream-foreing-object
Which is actually correct if not embedded within a fo:instream-foreing-object
element, but I cannot figure out how to avoid the use of this element, as
without it the extension is not triggered.
Any workaround ideas?
Regards,
Gonzalo Vásquez Sáez
Gerente Investigación y Desarrollo (RD)
Altiuz Soluciones Tecnológicas de Negocios Ltda.
Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099
+56 2 335 2461
gvasq...@altiuz.cl
http://www.altiuz.cl
http://www.altiuzreports.com
Re: Improving FOP Performance
Dear Luis, We do use several images, such as logos, barcodes and charts in our documents (imagine bank statement like documents). What formats are the best (native) to make the process faster / smoother? We can tweak the images to suit what's best. Thanks Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com El 17-03-2014, a las 20:13, Luis Bernardo lmpmberna...@gmail.com escribió: Can you explain what you expected? The performance results really depend on the example you use. For instance, images can make a big difference, and depending on the type of image and the format output FOP may use a native or non native image loader which may result in significant performance differences. On 3/17/14, 9:48 PM, Gonzalo Vasquez wrote: Hi everybody, We've been doing some performance tests using several output formats (PDF, PostScript and AFP), and they al give us about the same time results, which are far from what we expected. I'm aware that there are several bits of Apache FOP which might me tweaked, but any suggestions would be appreciated for improving performance. Regards, Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com
Re: Improving FOP Performance
I'm into that, but I guess there might be some first parts to look before I dig thaaat deep ;) Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com El 18-03-2014, a las 9:22, Paul Womack supp...@papermule.co.uk escribió: Gonzalo Vasquez wrote: Hi everybody, We've been doing some performance tests using several output formats (PDF, PostScript and AFP), and they al give us about the same time results, which are far from what we expected. I'm aware that there are several bits of Apache FOP which might me tweaked, but any suggestions would be appreciated for improving performance. Use a profiling tool? Or is that too obvious? BugBear
Missing images in PostScript output
Checking FOP Documentation (https://xmlgraphics.apache.org/fop/1.0/output.html), under the PostScript section I see: Limitations Images and SVG may not be displayed correctly. SVG support is far from being complete. No image transparency is available. Can anyone provide a list of actually supported image formats for PostScript output? Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com
Re: Missing images in PostScript output
Well...does help indeed, but doesn't solve the problem, as I'm missing both SVG and JPEG images, which are supported in PostScript :( Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com El 18-03-2014, a las 14:09, A Gian a.yan...@hotmail.com escribió: Hi Carlos, this might help you https://xmlgraphics.apache.org/fop/1.0/graphics.html (check the section Map of supported image formats by output format , Thanasis From: gvasq...@altiuz.cl Subject: Missing images in PostScript output Date: Tue, 18 Mar 2014 14:02:46 -0300 To: fop-us...@xmlgraphics.apache.org; fop-dev@xmlgraphics.apache.org Checking FOP Documentation (https://xmlgraphics.apache.org/fop/1.0/output.html), under the PostScript section I see: Limitations Images and SVG may not be displayed correctly. SVG support is far from being complete. No image transparency is available. Can anyone provide a list of actually supported image formats for PostScript output? Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com
Improving FOP Performance
Hi everybody, We've been doing some performance tests using several output formats (PDF, PostScript and AFP), and they al give us about the same time results, which are far from what we expected. I'm aware that there are several bits of Apache FOP which might me tweaked, but any suggestions would be appreciated for improving performance. Regards, Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com
[jira] [Commented] (FOP-2318) Caching FontInfo class/constructors in AbstractFOPBridgeContext
[ https://issues.apache.org/jira/browse/FOP-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852144#comment-13852144 ] Gonzalo Vasquez commented on FOP-2318: -- Has anyone seen mi suggestion? Caching FontInfo class/constructors in AbstractFOPBridgeContext --- Key: FOP-2318 URL: https://issues.apache.org/jira/browse/FOP-2318 Project: Fop Issue Type: Improvement Components: fonts, svg Affects Versions: trunk Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04) Reporter: Gonzalo Vasquez Priority: Minor Labels: perfomance Attachments: AbstractFOPBridgeContext.patch This my second performance oriented patch, that also improves a little more document generation speed. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Re: [jira] [Resolved] (FOP-2314) Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
Great, thanks for considering it!
Gonzalo Vásquez Sáez
Gerente Investigación y Desarrollo (RD)
Altiuz Soluciones Tecnológicas de Negocios Ltda.
Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099
+56 2 335 2461
gvasq...@altiuz.cl
http://www.altiuz.cl
http://www.altiuzreports.com
El 24-11-2013, a las 8:42, Luis Bernardo (JIRA) j...@apache.org escribió:
[
https://issues.apache.org/jira/browse/FOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Bernardo resolved FOP-2314.
Resolution: Implemented
Fix Version/s: trunk
the tiger example (example/fo/svg/embedding.fo) runs 10% faster with this
change.
patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1544897
Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
---
Key: FOP-2314
URL: https://issues.apache.org/jira/browse/FOP-2314
Project: Fop
Issue Type: Improvement
Components: svg
Affects Versions: trunk
Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04)
Reporter: Gonzalo Vasquez
Priority: Minor
Labels: performance
Fix For: trunk
Attachments: SimpleSVGUserAgent.java.patch, sample.fo
After having profiled an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result =
factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (FOP-2318) Caching FontInfo class/constructors in AbstractFOPBridgeContext
[ https://issues.apache.org/jira/browse/FOP-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Vasquez updated FOP-2318: - Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04) (was: Tested on Mac OSX 10.9) Caching FontInfo class/constructors in AbstractFOPBridgeContext --- Key: FOP-2318 URL: https://issues.apache.org/jira/browse/FOP-2318 Project: Fop Issue Type: Improvement Components: fonts, svg Affects Versions: trunk Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04) Reporter: Gonzalo Vasquez Priority: Minor Labels: perfomance Attachments: AbstractFOPBridgeContext.patch This my second performance oriented patch, that also improves a little more document generation speed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2318) Caching FontInfo class/constructors in AbstractFOPBridgeContext
[ https://issues.apache.org/jira/browse/FOP-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Vasquez updated FOP-2318: - Attachment: AbstractFOPBridgeContext.patch Caching FontInfo class/constructors in AbstractFOPBridgeContext --- Key: FOP-2318 URL: https://issues.apache.org/jira/browse/FOP-2318 Project: Fop Issue Type: Improvement Components: fonts, svg Affects Versions: trunk Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04) Reporter: Gonzalo Vasquez Priority: Minor Labels: perfomance Attachments: AbstractFOPBridgeContext.patch This my second performance oriented patch, that also improves a little more document generation speed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (FOP-2318) Caching FontInfo class/constructors in AbstractFOPBridgeContext
Gonzalo Vasquez created FOP-2318: Summary: Caching FontInfo class/constructors in AbstractFOPBridgeContext Key: FOP-2318 URL: https://issues.apache.org/jira/browse/FOP-2318 Project: Fop Issue Type: Improvement Components: fonts, svg Affects Versions: trunk Environment: Tested on Mac OSX 10.9 Reporter: Gonzalo Vasquez Priority: Minor Attachments: AbstractFOPBridgeContext.patch This my second performance oriented patch, that also improves a little more document generation speed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2318) Caching FontInfo class/constructors in AbstractFOPBridgeContext
[ https://issues.apache.org/jira/browse/FOP-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831514#comment-13831514 ] Gonzalo Vasquez commented on FOP-2318: -- Same FO file as in https://issues.apache.org/jira/browse/FOP-2314 works a sample subject Caching FontInfo class/constructors in AbstractFOPBridgeContext --- Key: FOP-2318 URL: https://issues.apache.org/jira/browse/FOP-2318 Project: Fop Issue Type: Improvement Components: fonts, svg Affects Versions: trunk Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04) Reporter: Gonzalo Vasquez Priority: Minor Labels: perfomance Attachments: AbstractFOPBridgeContext.patch This my second performance oriented patch, that also improves a little more document generation speed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2314) Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
[
https://issues.apache.org/jira/browse/FOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13825287#comment-13825287
]
Gonzalo Vasquez commented on FOP-2314:
--
Great! Hope to hear some more results from the tests soon!
Regarding the note: can you please provide some pointers to replacing the svg
rectangles with fo based ones?
Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
---
Key: FOP-2314
URL: https://issues.apache.org/jira/browse/FOP-2314
Project: Fop
Issue Type: Improvement
Components: svg
Affects Versions: trunk
Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04)
Reporter: Gonzalo Vasquez
Priority: Minor
Labels: performance
Attachments: SimpleSVGUserAgent.java.patch, sample.fo
After having profiled an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result =
factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Content overflows the viewport
I'm getting several warnings like these: Nov 18, 2013 12:58:40 PM org.apache.fop.events.LoggingEventListener processEvent Advertencia: Content overflows the viewport of an fo:block-container in inline-progression direction by 54 millipoints. Content will be clipped. (No context info available) How can I properly identify the offending elements? Please consider that the FO is XSL generated. Regards, Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com
Perfomance tweaks suggested
Hi everybody, I've recently moved to using the trunk version of FOP instead of the latest release (1.1), mainly due to performance issues, as I wanted to check if anything could be improved in the code to get some performance gain, and I've actually succeeded in doing so. The performance upgrade is no such thing 10x times faster but it is an improvement. I've only tweaked two methods that I'd like to propose for commit to the trunk, how do I do so? Regards, Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com
[jira] [Created] (FOP-2314) Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
Gonzalo Vasquez created FOP-2314:
Summary: Caching xmlParserClassName in
org.apache.fop.svg.SimpleSVGUserAgent
Key: FOP-2314
URL: https://issues.apache.org/jira/browse/FOP-2314
Project: Fop
Issue Type: Improvement
Components: svg
Affects Versions: trunk
Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04)
Reporter: Gonzalo Vasquez
Priority: Minor
After having profile an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result = factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (FOP-2314) Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
[
https://issues.apache.org/jira/browse/FOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gonzalo Vasquez updated FOP-2314:
-
Description:
After having profiled an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result = factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
was:
After having profile an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result = factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
---
Key: FOP-2314
URL: https://issues.apache.org/jira/browse/FOP-2314
Project: Fop
Issue Type: Improvement
Components: svg
Affects Versions: trunk
Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04)
Reporter: Gonzalo Vasquez
Priority: Minor
Labels: performance
After having profiled an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result =
factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (FOP-2314) Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
[
https://issues.apache.org/jira/browse/FOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gonzalo Vasquez updated FOP-2314:
-
Attachment: sample.fo
Sample FO file to test performance improvement
Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
---
Key: FOP-2314
URL: https://issues.apache.org/jira/browse/FOP-2314
Project: Fop
Issue Type: Improvement
Components: svg
Affects Versions: trunk
Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04)
Reporter: Gonzalo Vasquez
Priority: Minor
Labels: performance
Attachments: sample.fo
After having profiled an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result =
factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (FOP-2314) Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
[
https://issues.apache.org/jira/browse/FOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823768#comment-13823768
]
Gonzalo Vasquez edited comment on FOP-2314 at 11/15/13 4:18 PM:
Added sample FO file to test performance improvement
was (Author: gvasquez):
Sample FO file to test performance improvement
Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
---
Key: FOP-2314
URL: https://issues.apache.org/jira/browse/FOP-2314
Project: Fop
Issue Type: Improvement
Components: svg
Affects Versions: trunk
Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04)
Reporter: Gonzalo Vasquez
Priority: Minor
Labels: performance
Attachments: sample.fo
After having profiled an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result =
factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (FOP-2314) Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
[
https://issues.apache.org/jira/browse/FOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gonzalo Vasquez updated FOP-2314:
-
Attachment: SimpleSVGUserAgent.java.patch
Added SVN patch as generated from Eclipse Kepler
Caching xmlParserClassName in org.apache.fop.svg.SimpleSVGUserAgent
---
Key: FOP-2314
URL: https://issues.apache.org/jira/browse/FOP-2314
Project: Fop
Issue Type: Improvement
Components: svg
Affects Versions: trunk
Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04)
Reporter: Gonzalo Vasquez
Priority: Minor
Labels: performance
Attachments: SimpleSVGUserAgent.java.patch, sample.fo
After having profiled an application I'm coding, and having detected hotspot
methods, I've come across with a few suggestions por performance improvement
which actually have worked in my environment.
Changing the referenced method to the following code makes the small trick:
From:
public String getXMLParserClassName() {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
return factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
return null;
}
}
To:
private static final String xmlParserClassName;
static {
String result;
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
result =
factory.newSAXParser().getXMLReader().getClass().getName();
} catch (Exception e) {
result = null;
}
xmlParserClassName = result;
}
public String getXMLParserClassName() {
return xmlParserClassName;
}
Could this be added as a patch to the trunk please?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
java.lang.NoSuchMethodError: org.apache.fontbox.cff.CFFFont.getGIDMappings()Ljava/util/ArrayList;
When adding a specific font that contains TrueType fonts or using the auto-detect tag in the fop (trunk version) config file, I'm getting the following exception. Any comments / ideas? java.lang.NoSuchMethodError: org.apache.fontbox.cff.CFFFont.getGIDMappings()Ljava/util/ArrayList; at org.apache.fop.fonts.truetype.OTFFile.updateBBoxAndOffset(OTFFile.java:51) at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:740) at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:108) at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:92) at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:127) at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:111) at org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:251) at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63) at org.apache.fop.fonts.DefaultFontConfigurator.addDirectories(DefaultFontConfigurator.java:122) at org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:85) at org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147) at org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127) at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170) at org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187) at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75) at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135) at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105) at org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350) at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:106) at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104) at org.apache.fop.apps.Fop.init(Fop.java:78) at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179) at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:220) at TestRender.test(TestRender.java:89) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (RD) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099 +56 2 335 2461 gvasq...@altiuz.cl http://www.altiuz.cl http://www.altiuzreports.com
