[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632745#comment-13632745
]
Peter Hancock commented on FOP-2211:
Fix committed in revision 1468361
Alexios - Thanks for you help and please feel free to post any ideas or code
for better handling of temp data.
[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--
Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk
Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch
As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects for
long running processes that use FOP embedded.
1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when using
FOP embedded in order to fix those issues. The default implementation should
work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Hancock closed FOP-2211.
--
Resolution: Fixed
Assignee: Peter Hancock
[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--
Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Assignee: Peter Hancock
Fix For: trunk
Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch
As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects for
long running processes that use FOP embedded.
1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when using
FOP embedded in order to fix those issues. The default implementation should
work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628759#comment-13628759
]
Peter Hancock commented on FOP-2211:
Hi Alexios,
Sorry for the late reply. I plan to commit the patch with the omission of the
File.deleteOnExit() in the next few days
[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--
Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk
Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch
As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects for
long running processes that use FOP embedded.
1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when using
FOP embedded in order to fix those issues. The default implementation should
work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Hancock updated FOP-2211:
---
Attachment: fop.patch
[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--
Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk
Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch
As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects for
long running processes that use FOP embedded.
1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when using
FOP embedded in order to fix those issues. The default implementation should
work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13600190#comment-13600190
]
Peter Hancock commented on FOP-2211:
Hi Alexios,
The latest patch ensures file is deleted when the resource is closed.
Peter
[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--
Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk
Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch
As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects for
long running processes that use FOP embedded.
1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when using
FOP embedded in order to fix those issues. The default implementation should
work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
Hi Alexios,
I take it you are you reading from the temp files more than once,
otherwise you could reluctantly hook into the close method of Resource
to do the file deletion. I am interested to know how you are
benefiting from reusing the temp file.
Thanks,
Peter
On Tue, Mar 5, 2013 at 10:55 AM, Alexios Giotis (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13593313#comment-13593313
]
Alexios Giotis commented on FOP-2211:
-
Hi Simon,
Thank you for the patch. I looked at it and it does not resolve the issue of
keeping on disk many and big files. In a test we did last week, the temp file
was 100GB and for sure we don't wish to keep such files until the JVM is
normally terminated. For us, this is several months or a year.
Also, I don't think that backwards compatibility is an issue here. This is
trunk, there are many changes since 1.1 that do affect users embedding FOP in
their apps and this is not one of them. I am sure it will be easy to change
your code or to create an adapter.
I will try to find some time to submit updated versions of the patches that
take into account the comments above.
[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--
Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk
Attachments: fop.patch, tempurisimple.patch, xgc.patch
As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects
for long running processes that use FOP embedded.
1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when
using FOP embedded in order to fix those issues. The default implementation
should work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Trouble with temporary files after the merge of Temp_URI_Resolution branch
Hi Alexis, The DefaultTempResourceResolver is used by the DefaultResourceResolver and is suitable for the case when we run FOP from the command line ... the actual pattern of using temp files has changed from: File tmpFile = File.createTempFile(); // Write and read from the file tmpFile.delete(); to: File tmpFile = new File(System.getProperty(java.io.tmpdir), counterStartingFrom1AsString); tmpFile.deleteOnExit(); // Write and read from the file This introduces a number of bad side effects: 1. Different FOP processes can't be executed in parallel on the same system because creating the same temp file fails. 2. If the JVM is not normally terminated, the temp files are never deleted and the next invocation of the JVM fails to run. 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp files both on disk and a reference in memory. The DefaultTempResourceResolver is used by the DefaultResourceResolver and is suitable in the case when we run FOP from the command line and sequentiality at the system level. I agree that the first side effect is problematic and the URI generator should perhaps add some random characters or something similiar. The 2nd point and 3rd point are not an issue when we run FOP from the command line. When running FOP as part of a long running process I would recommend creating an implementation of TempResourceResolver that handles the cleanup: This implementation could return an instance of Resource in the getResource method that s parametrised with an InputStream that uses close() to perform the file deletion - you could even decide to store the temporary data in memory if your requirements make that feasible. I am also tempted to delete the org.apache.xmlgraphics.io.Resource and change in ResourceResolver the Resource getResource(URI uri) to InputStream getInputStream(URI uri) Although in [1] there is a reason for having it, in practice the type is used nowhere. Although the type property is not used yet, it was introduced as a way of being able to set something like a mime type on a resource without having to encode that in the URL. For example, if FOP needed to be able to determine the type of font that a resource represented it would be better to declare this as a property, rather than perhaps using a pseudo file extension. This was looslely inspired by the HTTP protocol that uses the 'content-type header field to identify the content type of a resonse. Please ask me to expand on any of my explanations if you require more detail. Thanks, Pete
[jira] [Commented] (FOP-2180) [PATCH] TTFReader: Output bounding box information for glyphs
[ https://issues.apache.org/jira/browse/FOP-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13550991#comment-13550991 ] Peter Hancock commented on FOP-2180: Whoops - the evils of cut paste! [PATCH] TTFReader: Output bounding box information for glyphs - Key: FOP-2180 URL: https://issues.apache.org/jira/browse/FOP-2180 Project: Fop Issue Type: Wish Components: fonts Affects Versions: 1.1 Reporter: Alexey Neyman Assignee: Peter Hancock Priority: Minor Attachments: ttfreader.diff As I mentioned in another email, I am trying to constrain FOP to use only local fonts (i.e. ones described in fop.cfg). For SVGs, I have a workaround: - Generate fonts in SVG format using ttf2svg utility from Batik; - Use an XSL stylesheet to embed all the fonts used by an SVG image into the image itself; - Use such preprocessed SVG image as the input to FOP. This does not work well with JEuclid, though. When JEuclid generates SVG from MathML, it performs font rendering - that is, replaces characters by actual paths. And again, it uses system fonts, not the fonts available in FOP - even if running as FOP plugin. To work around this issue for MathML, I am currently switching from JEuclid to pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text characters, not paths. But in order to do so, it needs font metrics. Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient - this stylesheet also needs bounding box for each glyph. To obtain these, pMML2SVG currently packages an augmented TTFReader Java sources which are to be compiled and used in lieu of the stock one. Given that the patch is very small and as far as I can tell, compatible with current users of font metrics (it just adds 4 attributes to glyph description), is it possible to integrate this support into stock FOP? Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2180) [PATCH] TTFReader: Output bounding box information for glyphs
[ https://issues.apache.org/jira/browse/FOP-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Hancock resolved FOP-2180. Resolution: Implemented Assignee: Peter Hancock Thanks to Alexey Neyman [PATCH] TTFReader: Output bounding box information for glyphs - Key: FOP-2180 URL: https://issues.apache.org/jira/browse/FOP-2180 Project: Fop Issue Type: Wish Components: fonts Affects Versions: 1.1 Reporter: Alexey Neyman Assignee: Peter Hancock Priority: Minor Attachments: ttfreader.diff As I mentioned in another email, I am trying to constrain FOP to use only local fonts (i.e. ones described in fop.cfg). For SVGs, I have a workaround: - Generate fonts in SVG format using ttf2svg utility from Batik; - Use an XSL stylesheet to embed all the fonts used by an SVG image into the image itself; - Use such preprocessed SVG image as the input to FOP. This does not work well with JEuclid, though. When JEuclid generates SVG from MathML, it performs font rendering - that is, replaces characters by actual paths. And again, it uses system fonts, not the fonts available in FOP - even if running as FOP plugin. To work around this issue for MathML, I am currently switching from JEuclid to pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text characters, not paths. But in order to do so, it needs font metrics. Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient - this stylesheet also needs bounding box for each glyph. To obtain these, pMML2SVG currently packages an augmented TTFReader Java sources which are to be compiled and used in lieu of the stock one. Given that the patch is very small and as far as I can tell, compatible with current users of font metrics (it just adds 4 attributes to glyph description), is it possible to integrate this support into stock FOP? Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-1069) No error message on illegal/unknown values on a property
[ https://issues.apache.org/jira/browse/FOP-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Hancock resolved FOP-1069. Resolution: Fixed Assignee: Peter Hancock Resolved thanks to Robert Meyer No error message on illegal/unknown values on a property Key: FOP-1069 URL: https://issues.apache.org/jira/browse/FOP-1069 Project: Fop Issue Type: Bug Components: fo tree Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Jeremias Maerki Assignee: Peter Hancock Attachments: patch.diff, test2.fo I've written border=solit 1pt into an FO file. When I realized my typo I went looking for an error message but didn't find one. I looked around to fix this myself but didn't find the right spot in reasonable time as I'm concentrating on other stuff right now. I'm posting it here so it doesn't get lost. FOP should notify the user that it has found a value it cannot deal with, especially if this is an enum value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Vote] Add dependency to fontbox for OTF CFF
+1 if usage is restricted to OTF CFF fonts at first. On Thu, Jan 10, 2013 at 2:20 PM, Vincent Hennebert vhenneb...@gmail.comwrote: +1 Vincent On 10/01/13 13:07, Robert Meyer wrote: Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. Regards, Robert Meyer
Re: [Vote] for the merge of Temp_RoundedCorners
With 7 +1 votes and a 0.5 for limited CSS3 support I am able to close the vote and perform the merge. Thank you to all those who explored the feature and provide feedback! Peter On Tue, Oct 23, 2012 at 11:36 PM, Luis Bernardo lmpmberna...@gmail.com wrote: my vote: +1 On 10/12/12 10:40 AM, Peter Hancock wrote: Hi, Luis Benardo and Myself have just done some clean up to the branch Temp_RoundedCorners. This branch implements support for 'fox' extension properties for specifying borders with rounded corners. Please refer to [1] and [2] for details. There is an example fo [3] that demonstrates the feature. Currently we are supporting: PDF, PS and AFP outputs 'border-style' property with values of 'solid', 'none', 'hidden' and, to a limited degree, 'dashed' I would like to start a vote to merge feature branch to trunk, with my +1. Thanks, Peter [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
Re: [Vote] for the merge of Temp_RoundedCorners
Hi Glenn, I have just committed to Temp_RoundedCorners to address some of the concerns raised. My preference would be to provide both the CSS3 named properties and also writing system relative properties, giving the user the preference of which to use. But I would suggest using the same pattern as CSS3 for property names for these latter: border-top-left-radius border-top-right-radius border-bottom-right-radius border-bottom-left-radius border-before-start-radius border-before-end-radius border-after-start-radius border-after-end-radius I have now implemented border properties of the form border-before-start-radius, that take one or two values, in line with the CSS3 recommendation. However, I have not been able as yet to implement properties for the absolute properties (border-top-left-radius, etc). I am unable to prove concretely that the property resolution system can or cannot support my requirements here, but either way I have decided to put this requirement on hold for now. The omission of these properties will not affect backwards compatibility going forward and so I do not personally consider it to be a show stopper. it would also be useful to support the border-radius shortcut from CSS3 (mapping to the above CSS3 longhand flavors) This was done previously if we accept that the second value refers to the block progression direction and not the absolute top-to-bottom direction. I have updated the example fo and the CMS to reflect these changes. If you are happy with the change I can proceed with the merge. Thanks, Peter
Re: [Vote] for the merge of Temp_RoundedCorners
Hi Jeremias, I have updated the CMS to document that there are limitations with tables. I have suggested that setting the 'border-collapse' property on tables to 'separate' will allow the support of rounded corners on tables. I am currently fighting with FOPropertyMapping to support the absolute properties and I am not having much luck. Thanks again for your help with this feature! Peter On Sun, Oct 14, 2012 at 10:56 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: I took a peek since I helped with the branch in the beginning. Nice job over all!!! Good looking borders! I agree with Glenn that the extension should be aligned with CSS3 as closely as possible. In the usual XSL manner there should ideally be both relative (start, end...) and absolute (top, left...) properties. While there seem to be unit tests for the generation of painting operators there are no layout engine tests that verify area tree generation as well as area tree and IF parsing/round-trips. Also I haven't found any mention in the docs or the demo file that rounded borders on tables are not implemented, yet. I found that out the hard way. Seems like border radius information is lost during border collapse processing. However, that should be easy to fix and is probably a matter of adding a few lines to CollapsingBorderModelEyeCatching.java. Some layout engine tests will help here. +0.5 as the current state goes. +1 if CSS3 alignment is achieved and there are a few layout engine tests (at least one for fo:block and one for fo:inline) checking the decoding of the enhanced border function and the AT/IF round-trip. The missing table border support is surely not blocking. Jeremias Maerki On 12.10.2012 11:40:19 Peter Hancock wrote: Hi, Luis Benardo and Myself have just done some clean up to the branch Temp_RoundedCorners. This branch implements support for 'fox' extension properties for specifying borders with rounded corners. Please refer to [1] and [2] for details. There is an example fo [3] that demonstrates the feature. Currently we are supporting: PDF, PS and AFP outputs 'border-style' property with values of 'solid', 'none', 'hidden' and, to a limited degree, 'dashed' I would like to start a vote to merge feature branch to trunk, with my +1. Thanks, Peter [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
Re: [Vote] for the merge of Temp_RoundedCorners
Hi Vincent,
In the last commit to Temp_RoundedCorners I have addressed all your
points, except:
• o.a.f.render.intermediate.BorderPainterTestCase
the generics don’t seem necessary and could be removed altogether
I would like to improve that little micro-framework to eliminate the
need for generics (and the cast I had to do!) but I think it serves
it's purpose for now.
Thanks,
Pete
On Fri, Oct 19, 2012 at 4:43 PM, Vincent Hennebert vhenneb...@gmail.com wrote:
+1
Having the ‘absolute’ versions of the properties would be nice but this
is not IMO a blocker requirement for the merge of this work.
Here are a few comments based on a quick look at the branch:
• o.a.f.fo.Constants
PR_X_BORDER_START_RADIUS_START
PR_X_BORDER_START_RADIUS_END
PR_X_BORDER_END_RADIUS_START
PR_X_BORDER_END_RADIUS_END
Shouldn’t it be
PR_X_BORDER_START_RADIUS_BEFORE
PR_X_BORDER_START_RADIUS_AFTER
PR_X_BORDER_END_RADIUS_BEFORE
PR_X_BORDER_END_RADIUS_AFTER
?
• o.a.f.fo.properties.BoxCornerPropShorthandParser
some glitches in the javadoc for convertValueForProperty
• o.a.f.fo.properties.CommonBorderPaddingBackground
there’s a commented out ‘if (style != Constants.EN_NONE) {’? Is that
left-overs from debugging that can be removed?
• o.a.f.layoutmgr.TraitSetter
line ~100: it’s a shame to re-introduce Hungarian notation
• o.a.f.render.intermediate.BorderPainter
left-over ‘TODO remove before integration’?
drawBorderSegment: don’t you want to use Math.round instead of
directly casting to int, for better precision?
• o.a.f.render.intermediate.BorderPainterTestCase
the generics don’t seem necessary and could be removed altogether
• o.a.f.render.pdf.PDFPainterTestCase,
o.a.f.render.ps.PSPainterTestCase
the ‘// mock’ comments are hardly helpful and could be removed; the
variables could instead be renamed into something that starts with
‘mock’ so that we know what is what later in the code.
The try...catch should really be removed: if an exception occurs
during the test it will be swallowed (along with its stack trace) by
the catch and replaced with an unhelpful AssertionError with no stack
trace.
Thanks,
Vincent
On 12/10/12 10:40, Peter Hancock wrote:
Hi,
Luis Benardo and Myself have just done some clean up to the branch
Temp_RoundedCorners. This branch implements support for 'fox'
extension properties for specifying borders with rounded corners.
Please refer to [1] and [2] for details.
There is an example fo [3] that demonstrates the feature.
Currently we are supporting:
PDF, PS and AFP outputs
'border-style' property with values of 'solid', 'none', 'hidden'
and, to a limited degree, 'dashed'
I would like to start a vote to merge feature branch to trunk, with my +1.
Thanks,
Peter
[1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
[2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
[2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
Re: [Vote] for the merge of Temp_RoundedCorners
Great feedback everyone. I will address property naming and document the table limitation spotted by Jeremias. On Sun, Oct 14, 2012 at 10:56 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: While there seem to be unit tests for the generation of painting operators there are no layout engine tests that verify area tree generation as well as area tree and IF parsing/round-trips. Since the feature did not impact on the layout process other than adding new area traits, I did not consider at the time that there was a need for layout tests. I agree that there is value in testing the area tree and IF serialization/parsing and will create some tests. Thanks, Peter
[Vote] for the merge of Temp_RoundedCorners
Hi, Luis Benardo and Myself have just done some clean up to the branch Temp_RoundedCorners. This branch implements support for 'fox' extension properties for specifying borders with rounded corners. Please refer to [1] and [2] for details. There is an example fo [3] that demonstrates the feature. Currently we are supporting: PDF, PS and AFP outputs 'border-style' property with values of 'solid', 'none', 'hidden' and, to a limited degree, 'dashed' I would like to start a vote to merge feature branch to trunk, with my +1. Thanks, Peter [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
Re: [Vote] for the merge of Temp_RoundedCorners
Thanks for taking the time to review this! On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams gl...@skynav.com wrote: ... However, I also notice that the fox property name proposed in [1] contains uppercase (fox:border-BLOCK-radius-INLINE). That is a definite no-no, and thus warrants a -1 vote until changed to LC. All LC please! The upper case BLOCK and INLINE were meant to represent variables with values before and after, and start and end, respectively. I haven't had a chance to look at the details, but does this extension follow the (property name and value) definitions found in CSS3 Backgrounds and Borders [4]? If it doesn't, then my vote is -1; otherwise, I would vote +1. I do concede that there is a departure from CSS3: To specify the top left corner in CSS3 you do border-top-left-radius=x y and with the fox extension (assuming a viewport orientated with the page) fox:border-start-radius-before=x fox:border-before-radius-start=y If this is unsatisfactory then I guess it is back to the drawing board. Peter
Re: [VOTE] Merge Temp_URI_Unification
Hi Vincent, FOP Dev, On Wed, Jul 4, 2012 at 12:32 PM, Vincent Hennebert vhenneb...@gmail.com wrote: snip/ And BTW, what is the recommended way to get a FopFactoryConfig? The javadoc of buildConfig doesn’t say. I think it should. The need to obtain an instance of a FopFactoryConfig implementation is most probably unnecessary, however we have made it an option for two reasons: 1 The unit test org.apache.fop.fotreetest.FOTreeTestCase uses processing instructions in the parsed FO files to alter FopFactory configuration. We decided not to change this mechanism, and thus required a way to modify the configuration. By exposing the underling FopFactoryConfig we were able to wrap the immutable instance in a proxy that allows property modification. 2 If an existing FOP client relies on the modification of the FopFactory then there is a mechanism in place. Modifying the FopFactory after construction is discouraged which is why we have not advertised the practise in the javadocs or wiki. I have just noticed that the stativ method FopFactoryConfig FopFactory.newInstance(FopFactoryConfig) is not marked as depricated - I think the long term intention should be to make this method package private, along with FopFactoryConfig. src/java/org/apache/fop/apps/io/TempResourceResolver • unless I’m mistaken there’s no way of releasing the temporary resource once it’s no longer needed. The DefaultTempResourceResolver implementation deleteOnExits the file but this may not be enough if FOP is run on a server that is meant to (almost) never shut down. Or did I miss something? You missed something; this is the default implementation. This is pretty much only for the CLI use-case, if users wish to define their own implementation, all they have to do is implement the interface. OK, so presuming I want to write my own implementation that does a more fine-grained management of resources, how do I know that I can release a given resource? This is a good point. Currently, FOP assumes that temporary resources become unavailable for reading once the input stream is closed. FOP is expected to call InputStream.close(), and this call should be used to trigger he release of the resource, perhaps by wrapping the underlying InputStream in an implementation FilteredInputStream that does this cleanup. We intend to document in detail some recipes for implementing the ResourceResolver - there is currently some further work required for the handling of resource types (we envision that that these will consist of something like a superset of all MIME types) that we wish to handle first. Thanks, Peter
Re: Comments on FopFactory.getRendererConfig (Temp_URI_Unification)
Hi Alexios,
Thanks for taking a look at this.
On Thu, Jul 5, 2012 at 1:41 PM, Alexios Giotis alex.gio...@gmail.com wrote:
Hi,
I had a quick look on the work you are doing and I think that the newly
introduced methods
FopFactory.getRendererConfig(getRendererConfig(FOUserAgent userAgent,
Configuration cfg,
RendererConfigParser configCreator))
and the similar ones on FOUserAgent should all be replaced with a single
FopFactory.getRendererConfig(String mimeType).
1. Design reason: This is a public API that uses too many internal objects.
RendererConfigParser is not part of the public API [1] and I find no reason
to add. If this does not change, then it becomes automatically part of the
public API (it's a public method of the public FopFactory).
[1] http://xmlgraphics.apache.org/fop/trunk/embedding.html#API
Good point - a quick fix is to make the method can be made package
private. With a bit more work I agree that the method signature could
be simplified: The Configuration object is resolvable from the mime
type, as you suggest, however calls to getRendererConfig(String
mimeType, RendererConfigParser configCreator) can be made whereby
configCreator.getMimeType() differs from mimeType (see
BitmapRendererConfigurator). Ideally we should fix the configuration
hierarchy however this was out of scope for our initial
implementation. Removing the FOUserAgent parameter and calling
RendererConfigParser.build() with the FopFactory makes sense, however
the issue of the Event Broadcaster crops up - see below...
2. Buggy: FopFactory is supposed to be reusable and a new FOUserAgent should
be created for every execution since it holds some rendering specific
information. But the existing FopFactory.getRendererConfig() uses the
rendering specific FOUserAgent to cache in (MapString, RendererConfig
rendererConfig) a RendererConfig. The cached object will be used by a future
FOUserAgent with possibly different user properties. Sounds scary to me. What
if the configuration of a renderer uses a FOUserAgent specific property ?
(the properties of the first FOUserAgent will be used).
Looking a little deeper, the renderer config implementations are currently
using firstly the FOUserAgent to get access to FopFactory (e.g. to check the
strict validation flag), secondly the event broadcaster. The first tells me
that they actually need to get the immutable FopFactory instead of the
FOUserAgent. The second (usage of the event broadcaster) makes my fears come
true. Scenario:
During the first rendering, a default FOUserAgent is used. Assuming the
configuration is problematic, the default event handlers will log a message
and continue. During the next rendering, an event broadcaster that aborts
processing on any error is registered. The user would expect to stop on any
error, but the process will simply continue.
I see a few options. I am in favor of the simpler one which is to throw an
exception instead of broadcasting an event when an error in found in the
renderer config. A second one is to add yet another flag on FopFactory that
will determine this behavior. Another one is to register event handlers
related to renderer config on FopFactory. It's flexible but a thread safe
implementation of the handler is required.
Well spotted! We considered this problem and wondered whether we
should store the events and republish them upon subsequent calls to
FopFactory.getRendererConfig.
I think this is something to consider, along with your suggestions, if
it turns out to be a practical requirement.
3. Buggy: FopFactory getRendererConfig() is not thread safe. Wrap the method
body in a synchronized (rendererConfig) {...}
Well spotted!
Thanks,
Peter
Re: [VOTE] Merge Temp_URI_Unification
+1 On Tue, Jun 26, 2012 at 3:39 PM, mehdi houshmand med1...@gmail.com wrote: Sorry, added [VOTE] to subject line... My bad On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com wrote: Hi All, I think we've got to the stage in the URI unification branch where it's ready to be merged into trunk (not into 1.1RC1). I know there have been proponents against the inclusion of this feature and/or those who are concerned the wider implications as it means FOP has fewer contingency methods when attempting file access. I'll try and explain how we've addressed those concerns as well as some of the code improvements we've made. - Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous i.e. contains white-space, \ instead of /, we do some validation on to mitigate some of the common mistakes. However, we don't allow for falling back to 'new File(.)' or new URL(...).openStream() since these can obviously cause clashes in a highly parallelised multi-tenant environment. - Single FOP conf parse - Previously the renderer specific regions of the FOP conf was being parsed on every run. This is costly to performance for the obvious reason, but as well as this, it meant that font auto-detection was having to be executed on every run. The font-caching was created to mitigate some of those performance costs, however, caching the FOP conf makes much more sense. It means we can get rid of the font-caching and don't have to to worry about performance but it also allowed to do a lot of clean up in the configuration packages. The renderer specific config is also lazy loaded such that it is only parsed when the respective renderer is invoked, mitigating the one-off cost of parsing that config. - The environment profile - We've created an environment profile that abstracts the system in which FOP is invoked. This allows us to programmatically enforce restrictions to, for example, font-caching and auto-detection since users may want to control this behaviour for any number of reasons. - Improved URI handling - because the URI resolution has been unified to a couple of classes, the behaviour is much easier for users to understand. - Consistent base directories - We've tried to ensure that base directories are consistent with FOP previously, the base and font-base still work as previously. There are however some outstanding TODOs that need to be addressed, however, though they are important, they don't need to be all merged in at the same time. I will be working on these and keep the community updated: TODOs// - XGC and libraries - This is most likely the next project, we need to do the same in the XGC project and look at some of FOPs dependencies (Batik too!). The plan will be to move all the resource resolver classes to XGC since that is the parent library so that they can be used though out the XMLGraphics libraries. - Improved MIME type resolution - currently FOP's file-type (file-MIME-type) is performed in-situ using file-name endings. This is, while working perfectly fine on a desktop environment, would be less than desirable if file-names were just hashes or the like from a virtual file-system. We need to give the user the flexibility to define a file MIME type without forcing them to put the file-ending in the URI. - Default handling in some of the Configurators - We have improved the mechanism that handles default values in the configuration as well as config injected via RendererOptions (on the FOUserAgent) and the FOP conf for PDF. However, time constraints haven't allowed us to do the same for PS and AFP, which would be nice to do. This isn't of utmost priority, but it would be nice to not have the if (x != null) peppered around the source Sorry for the long email, I just thought it'd be a good time to expose some of the work we've been doing, Mehdi P.S. More information can be found wiki under the developers section, it's currently down so I can't post a link.
Re: [VOTE] Merge Temp_TrueTypeInPostScript branch into trunk
+1 On Mon, Jun 18, 2012 at 12:02 PM, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 15/06/2012 11:25, Vincent Hennebert wrote: As you may have noticed, I’ve recently spent some time updating the Temp_TrueTypeInPostScript branch to the latest trunk and doing some clean-up (thanks to Robert for updating the testcases to JUnit 4). We have been using the code from this branch for quite a while now and it has proven to work reasonably well. I won’t hide the fact that some parts of the code are truly ugly (in PSFontUtils mainly), but it’s not possible to clean that up without heavily refactoring the font sub-system, which I unfortunately can’t spend time on right now. At least the ugliness is fairly self-contained. Meanwhile some users may find the additional functionality useful. So I’d like to propose a vote for merging that branch back to Trunk. The vote will run until Thursday 21st, 8:00GMT. Here’s my +1. +1. Good work Vincent and Rob on cleaning up this old branch. The functionality is long overdue in a publicly released version of FOP. Chris Thanks, Vincent
Re: [VOTE] Switch from Bugzilla to JIRA
+1 On Tue, Apr 17, 2012 at 9:15 AM, Chris Bowditch bowditch_ch...@hotmail.com wrote: Hi All, We need to have a formal vote to decide if the XML Graphics project and all sub projects should switch the bug tracking system from Bugzilla to JIRA. The main benefits of which are: 1. JIRA has a more modern look and feel 2. Infrastructure are not equiped to support Bugzilla anymore as most Apache projects are based on JIRA. Therefore should be more able to respond to requests for changes. The downside is that someone will have to work with infra@ to organize the import of bugs from BZ to JIRA. We then need to update the website links to point to JIRA instead of BZ. Glenn Adams has kindly volunteered to oversee the migration. Heres my +1 The vote runs until 24th April. Thanks, Chris
Re: A proposal to change the configuration and deployment of FOP
Hi Jeremias, Thanks for your feedback! On Wed, Mar 28, 2012 at 7:08 PM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Hi Peter, can you please explain what problem you're trying to solve? From the Wiki pages I cannot derive that. And what do you mean by the separation of configuration and deployment? I'm particularly clueless as to how an API affects deployment here. By configuration I refer to the process of configuring the Fopfactory; both through direct programmatic means and via the parsing of the fop.xconf. By deployment I refer to the creation of the FOUserAgent and Fop object. The problems we wish to solve are ones of maintainability and simplicity, and modest in scope: We think that having an unmodifiable FopFactory would allow developers to make certain assertions with absolute confidence about the state of the system; from the point when the Fop object is created (what I was unhelpfully referring to as deployment) to the closing of the render output stream. Currently, classes that contribute to the FOP process have access to the FopFactory and can conceivably modify it. Although this does not actually occur in the code-base, extension code with access to the FopFactory could, causing non-trivial bugs to emerge. There must be a really, really good reason to change the frontmost public API of FOP in a backwards-incompatible way. Changing the API will cause considerable work for all users when they upgrade. We must not do that on a whim. Absolutely. We are trying to make minimal API changes to achieve our objectives. The updates we are making to allow the external control of all IO will require more substantial changes to the API, and therefore we considered this a good time to make further changes. Assuming that breaking changes are inevitable during FOP's lifetime, I suppose we have to judge the impact of frequent minor breaks against infrequent major breaks and the associated development costs. I think that the designed public API (which has been previously discussed) of FOP and the actual public API (classes/members with visible access modifiers) are generally not close enough; and the wider the API, the harder we all have to work maintain backwards compatibility. The current API is the product of long discussions and a positive vote back in 2005/2006. It was roughly modelled after the JAXP pattern with TransformerFactory and Transformer. I'd say that the API has proven to be solid over the years. We do not propose a big change to this API and I am confident that they will are faithful to the ambitions of the API requirements [1]. Referring to the hard requirements HR1-15: HR1 Our proposal should make it configuration more consistent, there were disparities between how FOP was configured (an empty fop.xconf would configure FOP differently to the case when none was supplied!) HR3 I think we have simplified API by making the distinction between config and deployment explicit. HR4 We will fully document. HR6 Immutability configuration help to reduce concurrency related issues. HR10 This is addressed as part of the wider URI resolution work. HR13 All examples will be updated. The remaining requirements have not affected by the proposal. If we do proceed with these changes as part of the wider URI resolution work, we would expect them to be included into trunk as part of a later major revision. [1] http://wiki.apache.org/xmlgraphics-fop/ApiRequirements On Wed, Mar 28, 2012 at 7:08 PM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Hi Peter, can you please explain what problem you're trying to solve? From the Wiki pages I cannot derive that. And what do you mean by the separation of configuration and deployment? I'm particularly clueless as to how an API affects deployment here. There must be a really, really good reason to change the frontmost public API of FOP in a backwards-incompatible way. Changing the API will cause considerable work for all users when they upgrade. We must not do that on a whim. The current API is the product of long discussions and a positive vote back in 2005/2006. It was roughly modelled after the JAXP pattern with TransformerFactory and Transformer. I'd say that the API has proven to be solid over the years. For reference: http://wiki.apache.org/xmlgraphics-fop/ApiRequirements http://wiki.apache.org/xmlgraphics-fop/ApiDesign On 28.03.2012 12:02:27 Peter Hancock wrote: Hello, As part of our work addressing URI resolution in FOP [1], Mehdi and myself have been considering making changes to the configuration and deployment of FOP. Our proposal will introduce breaking changes to the public API that will affect code that embeds FOP. Please review our proposal [2] and provide feedback. Thanks, Peter [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration Jeremias Maerki
A proposal to change the configuration and deployment of FOP
Hello, As part of our work addressing URI resolution in FOP [1], Mehdi and myself have been considering making changes to the configuration and deployment of FOP. Our proposal will introduce breaking changes to the public API that will affect code that embeds FOP. Please review our proposal [2] and provide feedback. Thanks, Peter [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration
Re: Merging Temp_PDF_ObjectStreams branch to trunk
+1 Thanks for launching the vote Vincent! Peter On Thu, Mar 22, 2012 at 7:54 AM, Pascal Sancho pascal.san...@takoma.fr wrote: Hi, +0 I see no objection if PDF-image plugin is updated in a short delay (I mean: before next release). Le 21/03/2012 17:41, mehdi houshmand a écrit : If I'm not mistaken the r1302518 commit broke compile compatibility with the Jeremias' PDF-image-plugin trunk which needs to be addressed. It's a simple change if I'm not mistaken, just to do with how PDFDocument holds it's version (was an int now an enum o.a.f.pdf.Version), there maybe some other minor changes, but that one sticks out. Anyway, I haven't checked it myself, but trust yourself and Pete did a good job, +1 from me Mehdi On 21 March 2012 15:40, Vincent Hennebert vhenneb...@gmail.com mailto:vhenneb...@gmail.com wrote: Hi All, I’ve just uploaded our work on PDF object streams. If accessibility is enabled and PDF version 1.5 has been selected in the config file, then the structure tree will be stored in object streams. Support for cross-reference streams (a successor of the cross-reference table that appeared in 1.5) has been implemented in order to be able to address objects stored in object streams. The amount of space saved can be substantial, as much as 70% on a 20-page document. The changes are relatively localized and mostly affect the PDF packages. While there are significant refactorings, there is not a lot of new code. Therefore I’m inclined to handle this using lazy consensus; So if nobody objects within 72 hours, I’ll merge the branch back to trunk. Side note for those using the PDF Images plug-in: once the branch has been merged, the plug-in will have to be modified so that PDF objects do not output the obj/endobj wrapper themselves if they are indirect. This concerns the PDFBoolean and PDFString classes in o.a.f.render.pdf.pdfbox. Also, AbstractPDFStream now uses composition rather than inheritance for its dictionary, which requires changes to PDFBoxAdapter. Once the PDF Images plug-in has been moved under the umbrella of the XML Graphics project, we will upload the necessary changes. -- Pascal
Re: [VOTE] merge Temp_ImproveAccessibility to trunk
Hi All, I think with a +1 from me, now is a good time to close the vote. With a total of 5 +1s we are in favor of merging the improved accessibility work into trunk. Thank you to those who voted. Peter On Wed, Feb 8, 2012 at 1:58 PM, Clay Leeds the.webmaes...@gmail.com wrote: +1 from me. Peter, you might want to have a VOTE recorded too! ;-) My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On Feb 1, 2012, at 7:40 AM, Peter Hancock peter.hanc...@gmail.com wrote: Hi All, Vincent and I have recently been working to improve the generation of tagged PDF and we now propose merging the branch Temp_ImproveAccessibility into trunk. The objectives and an implementation plan was summarised by Vincent in [1] and development has remained fairly faithful to that proposal. A core objective of this work was to remove the XSLT pre-process stage and instead build the structure tree from FONode creation events and this has been realised. The new implementation has allowed us to fix a few bugs related to the structure tree representation of tables. Thanks, Peter [1] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/201109.mbox/%3C4E6624CE.1030703%40gmail.com%3E
Re: [VOTE] merge Temp_ImproveAccessibility to trunk
Thanks for bring these issues to my attention Chris. Revision 1240963 addresses all findbug and checkstyle warnings. Thanks, Peter On Thu, Feb 2, 2012 at 11:56 AM, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 01/02/2012 15:40, Peter Hancock wrote: Hi All, Hi Peter, Vincent and I have recently been working to improve the generation of tagged PDF and we now propose merging the branch Temp_ImproveAccessibility into trunk. The objectives and an implementation plan was summarised by Vincent in [1] and development has remained fairly faithful to that proposal. A core objective of this work was to remove the XSLT pre-process stage and instead build the structure tree from FONode creation events and this has been realised. The new implementation has allowed us to fix a few bugs related to the structure tree representation of tables. Looks like you've done some good work here. I checked out the code and compiled it. I ran Findbugs and it reports 61 new warnins compared to trunk. Please see the attached report. I have to vote -1 until the warnings are resolved. Thanks, Chris Thanks, Peter [1] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/201109.mbox/%3C4E6624CE.1030703%40gmail.com%3E
Re: Some characters are not displayed, or displayed incorrectly, or displayed as “#”.
Hi Tri Tran, The replay I just sent to Harshini applies for your case, too. From there we can check how you have configured your font, etc. See http://old.nabble.com/LazyFont-and-MultiByteFont-NullPointerException-td33126181.html Thanks, Peter On Wed, Jan 11, 2012 at 3:25 PM, Tran Van Tri trit...@temenos.com wrote: Dear Dev team, I generated PDF using FOP write by servlet, but I have problem VietNamese character, it display “#”. Pls help how I can correct Vietnamese character? Thanks, Tri Tran The information in this e-mail and any attachments is confidential and may be legally privileged. It is intended solely for the addressee or addressees. Any use or disclosure of the contents of this e-mail/attachments by a not intended recipient is unauthorized and may be unlawful. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of TEMENOS. We recommend that you check this e-mail and any attachments against viruses. TEMENOS accepts no liability for any damage caused by any malicious code or virus transmitted by this e-mail.
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
I will vote -0 with reasons I have already expressed in the 'Merge Request - Temp_ComplexScripts into Trunk' thread. I hope we can go forward refining this work, along with the rest FOP, through constructive collaboration, respecting the varied degrees of experiences, expertises and passion that we can all bring to the project. Peter [1] http://markmail.org/message/ti5233ftlxacau4a On Fri, Oct 28, 2011 at 3:40 PM, Vincent Hennebert vhenneb...@gmail.com wrote: This vote was launched while discussion was still going on on the mailing list. It would have been good to wait that a consensus is reached, which I don’t think has happened yet. What was the urgency to launch the vote now? I haven’t received any answer to my concerns about the following metrics: • 74 files in the o.a.f.fonts package In o.a.f.fonts.truetype.TTFFile: • 5502 lines • 150+ method declarations In the test o.a.f.complexscripts.util.TTXFile: • 3449 lines • 50+ field declarations • 1800 lines in the Handler.startElement method As it currently is, I believe that the font package will cause serious issues when merging other branches, fixing bugs or implementing other features. I don’t see what advantage does merging the Complex Scripts branch to trunk bring. Users who are skilled enough to check out a copy of the trunk, build it and test it can equally do it on a branch. For the rest of them, I don’t think that downloading a nightly build of trunk or a build of the branch would make any difference. ATM Simon is regularly uploading a build of the branch on his personal space at people.apache.org. I believe that this is exactly what non power users need, and I would be happy to take over this task if he is no longer willing to do it. If trunk is regularly merged to the branch (which I would also happily do), then it makes virtually no difference whether one is working on the trunk or on the branch. The new code deliberately ignores established code conventions by disabling Checkstyle rules. This makes it inconsistent with the rest of the code base and will unnecessarily distract people who try to understand it. I saw some slightly encouraging notes from Glenn that he is prepared to do some refactoring work on his code. I urge him to break down the fonts package and classes into smaller, more manageable components, and to do it as soon as possible. ATM I don’t believe that this code is maintainable by anyone else but Glenn. Therefore I think that merging it to Trunk is a bad idea. I’m not willing to provide any support for it at the moment, and the tone of his latest messages does certainly not encourage me to get involved in it in the future. Therefore, I’m voting -0.9. Vincent On 25/10/11 09:31, Simon Pepping wrote: With his latest patch, Glenn Adams wrote: With this latest patch I am satisfied that there is sufficient testing and stability in the CS branch to support its merger into trunk. Therefore, I request that such a merge be accomplished after applying patch 5 to the CS branch. ... snip ... Note that there remains work to be done on CS support, including adding support for: - additional scripts - additional output formats At present, support is provided for: - Arabic, Hebrew, and Devanagari Scripts - PDF output format I expect that additional support for other scripts and formats will be added over time, either by myself, or other members of the community. However, the absence of support for all complex scripts and all output formats should not be a deterrent to active use of the support already present. It is now a good time to broaden the user community of the CS features, and the best way to do that is to bring it into the trunk at this time. End of quote Following this request, I herewith propose to merge the branch Temp_ComplexScripts into trunk, and launch a formal vote. I vote positive: +1 For the rules of voting about code commits, see the project charter, article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter. Simon Pepping
Re: Merge Request - Temp_ComplexScripts into Trunk
On Mon, Oct 24, 2011 at 09:05:34PM +0800, Glenn Adams wrote: are you claiming my code is not maintainable by other developers? if so, then please prove it objectively; otherwise, let's stop talking about this, and move on with the merge vote How would one go about proving objectively that code is not maintainable? There are many aspects to writing maintainable code, spanning from the synax level through to the structuring of classes and modules (packages). Importantly we should encourage: Code reuse - (using trusted libraries, applying the DRY principle) hard to measure objectively A consistent style - this may be an emergent aspect of a project and choosing guidelines at the start or even retrospectively may be too difficult, but we can largely infer the style from the current state. An imperfect but consistent style is arguably favorable to inconsistency. Idiomatic language usage - applying common solutions that leverage the constructs of, and the philosophies behind a language (e.g applying OO design patterns in Java applications). I find that writing code that is in keeping with a the style of a project and using the language as recommended makes it easier to distill the intention of a piece of code from the implementation and can lead towards self-documenting code. The inner workings of FOP are complex and I think that all efforts to boost understandability are essential. Peter On Wed, Oct 26, 2011 at 12:55 PM, Glenn Adams gl...@skynav.com wrote: inline On Wed, Oct 26, 2011 at 7:17 PM, Vincent Hennebert vhenneb...@gmail.com wrote: On 24/10/11 14:05, Glenn Adams wrote: On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl georg.datt...@geneon.dewrote: Hello Glenn, (2) there is no standard for symbol length documented in FOP practice or enforced by checkstyle; I decline to exchange my choice of symbols with longer symbols simply because you prefer it that way; I have offered to add comments to my uses, and that is the most I'm willing to do to address this matter; You probably spent more years programming than I am alive, so please excuse me if that’s a stupid question: What is the reasoning/advantage behind those short variable names? First, I don't use short names everywhere. Mostly I just use in local variables, but generally not as class variables. Second, I was trained in Physics and Mathematics, which uses short variable names (E = M C ^ 2). Welcome to the Computer Science world, where longer variable names rule because they allow to make a program easier to understand and maintain. When I read the paper about the total-fit algorithm for breaking paragraphs into line, I found that the numerous one-letter variable names were an impediment to understanding it. It was difficult to remember what concept each variable was associated to. I had no trouble understanding it. In fact, I re-implemented it in Lisp (Scheme), and fixed a few issues in the process, which I reported to Don Knuth and for which he sent me a check for $2.56. See attached file. Note that I used long names for (structure) member names and dynamic variables, but often short names for local (lexical) variables in this code which I wrote 20 years ago. I haven't changed my style since then, and I don't intend to do so now. Third, I started programming in the 1960s with BAL 360, APL, then FORTRAN IV. We use short names there. Yes, it is very fortunate that the computer world has learnt from those old days, and moved on to embrace better programming practices. We are apparently in different generations, and this influences our thinking. I am not judging your style, but you seem to be quick to judge my style. Personally, I find ideology counterproductive. Fourth, I happen to have a good memory and I have no trouble remembering the meaning of variable names. Fifth, I find that short names prevents making lines too long and gives me more room for comments. By putting only one statement per line it is rare to bump into the 100 characters per line limit. Sixth, I am going to be maintaining this code. If anyone has a problem with specific code during a merge or regression, they merely need ask me. As Simon has already pointed out, this is not the way it should be in an open-source project. Seventh, that's just my style, and I assert it is as valid as doing it with long names. When I joined the FOP project, I adjusted my style to follow the project’s practices. It seemed obvious to me to do so, because a consistent style within a project avoids unnecessary distraction when wandering through its different parts. I would expect any contributor to do the same. Eighth, asking me to adhere to an undocumented convention that is not otherwise enforced, and for which there is no evidence or analysis of having been previously followed in FOP contributions is unwarranted. There is no documented convention simply
Re: Merge Request - Temp_ComplexScripts into Trunk
I wonder what you think about the code in o.a.f.hyphenation.TernaryTree, where the author apparently did not know Java, and introduces the libc functions strcmp, strcpy, and strlen, and which uses the Java char type (within the String type) for coding tree pointers! My apprehension about certain areas of your code (and not the majority!) stems from such examples, and the headaches theycan bring. This is old code that I had no influence over at the time and I do not want it to have any bearing on where the project is heading. If you wanted to make a serious case against using short names, you would start first by analyzing existing FOP usage and using such an analysis to establish concrete metrics. I do not think I have focused on the length of variable or member names have I? I did a PhD in mathematics and I have a soft spot for the aesthetic value of short names. It is always pleasing to distill a mathematical proof to the simplist form possible and using consise variable naming is often a part of that. That said, I do not think that working codebenefits from this approach: what can seem like an efficient and powerful piece of code when written can prove to be an overly difficult thing to read later. Unlike yourself, apparently, my memory ain't so good and I benefit from code that has clear intention. Peter
Re: Merge Request - Temp_ComplexScripts into Trunk
On Wed, Oct 26, 2011 at 2:13 PM, Glenn Adams gl...@skynav.com wrote: Notice also the considerable use of nested classes (and interfaces), which tends to make the file longer, but nevertheless encapsulates abstractions in smaller units. True, this file could be sub-divided into smaller files, and I may yet do that. However, I found it convenient to keep it in one file for the initial implementation. I appreciate that Java does not always help us when striving for well encapsulated code AND manageable file lengths! I really do not think you implementation is fundamentally that far off the mark and the amount of constructive attention it has received has naturally been proportional to the quantity - something that is very impressive! Peter
Re: Merge Request - Temp_ComplexScripts into Trunk
This is a tough one.
The need for complex script support in FOP is likely high on the wish
list of any global supporter of FOP and it is certainly in the
interest of the project to support. The amount of work that Glenn has
done is considerable: the volume of code, the test coverage and the
obvious depth of domain knowledge.
From the surface I would have been very much in favor of supporting a
merge in the near future, however I have had the chance to review some
areas of the complex script branch and I have some concerns.
The treatment of Unicode Bidi spans from the creation of the FO Tree
through to the construction of the Area Tree and I would have liked to
have seen the complex scripts solution integrate the Unicode Bidi
Algorithm more directly into the core process: For example, the
implementation performs a post process on the FO Tree to resolve the
Bidi properties of FONodes relating to text. It would be preferable to
see the construction of the FO Tree embracing this Bidi aspect:
FONodes should be responsible for determining their own bidi state
from the fo node semantics in context to the position in the tree.
Such an implementation would immediately force the maintainer to
consider how a change would effect the Bidi process.
The layout and area tree construction phase interact a little more
directly with the Bidi process, however most of the Bidi work is
delegated to static methods of a utility class (..layoutmgr.BidiUtil,
also used heavily in the Bidi post-process of the FO Tree) and
consequently require many instanceof expressions because of
differences in Bidi behavior between the Area classes. Areas should
be responsible for the character re-ordering process.
Having this functionality in FOP is desirable and I would encourage
steps to address these concerns, and those outlined by Chris and
Vincent.
Peter
On Thu, Oct 20, 2011 at 2:53 PM, Vincent Hennebert vhenneb...@gmail.com wrote:
The Complex Scripts feature is obviously a great enhancement and we
would all love to have it implemented in FOP. However, that should not
come at the expense of maintainability and the implementation of other
new features.
When I look at the code in the Temp_ComplexScripts branch, I have
serious concerns regarding the latter two points. I would oppose merging
the branch back to Trunk until those are resolved.
Here are the sizes of some new files:
1075 src/java/org/apache/fop/fonts/GlyphSequence.java
1089 src/java/org/apache/fop/fonts/GlyphProcessingState.java
1269
src/codegen/unicode/java/org/apache/fop/text/bidi/GenerateBidiTestData.java
2034 src/java/org/apache/fop/layoutmgr/BidiUtil.java
3449 test/java/org/apache/fop/complexscripts/util/TTXFile.java
This latter one contains more than 50 field
declarations, and the Handler.startElement method alone is more than
1800 lines long.
Also, the o.a.f.fonts.truetype.TTFFile class has now grown to
5502 lines. That’s 3 times its original size which was already too big.
I regularly find myself looking at bits of this class, and I would be
unable to do so on a 5500 line class.
I don’t think it needs to be explained why big classes are undesirable?
Also, most files disable Checkstyle checks, the most important ones
being line length and white space. Many files have too long lines which
makes it a pain to read through, having to horizontally scroll all the
time. We agreed on a certain coding style in the project and it would be
good if new code could adhere to it.
Speaking of variable names, here is a method picked from
o.a.f.fonts.GlyphSequence:
/**
* Merge overlapping and abutting sub-intervals.
*/
private static int[] mergeIntervals ( int[] ia ) {
int ni = ia.length;
int i, n, nm, is, ie;
// count merged sub-intervals
for ( i = 0, n = ni, nm = 0, is = ie = -1; i n; i += 2 ) {
int s = ia [ i + 0 ];
int e = ia [ i + 1 ];
if ( ( ie 0 ) || ( s ie ) ) {
is = s;
ie = e;
nm++;
} else if ( s = is ) {
if ( e ie ) {
ie = e;
}
}
}
int[] mi = new int [ nm * 2 ];
// populate merged sub-intervals
for ( i = 0, n = ni, nm = 0, is = ie = -1; i n; i += 2 ) {
int s = ia [ i + 0 ];
int e = ia [ i + 1 ];
int k = nm * 2;
if ( ( ie 0 ) || ( s ie ) ) {
is = s;
ie = e;
mi [ k + 0 ] = is;
mi [ k + 1 ] = ie;
nm++;
} else if ( s = is ) {
if ( e ie ) {
ie = e;
}
mi [ k - 1 ] = ie;
}
}
return mi;
}
Now I fully appreciate that one has to have some knowledge of an area to
understand code relating to that area, but no level of expertise,
however high, will help me to quickly
Re: [VOTE] to include the Mockito framework
6 +1 votes and Mockito has has been accepted. Peter On Mon, Oct 17, 2011 at 2:51 PM, Pascal Sancho pascal.san...@takoma.fr wrote: Hi, +1 for me Le 17/10/2011 15:06, Clay Leeds a écrit : I'll belly up to the bar and have a Mockito as well... ;-) +1 Sent from my iPhone On Oct 13, 2011, at 8:38 AM, Peter Hancock peter.hanc...@gmail.com wrote: I would like to launch a vote to include the Mockito framework and her dependencies in to FOP for unit testing. Some reasons for introducing a framework for mocking and stubbing, and Mockito in particular, have briefly been expressed [1] and patches have been provided [2] ... [4] that depend upon Mockito. Unit testing in FOP often proves difficult because it can be very hard to factor out dependencies: to run a piece of FOP code often requires substantial configuration. Mockito can go a long way in helping us here, and may even encourage us to write more unit tests! [1] http://markmail.org/message/zobrtzanojpkfysa [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50483 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=50391 [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=46962 +1 here. Peter -- Pascal
Re: [VOTE] to include the Mockito framework
could you describe the process you would like to see happen for incorporating the use of Mockito into fop? From a project setup point of view we just need 3 new jars in lib/build and an addition to the relevant classpath properties in build.xml. In terms of usage it is not a disruptive tool: I referred to it as a framework, but in fact it is a library and totally optional. Usage examples can be found at http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html Peter
[VOTE] to include the Mockito framework
I would like to launch a vote to include the Mockito framework and her dependencies in to FOP for unit testing. Some reasons for introducing a framework for mocking and stubbing, and Mockito in particular, have briefly been expressed [1] and patches have been provided [2] ... [4] that depend upon Mockito. Unit testing in FOP often proves difficult because it can be very hard to factor out dependencies: to run a piece of FOP code often requires substantial configuration. Mockito can go a long way in helping us here, and may even encourage us to write more unit tests! [1] http://markmail.org/message/zobrtzanojpkfysa [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50483 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=50391 [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=46962 +1 here. Peter
Re: svn commit: r1177251 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/BasicLink.java layoutmgr/inline/InlineLayoutManager.java pdf/PDFFactory.java
While fo:basic-link and fo:inline are both inline level elements, one is not the ancestor of the other and so FOP's model of the FO elements should reflect this, I believe. On Fri, Sep 30, 2011 at 8:43 AM, Glenn Adams gl...@skynav.com wrote: if I recall, I need this inheritance (from Inline) to work in the complex script branch as well On Fri, Sep 30, 2011 at 3:12 PM, Simon Pepping spepp...@leverkruid.eu wrote: On Thu, Sep 29, 2011 at 10:18:54AM -, phanc...@apache.org wrote: Author: phancock Date: Thu Sep 29 10:18:53 2011 New Revision: 1177251 URL: http://svn.apache.org/viewvc?rev=1177251view=rev Log: Fix FO tree hierarchy: BasicLink shouldn't inherit from Inline Why? A basic-link is an inline object which generates inline areas. Simon
Re: svn commit: r1177251 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/BasicLink.java layoutmgr/inline/InlineLayoutManager.java pdf/PDFFactory.java
By ancestor I refer to the relationship with respect to the fo: element hierarchy: Since the definition of fo:basic-link does not depend upon fo:inline, we cannot conclude that fo:basic-link is an fo:inline. The parameter entity %inline; refers to inline-level fo elements, fo:inline and fo:basic-link being members, and this is now reflected on the FOP FO object hierarchy, where Inline and BasicLink extend InlineLevel Have I understood the recommendation correctly, or have I missed anything? On Fri, Sep 30, 2011 at 1:18 PM, Glenn Adams gl...@skynav.com wrote: i'm not sure what you mean by 'ancestor', since containment relation is not at issue here; your argument is counter to the definition of the parameter entity %inline; defined in XSL 1.1 Section 6.2 The parameter entity, %inline; in the content models below, contains the following formatting objects: bidi-override character external-graphic instream-foreign-object inline inline-container leader page-number page-number-citation page-number-citation-last scaling-value-citation basic-link multi-toggle index-page-citation-list i believe you should first restore the previous state of affairs, and then, if you wish to continue making the case that it is not inline, take it up with the group and get consensus before making what appears to be a possibly unjustified architectural change On Fri, Sep 30, 2011 at 5:31 PM, Peter Hancock peter.hanc...@gmail.com wrote: While fo:basic-link and fo:inline are both inline level elements, one is not the ancestor of the other and so FOP's model of the FO elements should reflect this, I believe. On Fri, Sep 30, 2011 at 8:43 AM, Glenn Adams gl...@skynav.com wrote: if I recall, I need this inheritance (from Inline) to work in the complex script branch as well On Fri, Sep 30, 2011 at 3:12 PM, Simon Pepping spepp...@leverkruid.eu wrote: On Thu, Sep 29, 2011 at 10:18:54AM -, phanc...@apache.org wrote: Author: phancock Date: Thu Sep 29 10:18:53 2011 New Revision: 1177251 URL: http://svn.apache.org/viewvc?rev=1177251view=rev Log: Fix FO tree hierarchy: BasicLink shouldn't inherit from Inline Why? A basic-link is an inline object which generates inline areas. Simon
Re: Fop's build process
Thanks Mehdi for considering this, thats a +1 from me. This will require some work. A quick search on the subject of 3 to 4 migration yielded quite a few guides that pointed out some pitfalls. A general recommendation, for instance, is not to mix JUnit 3 and 4 conventions, e.g. est classes should not extend TestCase as this will instruct the framework to adopt JUnit 3 behavior. Unfortunately I could not find a defacto migration guide on the JUnit site, and I have no good reason to link to any other guide without evaluating in detail. If another member of our community has made the transition on another project and can offer advice, or perhaps can I point us to useful resources, this would be most welcomed! Thanks, Peter On Wed, Sep 14, 2011 at 10:16 AM, mehdi houshmand med1...@gmail.com wrote: Hi Guys, I want to propose an upgrade of our test system to JUnit 4, the benefits of upgrading can be found on plenty of blogs [1], but I just wanted to get a feel of what everyone thought? For those that aren't familiar with JUnit 4, it is backward compatible, so that may alleviate some migration worries. [1] http://weblogs.java.net/blog/fabianocruz/archive/2006/06/junit_4_you.html Mehdi
Re: Fop Memory Use
Hi Eric, Does your document contain many large SVG's? If so take a look at Bugzilla #46360. This issue was resolved in rev 997602 of FOP trunk. Pete On Wed, May 18, 2011 at 5:10 PM, Adrian Cumiskey adrian.cumis...@gmail.comwrote: Hi Eric, Fop calculates layout in page sequence chunks, so try breaking up your pages into chunks of page sequences. Pages should be available for garbage collection once the page sequence has been rendered. Cheers, Adrian. On May 18, 2011, at 7:24 AM, Michael Rubin mru...@thunderhead.com wrote: Just a wild thought. But is there a way you could possibly get the JVM to garbage collect between each run? Maybe that might free the memory up? Thanks. -Mike On 18/05/11 13:20, Eric Douglas wrote: I am using Fop 1.0. I tried using Fop to transform a single document. When I got a little over 100 pages my FO file was over 5 MB. The transform crashed with a Java heap out of memory error. I managed to break the input down, as I'm using embedded code generating the input programmatically, and the PDF output is a lot smaller. So I'm currently transforming 10 pages at a time, setting the initial-page-number to the next sequence (1, 11, 21, etc). Then I save all the generated PDFs in memory and merge them using pdfbox. So far this is working great. I tried to do the same thing with the PNGRenderer, just calling a method to transform 10 pages at a time and save the output images in an array. The PNGRenderer is created locally in the method. It should be getting released when the method ends but the java process never releases any memory. I tested a 90 page report and the memory use was over 1 GB. I tested on another machine where the memory limit is apparently lower and it crashed on page 24. Everything about the method to render to PNG is the same as the method to render to PDF aside from the Renderer. Is there a problem with this renderer or something I could need to do different? *Michael Rubin* Developer [image: Thunderhead Logo] [image: Tagline] [image: Triangles] *T* *F* *M* *E* *W* +44 20 8238 7400 +44 20 8238 7401 mru...@thunderhead.commru...@thunderhead.com www.thunderhead.com Thunderhead featured in The Sunday Times Profit Track 100 league table of companies with fastest-growing profits. Click herehttp://www.fasttrack.co.uk/fasttrack/press/pt11-lon.pdfto read more. [image: LinkedIn] http://www.linkedin.com/companies/25033/Thunderhead [image: twitter] http://twitter.com/Thunderheadon[image: RSS]http://www.thunderhead.com/rss/rss.php[image: YouTube] http://www.youtube.com/user/ThunderheadOnhttp://thunderheadinnovate.wordpress.com/ [image: were-hiring] http://thunderhead.com/about/careers.php The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
Re: PDF giving first page as blank
Hi, Can you provide an .fo file generated from this stylesheet that demonstrated the problem, please. If you are unsure how to do the transform just send some input xml. From there we can then run FOP and take a closer look. Thanks, Pete On Wed, Apr 20, 2011 at 4:05 PM, srmxslca vishal18...@gmail.com wrote: Hi , I am new new ot xsl:fo , when i generate a PDF using xsl:fo it is giving initial page as blank if number of pages are more than 1, if total number of pages = 1 in that case it is not giving blank pages. And the code for xsl:fo is as follows: ?xml version=1.0 encoding=ISO-8859-1? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:fo=http://www.w3.org/1999/XSL/Format; xsl:template match=/candidates fo:root fo:layout-master-set fo:simple-page-master master-name=my-page page-width=8in page-height=11.5in fo:region-body margin-top=0.60in margin-bottom=0.40in margin-left=0.20in margin-right=0.20in / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=my-page fo:flow flow-name=xsl-region-body fo:block fo:table text-align=center border-spacing=3pt fo:table-column column-number=1 / fo:table-column column-number=2 / fo:table-header fo:table-row fo:table-cell number-columns-spanned=2 /fo:table-cell /fo:table-row /fo:table-header fo:table-body xsl:apply-templates select=report-bO/candidate-ro-details/ /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root /xsl:template xsl:template match=report-bO/candidate-ro-details fo:table-row fo:table-cell height=3.5cm overflow=hidden number-rows-spanned=2 number-columns-spanned=1 fo:block fo:block text-align=left margin-left=40pt font-size=8pt white-space-collapse=false white-space-treatment=preservexsl:value-of select=attendancenumber//fo:block fo:block text-align=left margin-left=40pt font-size=8pt white-space-collapse=false white-space-treatment=preservexsl:value-of select=roname//fo:block fo:block text-align=left margin-left=40pt font-size=8pt xsl:value-of select=contactname//fo:block fo:block text-align=left margin-left=40pt font-size=8pt xsl:value-of select=filecasenumber//fo:block fo:block text-align=left margin-left=40pt font-size=8pt xsl:value-of select=addressline1//fo:block fo:block text-align=left margin-left=40pt font-size=8pt xsl:value-of select=addressline2//fo:block fo:block text-align=left margin-left=40pt font-size=8pt xsl:value-of select=addressline3/ xsl:choose xsl:when test=(string-length(addressline4)gt;0) ,#160;xsl:value-of select=addressline4/ /xsl:when xsl:otherwise fo:leader/ /xsl:otherwise /xsl:choose /fo:block fo:block text-align=left margin-left=40pt font-size=8ptxsl:value-of select=addressline5/ xsl:choose xsl:when test=(string-length(addressline6)gt;0) ,#160;xsl:value-of select=addressline6/ /xsl:when xsl:otherwise fo:leader/ /xsl:otherwise /xsl:choose /fo:block /fo:block /fo:table-cell /fo:table-row /xsl:template /xsl:stylesheet -- View this message in context: http://old.nabble.com/PDF-giving-first-page-as-blank-tp31441979p31441979.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]
Would the decision to move from SVN to another VCS be in the hands of the wider ASF community? Discussions about migrating from SVN to GIT are often held on infrastructure-...@apache.org and I imagine it is only a matter of time before this happens across the projects, and with sensible consideration. GIT certainly makes the creation and merging of branches easier to manage and this is just one of many features that FOP developers would gain from a switch to GIT or another DVCS (Distributed VCS). Another aspect of particular interest to contributors without committer status is that a DVCS gives every developer first class version control of their local development workflow, something that is not possible using SVN alone. Combining both SVN and GIT can get you a long way but as long as SVN is the central VCS there will remain a steep learning curve required to contribute effectively to FOP, and no satisfactory way of addressing the issue of submitting patches: Currently, contributors are encouraged to submit SVN compatible diffs to a Bugzilla issue, however this format does not contain the richness of information potential contained within a series local GIT commits. Submitting a GIT generated diff preserves the original workflow, but then defers the responsibility of handling the GiT SVN bridge onto the committer, further adding a layer of complexity to a job that the time stretched few currently struggle to keep on top of! I find GIT an indispensable tool and encourage all members of this community to investigate GIT, or perhaps other next generation DVCS (Distributed VCS), and see how they may help on both an individual and collaborative basis. Pete On Sat, Jan 29, 2011 at 10:08 PM, The Web Maestro the.webmaes...@gmail.com wrote: Are you saying you think we should consider: a) moving from SVN to GIT b) using GIT as a timesaver for conflicts? Clay Sent from my iPhone On Jan 29, 2011, at 12:24 PM, Simon Pepping spepp...@leverkruid.eu wrote: I read in the literature that GIT and Mercurial merge would be very much better at resolving possible conflicts than subversion. Today I tested this with the merge of the Temp_Color branch into trunk. In GIT I used the GIT repository at https://github.com/apache/fop. The merge of Temp_Color resulted in one conflict, in status.xml. The conflict was presented precisely, and was easily resolved. The merge in Subversion resulted in the following: Summary of conflicts: Text conflicts: 16 Property conflicts: 1 Tree conflicts: 68 The many tree conflicts were files that were removed in the branch and trunk or added in both. Obviously they were caused by the merges of trunk into Temp_Color earlier. After the merge in GIT I got no compilation errors. I got three failures in the junit tests, which were also present in the branch. I investigated a few cases which gave a conflict in subversion. They were resolved correctly in GIT. This merge result is a huge time saver, and I thought I should let you know. Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Re: The base of relative URIs in fop.xconf
Hi Simon, You beat me too it :-) I can confirm it works for a simple case I was considering. Thanks! Peter On Fri, Jan 14, 2011 at 1:04 PM, Simon Pepping spepp...@leverkruid.eu wrote: Done. Simon On Tue, Jan 11, 2011 at 07:40:59PM +0100, Simon Pepping wrote: On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: Hi, When configuring the base directory using the fop.xconf relative urls are based on the working directory, and not the fop.xconf. This contradicts the URI specification as pointed out in http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html I hate it when applications show this bug. I was not aware that FOP suffers from it. The problem must be solved as soon as possible. Can anyone suggest a robust way of achieving this scenario, given the current limitations of FOP, or should I fix this bug? It would be wonderful if you can provide a fix. Simon
The base of relative URIs in fop.xconf
Hi, When configuring the base directory using the fop.xconf relative urls are based on the working directory, and not the fop.xconf. This contradicts the URI specification as pointed out in http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html This can be more than an simple inconvenience when the working directory and the location of the fop.xconf are not related. Here is an example of something I wish to achieve with a set of limitations * I have a directory that contains both a fop.xconf and a directory of resources (fonts etc). * In the fop.xconf I want to reference resources relative to the fop.xconf. * I am unable to change path to the current working directory to coincide with the fop.xconf: e.g I may be running the FOP ant task that uses the location of the ant script as the working directory. * Using absolute paths is not an option since I wish to be able to move the fop.xconf without changing URIs referenced within. Can anyone suggest a robust way of achieving this scenario, given the current limitations of FOP, or should I fix this bug? Thanks, Pete
Re: Ant Hangs
Hi Eric, You can add the junit jar to Ant's lib directory - see http://ant.apache.org/manual/install.html and look for ANT_HOME + lib + Windows. I hope that helps, Pete On Mon, Dec 20, 2010 at 9:24 PM, mehdi houshmand med1...@gmail.com wrote: I'm no Windows expert by any stretch of the imagination, but have you tried adding the JUnit jar to the build XML, add the Ant jar to the Environment variables and try running it from the command line. I think you may have more luck there. Mehdi On 20 December 2010 21:12, Eric Douglas edoug...@blockhouse.com wrote: Windows XP -Original Message- From: mehdi houshmand [mailto:med1...@gmail.com] Sent: Monday, December 20, 2010 4:11 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: Ant Hangs Hi Eric, What OS are you using? If you're using Linux there are packages for installing the Ant and JUnit libraries which may avoid these issues. This I think is a config issue. Mehdi On 20 December 2010 20:28, Eric Douglas edoug...@blockhouse.com wrote: I compiled FOP 1.0 using the Ant build in Eclipse. It completed successfully saying Junit support not present. Then I downloaded the Junit source, imported it as a project, put it on the FOP Build Path, and copied the junit-4.8.2.jar into the FOP lib folder. Now the ant task shows Junit support present and the build never stops running. The last thing displayed on the Console message tab is this. junit-userconfig: [echo] Running user config tests
Re: Mocking a test
Hi, I have played with Mockito too, and found it very intuitive to use in contrast to EasyMock. Test are easier to understand and maintain when there intention is not obscured by complicated and verbose setup code, and api calls to mocking frameworks are often a major source of this problem. Mockito seems to stay out the way as much as possible, whilst being powerful enough to fulfil complicated mocking requirements. I have only ever tried out Mockito and EasyMock and so my support for Mockito is not based on that much experience, however Mockito does seem to be popular choice at the moment, is an active project and quite mature (though younger than EasyMock, JMock). I would certainly back the inclusion of Mockito into FOP. Pete On Sat, Nov 20, 2010 at 12:58 AM, Adrian Cumiskey adrian.cumis...@gmail.com wrote: Hi Medhi, That's a great suggestion. I really like to use the Mockito (http://code.google.com/p/mockito/) framework in my tests, it has a fluent interface that is really easy and comfortable to work with. Adrian. Sent from my iPad On Nov 20, 2010, at 12:08 AM, mehdi houshmand med1...@gmail.com wrote: Hi, I've been working on unit testing some of the classes in FOP and I think FOP could benefit from using a mocking framework. The goal is obviously that every class has a complimentary test class to test behaviour and state and mocking a class is a good way to emulate an object. I shan't make this into a lecture on the benefits, I've enclosed a good URL as to some of the benefits, but I wanted to put it to the community for feedback. This would mean including an extra JAR(s) file in the libs/ directory (obviously we'll have to be careful with licenses), but I'm just floating the idea if anyone has any preferred frameworks please do suggest pros/cons. http://martinfowler.com/articles/mocksArentStubs.html Thanks Mehdi
Re: FOP + JAXB
Hi Jason, I can imagine your motivation for creating a representation of an fo tree in a java application however feeding this into FOP directly would perhaps be a little wastful from FOP's point of view: FOP uses SAX to parse the fo input and then builds an internal representation of the FO tree. This is not just a deserialization of the tree into java beans- the FO Tree classes provides methods that capture the semantic complexity of the fo structure, one that cannot be represented in an .xsd. Navigating a DOM like structure and then generating the richer FOTree would promote an extra layer of processing and memory consumption, and is something we would want to avoid when dealing with large documents. This is not to say there is no value with your approach to generating fo. Maybe you could navigate your tree and generate sax events that can be handled by FOP's FOTree builder- I think this can be achieved in fairly straigt forward way, although I am no expert in chaining SAX processors. Perhaps a bit of bridging code maybe required and perhaps FOP would benefit from this. Hopefully some one else in the FOP community can confirm my thoughts here with perhaps a pointer for getting started. Pete On Fri, Nov 19, 2010 at 4:35 AM, Jason Harrop jhar...@gmail.com wrote: Hello I have used the JAXB tool XJC to generate a set of classes which represent http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/foschema/fop.xsd As wikipedia explains, Java Architecture for XML Binding (JAXB) allows Java developers to map Java classes to XML representations. JAXB provides two main features: the ability to marshal Java objects into XML and the inverse, i.e. to unmarshal XML back into Java objects. JAXB is similar to XMLBeans. It is JSR-222. You can see the Java classes for fop.xsd at http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/xslfo/org/plutext/jaxb/xslfo/ My motivation was initially to be able to create somewhat complex layout master set; see http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/main/java/org/docx4j/convert/out/pdf/viaXSLFO/LayoutMasterSetBuilder.java I'm planning to publish the code somewhere as a code base independent from docx4j. Is there any interest in having it as part of FOP? What if FOP could ingest these Java objects directly (ie without the having to be marshalled first)? If there is no interest, that's fine. I'll just put the code on Google Code, say. cheers . Jason
Re: svn commit: r1036179 [1/2] - in /xmlgraphics/fop/trunk: ./ examples/embedding/java/embedding/ src/java/org/apache/fop/afp/ src/java/org/apache/fop/afp/modca/ src/java/org/apache/fop/apps/ src/java
Hi, I think that representing acronyms as 'words' in class names should be generally preferred: Url url = ... is better than URL uRL = ... and UrlUriConverter is more readable than URLURIConverter Pete On Thu, Nov 18, 2010 at 11:25 AM, Vincent Hennebert vhenneb...@gmail.com wrote: Hi Simon, On 17/11/10 20:29, Simon Pepping wrote: On Wed, Nov 17, 2010 at 07:45:31PM -, spepp...@apache.org wrote: Author: spepping Date: Wed Nov 17 19:45:27 2010 New Revision: 1036179 URL: http://svn.apache.org/viewvc?rev=1036179view=rev Log: findbugs-reported bug squashing; 959 bugs left (findbugs 1.3.9) findbugs reports naming problems in public methods, such as setters and getters. I resolved those problems. But in doing so, in principle I am changing the public API. I do not think that every public method is really in use by other applications. Let me know when I go too far in those changes, harming applications that depend on fop. Good work, thanks for that. There are a few renamings that I’m not sure I agree with, though: • an ID is written ID, all upper case. Id is something else [1] that I believe is outside the scope of FOP ;-) So I would keep the names setID and getID, and not rename them into setId/getId. Affected classes are o.a.f.apps.PageSequenceResults, o.a.f.render.intermediate.extensions.AbstractAction and o.a.f.render.intermediate.extensions.URIAction [1] http://www.thefreedictionary.com/ID • likewise, URI is an acronym that’s always written upper case, and I think that should remain so. FWIW, the Java standard library uses names like toURI, toURL, etc. Affected classes are o.a.f.render.afp.AFPRendererImageInfo and o.a.f.render.ps.PSImageFormResource • namespace is not theoretically an English word but its use has been so pervasive (in the W3C Namespaces recommendation, to start with), that I would keep it like this. Affected classes are o.a.f.render.XMLHandler and descendants. WDYT? Thanks, Vincent
Re: Problem with FOP when generating a PNG
Hi Calixte, I saw that in Java2DPainter class the fonts are scaled by 1000 when used in drawText. In my mind you should do the same thing for drawImage. I made some tests and all is ok for me (and my plugin). I am a little unclear why you think coordinates should be scaled in the drawImage method. I do not see anything wrong with the awt output when processing fo with a png external-graphic. Are you suggesting that the scaling, currently done elsewhere, is best done here? I am glad you fixed your plugin- I had a look at your commit but it represented a large changeset so I did not really follow it. Pete On Sat, Nov 13, 2010 at 11:31 AM, Calixte Denizet cali...@contrib.scilab.org wrote: Hi Peter, I looked after the scale factor in the paint method of my Graphics2DImagePainter. When I export in pdf/ps, the scale factor is 1 and when I export in PNG, it's 1/1000. I saw that in Java2DPainter class the fonts are scaled by 1000 when used in drawText. In my mind you should do the same thing for drawImage. I made some tests and all is ok for me (and my plugin). What's your opinion ? Calixte Le jeudi 04 novembre 2010 à 13:09 +, Peter Hancock a écrit : Hi Calixte, Where you able to replicate the issue without integration with your plugin? Pete On Thu, Nov 4, 2010 at 10:16 AM, Calixte Denizet cali...@contrib.scilab.org wrote: Le jeudi 04 novembre 2010 à 10:02 +, Peter Hancock a écrit : Hi Calixte, Hello Peter, i) git clone git://git.forge.scilab.org/jlatexmath.git ii) cd jlatexmath iii) ant ant fop iv) you should have the 2 files jlatexmath-0.9.4.jar, jlatexmath-fop-0.9.4.jar in dist/, put them in the classpath (I put them in /usr/share/java in my Debian squeeze with sun java) v) cd cd plugin/fop/examples/ vi) fop -c conf.xml -fo latex.fo -pdf test.pdf works fine (thanks for that) vi) fop -c conf.xml -fo latex.fo -png test.png doesn't work since the latex images are not drawn. Thanks a lot Best regards Calixte Could you please describe the steps and attach any files required to replicate this bug independently of your plugin. If you are unable to do that and you think the bug may be in the plugin integration mechanism, we will require installation instructions for the fop plugin to proceed (maybe we jist need to add a jar but please let us know- it was not clear from the link). Thanks, Pete On Wed, Nov 3, 2010 at 8:28 PM, Calixte Denizet cali...@contrib.scilab.org wrote: Hi all, I wrote a FOP plugin to handle LaTeX notation in FO document. I use a class which extends AbstractImageConverter and with a target flavor equals to ImageFlavor.GRAPHICS2D. All is ok when I convert a .fo into a pdf or ps, but I met problems when I tryed to convert into png: the latex images are not drawn... I have no problems with fop 0.95 (I just retryed and all is ok), it is only with fop 1.0 and the trunk version. My loaders and converters can be found here: http://forge.scilab.org/index.php/p/jlatexmath/source/tree/master/plugin/fop/src/org/scilab/forge/jlatexmath/fop/image/loader Any ideas ? Calixte
Printing FOP generated PDF using PCL6 drivers
Dear FOP devs, I am working on rounded corner support in fop (see branch Temp_RoundedCorners for work in progress) and I have hit upon a problem whilst trying to print PDF to a printer using a PCL6 driver. Borders in PDF are created using a graphical streams of primitive drawing commands and the rounded variant makes use of cubic bezier curves. I am inconsistently not able to print rounded borders and I am hoping a snippet of the graphical stream of two border sections may provide a fop developer with enough info to debug the problem. The first snippet is part of PDF that is successfully transformed to printable PLC q 1 0 0 1 -10 0 cm 4.393 4.393 m 7.205 1.581 11.023 0 14.999 0 c 383.720001 0 l 387.696014 0 391.514008 1.581 394.325989 4.393 c 387.255005 11.464 l 386.317993 10.527 385.045013 10 383.720001 10 c 15 10 l 13.674 10 12.401 10.527 11.464 11.464 c h W n 0 G [] 0 d 15 w 0 7.5 m 398.720001 7.5 l S Q The next snippet does not work q 1 0 0 1 51.022999 785.195007 cm -0 -1 1 -0 0 0 cm 8.302 8.302 m 13.616 2.988 20.830999 0 28.344999 0 c 700.156982 0 l 707.671021 0 714.885986 2.988 720.200012 8.302 c 716.192017 12.31 l 711.940002 8.059 706.169006 5.668 700.156982 5.669 c 28.346001 5.669 l 22.333 5.669 16.562 8.059 12.31 12.31 c h W n 0.85098 0.14902 0.254902 RG [] 0 d 28.346001 w 0 14.173 m 728.502991 14.173 l S Q I am aware that the problem may be in the print driver (outside the scope of this list), or due to a wider context in the PDF, but I am consistently able to print embedded SVGs that FOP maps to equivalent graphical streams, and this leads me to conclude there may be a problem with the border generation code. Whilst debugging this issues I did notice that the coordinates are formatted to 6 decimal places in the border painting yet to 8 dps in org.apache.fop.svg.PDFGraphics2D ( the SVG to PDF bridge). Changing PDFBorderPainter to use 8 dps did not solve my problem, however I am wondering why the discrepancy exists. Please prompt me for more details if you are able to offer any help Thanks in advance, Pete
Re: Problem with FOP when generating a PNG
Hi Calixte, Could you please describe the steps and attach any files required to replicate this bug independently of your plugin. If you are unable to do that and you think the bug may be in the plugin integration mechanism, we will require installation instructions for the fop plugin to proceed (maybe we jist need to add a jar but please let us know- it was not clear from the link). Thanks, Pete On Wed, Nov 3, 2010 at 8:28 PM, Calixte Denizet cali...@contrib.scilab.org wrote: Hi all, I wrote a FOP plugin to handle LaTeX notation in FO document. I use a class which extends AbstractImageConverter and with a target flavor equals to ImageFlavor.GRAPHICS2D. All is ok when I convert a .fo into a pdf or ps, but I met problems when I tryed to convert into png: the latex images are not drawn... I have no problems with fop 0.95 (I just retryed and all is ok), it is only with fop 1.0 and the trunk version. My loaders and converters can be found here: http://forge.scilab.org/index.php/p/jlatexmath/source/tree/master/plugin/fop/src/org/scilab/forge/jlatexmath/fop/image/loader Any ideas ? Calixte
Re: Problem with FOP when generating a PNG
Hi Calixte, Where you able to replicate the issue without integration with your plugin? Pete On Thu, Nov 4, 2010 at 10:16 AM, Calixte Denizet cali...@contrib.scilab.org wrote: Le jeudi 04 novembre 2010 à 10:02 +, Peter Hancock a écrit : Hi Calixte, Hello Peter, i) git clone git://git.forge.scilab.org/jlatexmath.git ii) cd jlatexmath iii) ant ant fop iv) you should have the 2 files jlatexmath-0.9.4.jar, jlatexmath-fop-0.9.4.jar in dist/, put them in the classpath (I put them in /usr/share/java in my Debian squeeze with sun java) v) cd cd plugin/fop/examples/ vi) fop -c conf.xml -fo latex.fo -pdf test.pdf works fine (thanks for that) vi) fop -c conf.xml -fo latex.fo -png test.png doesn't work since the latex images are not drawn. Thanks a lot Best regards Calixte Could you please describe the steps and attach any files required to replicate this bug independently of your plugin. If you are unable to do that and you think the bug may be in the plugin integration mechanism, we will require installation instructions for the fop plugin to proceed (maybe we jist need to add a jar but please let us know- it was not clear from the link). Thanks, Pete On Wed, Nov 3, 2010 at 8:28 PM, Calixte Denizet cali...@contrib.scilab.org wrote: Hi all, I wrote a FOP plugin to handle LaTeX notation in FO document. I use a class which extends AbstractImageConverter and with a target flavor equals to ImageFlavor.GRAPHICS2D. All is ok when I convert a .fo into a pdf or ps, but I met problems when I tryed to convert into png: the latex images are not drawn... I have no problems with fop 0.95 (I just retryed and all is ok), it is only with fop 1.0 and the trunk version. My loaders and converters can be found here: http://forge.scilab.org/index.php/p/jlatexmath/source/tree/master/plugin/fop/src/org/scilab/forge/jlatexmath/fop/image/loader Any ideas ? Calixte
Re: DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page segment functionality for AFP rendering
Hi Jeremias, Thanks for committing the patch. BTW, while working on this it occurred to me that with the embedding functionality, we're actually making page segment handling overly complicated: we always need a replacement image that the layout image is actually working with. I'm not saying that this addition was a bad one, but we should think about making it easier in the future, namely by supporting AFP page segments True directly through fo:external-graphic. The first step here would be native embedding support (just reading the intrinsic size of the page segment). A In the case when the page segment is not available at AFP generation time (to be referenced), maybe another method of specifying the image metrics, rather than a placeholder image? For standard images like a company logo etc, the metrics maybe easier to distribute than this? second step could even be decoding page segments and supporting them for other output formats. Just a thought. ..and perhaps compressing if we can support that in the future! Cheers, Pete On Thu, Oct 7, 2010 at 8:48 AM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=49379 Jeremias Maerki jerem...@apache.org changed: What |Removed |Added Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jeremias Maerki jerem...@apache.org 2010-10-07 03:48:24 EDT --- Patch applied with modifications as discussed: http://svn.apache.org/viewvc?rev=1005350view=rev Thanks, Peter, and sorry for the long time it took to process your patch! BTW, while working on this it occurred to me that with the embedding functionality, we're actually making page segment handling overly complicated: we always need a replacement image that the layout image is actually working with. I'm not saying that this addition was a bad one, but we should think about making it easier in the future, namely by supporting AFP page segments directly through fo:external-graphic. The first step here would be native embedding support (just reading the intrinsic size of the page segment). A second step could even be decoding page segments and supporting them for other output formats. Just a thought. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Rounded Corners
Thanks for your comments Jeremias! I will prepare a patch with some test files for the community to take a look at. Working from a branch would certainly ease some of the merging headaches I have been getting. Pete On Thu, Sep 9, 2010 at 1:41 PM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Hi Peter My comments below... On 09.09.2010 11:57:51 Peter Hancock wrote: Hi, I have been working on rounded border support in FOP recently and I have come to a sticking point which I hope you can help with. First a little info regarding my work: I have used fox extension attributes to prescribe the elliptic properties of the corners as suggested in http://wiki.apache.org/xmlgraphics-fop/RoundedBorders I have not presented my code to the FOP community yet for a few reasons: The code is currently rather experimental in parts and breaks some of the design considerations currently in the painters. AFP support requires much more work: I have not implemented a solution using GOCA yet, instead opting for IOCA rendering of the whole block. This decision was driven by in house requirements and not as elegant perhaps as the GOCA solution. I'm not so sure. GOCA is relatively simplistic IMO and not supported well enough everywhere. At least I don't like GOCA at all and prefer a bitmap image for a fixed-resolution environment like AFP. But not everyone thinks like that. The common ground is always page segments. I learned that when rounded borders are required in the AFP environment, that people often create pre-generated page segments (IOCA in the end) to paint the borders (especially the rounded ones) in exactly the way they need it. The advantage of bitmaps in AFP is: since you know exactly the resolution the printer will work with, you can produce bitmaps tailored exactly for this resolution with a high quality tool (Java2D). I am not sure whether there would be enough interest in this feature to warrent starting a process a la the Complex Scripts feature? Should I continue to work in isolation and submit a patch for community review at a time I feel it is ready? First, I think there is interest in this feature. I remember multiple inquiries on our user list. It is in the works for CSS3. It was in the XSL 2.0 requirements, but surprisingly not in the first working draft. Still, some commercial implementations have extensions for this. Second, if you find yourself in a tight corner, it makes sense to reach out. You do that now and I've had to do it this week, too. So, why not put this in a branch where people can look at it and maybe help? Well, we do have to be careful not to create too many branches which never get finished, but more often that not they are. For example, my color branches are almost ready to be merged back into the trunks. Just a final effort left. My agenda here is to hopefully receive some help: I have come to a sticking point with the IF format. Currently block-like areas with a border are represented in the form g rect .../ /g border-rect x= y= width= height= before=(solid,#ff,1) ... / The rect element is used for the background colour of the block, and the border-rect element is used to draw the border. Currently I have overloaded the before|after|start|end attribute to include the ellipse radii (their meaning is not important in this query). When I produce a PDF from IF I am able to generate curved borders however I have not changed rect to incorporate rounded corners as I am not sure whether this would be deemed appropriate. What should I do? Should rect be overloaded? Should the grect//gborder-rect/ be replaced by something else? I am aware that structural changes to the IF should not be taken lightly but I also worry that overloading rect is a hacky solution. IMO, the IF has to grow with the requirements, be that complex scripts or rounded borders. Where possible we should be backwards-compatible. Implementations will simply ignore what they don't support. Let's design it on the Wiki page and bring it to a point where we're all happy. I suspect you mention rect and border-rect because, at the moment, they are used independently. And they may need to be specified together for rounded borders? IMO, border-rect doesn't have to stay a single-element with no content. If it unclutters the attributes, a defined set of child elements may be totally OK. After all, we get feedback every now and then that the PDF borders don't look to good in Adobe Acrobat Reader due to anti-aliasing side-effects. Maybe we can even optimize a bit in this direction, namely to paint more than one border segment at a time. My suggestion is that you bring your code to a presentable state and submit it as a patch and I can then look into it with you. I'm pretty sure this is important enough for your employer so I can get a few hours to help you. Jeremias Maerki
Rounded Corners
Hi, I have been working on rounded border support in FOP recently and I have come to a sticking point which I hope you can help with. First a little info regarding my work: I have used fox extension attributes to prescribe the elliptic properties of the corners as suggested in http://wiki.apache.org/xmlgraphics-fop/RoundedBorders I have not presented my code to the FOP community yet for a few reasons: The code is currently rather experimental in parts and breaks some of the design considerations currently in the painters. AFP support requires much more work: I have not implemented a solution using GOCA yet, instead opting for IOCA rendering of the whole block. This decision was driven by in house requirements and not as elegant perhaps as the GOCA solution. I am not sure whether there would be enough interest in this feature to warrent starting a process a la the Complex Scripts feature? Should I continue to work in isolation and submit a patch for community review at a time I feel it is ready? My agenda here is to hopefully receive some help: I have come to a sticking point with the IF format. Currently block-like areas with a border are represented in the form g rect .../ /g border-rect x= y= width= height= before=(solid,#ff,1) ... / The rect element is used for the background colour of the block, and the border-rect element is used to draw the border. Currently I have overloaded the before|after|start|end attribute to include the ellipse radii (their meaning is not important in this query). When I produce a PDF from IF I am able to generate curved borders however I have not changed rect to incorporate rounded corners as I am not sure whether this would be deemed appropriate. What should I do? Should rect be overloaded? Should the grect//gborder-rect/ be replaced by something else? I am aware that structural changes to the IF should not be taken lightly but I also worry that overloading rect is a hacky solution. Any thoughts welcome Kind Regards, Pete
Re: DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page segment functionality for AFP rendering
Hi Jeremias, I totally agree with you here. Time constraints did not allow me to create a proper parser/object model for the AFP resource but it is the only sensible way to read them safely - as your error reinforces. It would be great to use your MO:DCA parser to improve this feature, when you are ready to integrate it. Thanks for your comments Peter On Fri, Aug 20, 2010 at 8:47 AM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=49379 --- Comment #2 from Jeremias Maerki jerem...@apache.org 2010-08-20 03:46:59 EDT --- Peter, I've taken a look at your patch. I found that I get an IOException when referencing the page segment s1islogo.psg that comes with IBM AFP Workbench: java.io.IOException: Malformed AFP resource with name 's1islogo': No Begin structured field at org.apache.fop.afp.util.AFPResourceUtil.copyNamedResource(AFPResourceUtil.java:123) I have the impression that the method AFPResourceUtil.findStart() may not be ideal to parse an MO:DCA file. I haven't investigated more closely why the above file fails, but stepping through findStart() feels a bit weird in terms of how that method looks for the requested resource. Some time ago I started a rudimentary AFP parser I used to dump the Type 1 data from an outline font, or to simply dump the basic structure of an AFP file. I could include that in FOP and we build from there. It allows to return an object for each structured field encountered. A generic MO:DCA parser would also allow future functionality that involves parsing an AFP file. WDYT? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: AFP colour images
Hi Jeremias, Thanks for looking into this. I am finding that the colours in the PTOCA and the F11 IOCA appear identical in the viewers that I have tried too. I printed your example and the the background colour #FFCC00 appears identical. I tried this shade with my rounded corners with identical results. Using your fo as a template I have printed out a range of different colours (64 different colours - #xyx such that x,y,z in [2,6,A,E]) and I have noticed that only a handful have a good colour match between the PTOCA and the rastered SVG- I think you were lucky in your pick of #FFCC00 :-) It could be the printer and I will investigate further. Thanks again Jeremias! Pete On Tue, Aug 10, 2010 at 10:16 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Hi Peter I did some experiments mixing PTOCA-built backgrounds with GOCA-built rectangles and SVG converted to bitmaps (see attached FO). When I look into the generated file, all three elements use the same RGB values (#FFCC00). What we need to keep in mind here is that all colors are interpreted in sRGB color space. But that information doesn't make it into the AFP file due to lack of extended color support for AFP output in FOP. The colors in the AFP are therefore interpreted in a device-dependent way. Still, I'd expect all RGB values to be interpreted in the same way. When I check with the usual AFP viewers, I don't see any mismatched colors. Maybe the printer you're using does have some kind of extended color management (which the viewers may not have) but maybe not for all elements. That would suggest that the PTOCA colors and the image colors in your case are somehow interpreted differently. In the end, I have absolutely no idea what could cause the color mismatch. :-( You may need to ask the printer manufacturer. On 05.08.2010 13:07:47 Peter Hancock wrote: Hi, I am having colour problems with AFP and wonder if the FOP community can help me. I have a fo:block with a non-white background- colour (an arbitrary #AFA) and I have modified FOP to overlay an image that is largely composed of the same colour. The image is defined within the AFPPainter using a org.apache.xmlgraphics.java2d.Graphics2DImagePainter2D; the Graphics2D drawing commands being defined in the pai nt method. This is then wrapped in a org.apache.xmlgraphics.image.loader.impl.ImageGraphics2D and passed to AFPPainter.drawImage. This method is responsible for rendering the image: A stack trace shows that a call org.apache.xmlgraphics.image.loader.impl.ImageConverterG2DBitmap.convert is responsible for generating a BufferedImage. FOP then uses AFPImageHandlerRenderedImage to handle the image: the bytes of the buffered image are directly written to the AFP and the image is tagged as an FS11 IOCA. When I print the afp there is a visible difference in the blocks background colour and the images background colour and so I would like to know what sort of steps and considerations are required to resolve this. I am currenty unclear exactly how the coloured areas of block like elements are represented in the AFP and how I can synchronize this with image creation. Whilst I research this further myself, it would be great to have the knowledge confirmed by other FOP developers with experience here. This issue has cropped whilst working on a FOP extension for drawing rounded corners as my solution for generating them for AFP is to use corner images. I am not using GOCA due to print server support issues. I would be very grateful for any of your thoughts. Thanks, Pete Jeremias Maerki
AFP colour images
Hi, I am having colour problems with AFP and wonder if the FOP community can help me. I have a fo:block with a non-white background- colour (an arbitrary #AFA) and I have modified FOP to overlay an image that is largely composed of the same colour. The image is defined within the AFPPainter using a org.apache.xmlgraphics.java2d.Graphics2DImagePainter2D; the Graphics2D drawing commands being defined in the pai nt method. This is then wrapped in a org.apache.xmlgraphics.image.loader.impl.ImageGraphics2D and passed to AFPPainter.drawImage. This method is responsible for rendering the image: A stack trace shows that a call org.apache.xmlgraphics.image.loader.impl.ImageConverterG2DBitmap.convert is responsible for generating a BufferedImage. FOP then uses AFPImageHandlerRenderedImage to handle the image: the bytes of the buffered image are directly written to the AFP and the image is tagged as an FS11 IOCA. When I print the afp there is a visible difference in the blocks background colour and the images background colour and so I would like to know what sort of steps and considerations are required to resolve this. I am currenty unclear exactly how the coloured areas of block like elements are represented in the AFP and how I can synchronize this with image creation. Whilst I research this further myself, it would be great to have the knowledge confirmed by other FOP developers with experience here. This issue has cropped whilst working on a FOP extension for drawing rounded corners as my solution for generating them for AFP is to use corner images. I am not using GOCA due to print server support issues. I would be very grateful for any of your thoughts. Thanks, Pete
Re: AcroForm extension
Hi Alessandro, First off this is a development discussion and should be moved to fop-dev mailing list - if you have not subscribed to this yet I suggest you do for further discussion (see http://xmlgraphics.apache.org/fop/maillist.html). I have been working on an implementation of AcroForms (Following PDF Ref 1.4 - FOP's PDF library mostly adheres to this spec). Before you take on this task alone it would be a good idea if you review my progress: I am at a fairly early stage although * Written draft specification for fox extensions * Extended FOP's PDF library (package org.apache.fop.pdf) to include a fairly comprehensive set of PDF's acroform elements * Implemented a simple text label and pushbutton usecase I will shortly submit a patch to FOP and put documentation on the FOP wiki. It would be fantastic to get your thoughts on this and hopefully save you independently doing the same thing! Your approach to develop the extension as a pluggable module is theoretically the correct approach, however you may run into problems- perhaps insurmountable ones! Althougth the FO tree building and the layout/ area tree building stages both support pluggable extension in principle, some parts of the system currently do not: The rendering of fox extension elements, for example, is handled by the core renderers/painters and it does not seem trivial (possible?) to delegate at these stages to an external handler. I see some of the major challenges in developing the right implementation including: * Defining fox elements that exploit the rich appearances that can be prescribed to pdf fields * With regards to layout, defining the right bridge between existing fo elements and PDF e.g. text labels may behave like fo:inline elements, multiline text fields may have the layout behaviour of fo:blocks etc) * Externalising the rendering/painting code - perhaps not possible Peter On Mon, May 10, 2010 at 8:14 PM, Alessandro Marino ale.marin...@gmail.comwrote: I'm trying to implement an extension to add AcroForm (§ 8.6 page 671 of PDF Reference 1.7) to a PDF document. Below there are my thoughts about the process of building such extension, could anyone tell me if there's somethig wrong? I have to create a jar and configure an ElementMapping provider adding the file /META-INF/services/org.apache.fop.fo.ElementMapping with the fully qualified classname of my ElementMapping implementation class. The ElementMapping implementation is responsible to provide a Maker class that adds an objectified representation of the xsl tag to the FOTree. After the creation of the FOTree the LayoutManagerMapping is initialized inside the AreaTreeHandler. The LayoutManagerMapping holds the association between each FONode and its LM. For the first version of this extension I would prefer (to simplify things) to have a LM that puts an AcroForm field on its own line. How do I configure a LM for these objects? It doesn't seem to exist an extension point for LM, obvious extension points are represented by: ElementMapping, ContentHandlerFactory, Renderer, FOEventHandler, PDFImageHandler, XMLHandler (for which I can configure an implementation class provider in META-INF/services). I saw the LayoutManagerMaker interface that has various methods for creating a LM from a FONode or from another LM. Do I need to add another method to this interface? Then I needs two things to render an AcroForm in PDF: * an array in the catalog dictionary (§ 3.6.1 page 141) that holds all references to each field. Do I need to patch the PDFRoot object to add such array for example with a method setAcroForm? * a field dictionary (page 674) for each field Thanks and regards, Alessandro
Re: new patch, bug 48975
Hi Yannick, The process is briefly described here http://xmlgraphics.apache.org/fop/dev/index.html#patches The time taken to process depends upon the size of the patch queue (see the Patch Queue node under the Develop branch of the left-hand menu tree of http://xmlgraphics.apache.org/fop/dev/index.html) and the number of active committers available to process it. Your patch will be very quick to review and commit assuming you are right about the convention taken with extensions. Not being a committer myself I am unable to help, but I am sure you will not have t owait too long. Peter On Mon, Mar 29, 2010 at 11:39 AM, Yannick Majoros yannick.majo...@uclouvain.be wrote: Hi, Last week, I submitted a bug report and a patch (48975, https://issues.apache.org/bugzilla/show_bug.cgi?id=48975). What's next? Yannick Majoros
Re: new patch, bug 48975
Hi Yannick, I think you need t ochange your bug report. The Product field should be FOP, and not the parent project Xml Graphics Commons. Peter On Mon, Mar 29, 2010 at 1:01 PM, Yannick Majoros yannick.majo...@uclouvain.be wrote: Le 3/29/2010 1:44 PM, Peter Hancock a écrit : Hi Yannick, The process is briefly described here http://xmlgraphics.apache.org/fop/dev/index.html#patches The time taken to process depends upon the size of the patch queue (see the Patch Queue node under the Develop branch of the left-hand menu tree of http://xmlgraphics.apache.org/fop/dev/index.html) and the number of active committers available to process it. Your patch will be very quick to review and commit assuming you are right about the convention taken with extensions. Not being a committer myself I am unable to help, but I am sure you will not have t owait too long. Hi, Thank you for this information. I couldn't find my patch in the patch queue, why? Yannick
Interactive PDF
Hi, I need FOP to handle interactive PDF (see § 8.6 of http://www.adobe.com/devnet/pdf/pdfs/PDFReference15_v6.pdf). An implementation of this will involve defining an extension schema for the xsl-fo, adding PDF form elements and utilies to the PDF library under the org.apache.fop.pdf package and extending the .fo to .pdf process. I will begin by experimenting with the PDF library, and I will document my findings on the FOP wiki. Any feedback from the community regarding this development would be greatly appreciated. Peter Hancock
Re: [ERROR] Image not found
Hi Paulo,
I imagine that the problem has something to do with the container hosting
the web service. The image location is given as a relative path which may
not resolve to where you think it does. Perhaps try supplying an absolute
path to test this theory. The answer may depend upon how you package your
web app - do you bundle the image as well?
Maybe try looking for IO related information in the web container
documentation. If you are unable to solve the problem please send more
information about the environment that your code runs in.
I hope that helps,
Peter
On Thu, Feb 18, 2010 at 7:07 AM, Paulo Carvalho pjcarva...@gmail.comwrote:
Hello
I used a simple example on the Internet about how to use FOP in java (
http://javaboutique.internet.com/tutorials/FOP/):
- I Created a simple Java application with a class that takes an XML and
converts it into a PDF (using a XSL) containing an image. The name of my
class is Process.java and it has a method process. It works fine when
called directly as a java application.
- I Created a simple web service that just call this process method of
that class. However, when i call the web service, i get an error:
[ERROR] Image not found: img/logo.gif
= The PDF is created but without the image.
Here is the code of my Process.java class:
public static String process(String xml, String xsl) {
String sResult = null;
try {
ByteArrayOutputStream foOut = new ByteArrayOutputStream();
ByteArrayOutputStream bOut = new ByteArrayOutputStream();
InputStream iss =
Process.class.getClassLoader().getResourceAsStream(brique);
copyFile(new BufferedInputStream(iss), bOut);
SAXBuilder builder = new SAXBuilder();
Document document = builder.build(new
ByteArrayInputStream(xml.getBytes()));
TransformerFactory factory = TransformerFactory.newInstance();
InputStream iXsl = Process.class.getClassLoader().getResourceAsStream(xsl);
StreamSource iSource = new StreamSource(iXsl);
Transformer foTrans = factory.newTransformer(iSource);
StreamSource strSourceXML = new StreamSource(new
ByteArrayInputStream(xml.getBytes()));
foTrans.transform(strSourceXML, new StreamResult(foOut));
foOut.flush();
ByteArrayOutputStream pdfOut = new ByteArrayOutputStream();
TransformerFactory tFactoryFO2PDF = TransformerFactory.newInstance();
Transformer pdfTrans = tFactoryFO2PDF.newTransformer();
FopFactory fopFactory = FopFactory.newInstance();
FOUserAgent foUserAgent = fopFactory.newFOUserAgent();
Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent, pdfOut);
Result res = new SAXResult(fop.getDefaultHandler());
StreamSource streamSourceXml = new StreamSource(new
ByteArrayInputStream(foOut.toByteArray()));
pdfTrans.transform(streamSourceXml, res);
java.io.File file = new java.io.File(d:/res.pdf);
FileOutputStream foStream = new FileOutputStream(file);
pdfOut.writeTo(foStream);
} catch(Exception e) {
e.printStackTrace();
}
return sResult;
}
private static boolean copyFile(InputStream in, OutputStream out) {
try {
int c;
while ((c = in.read()) != -1)
out.write(c);
in.close();
out.close();
} catch (IOException io) {
return false;
}
return true;
}
The code of my web service is just:
public static String process(String xml, String xsl) {
String sResult = null;
try {
sResult = Process.process(xml, xsl);
System.out.println(sss);
} catch(Exception e) {
e.printStackTrace();
}
return sResult;
}
The web service has the JAR of the Java application in his classpath. The
content of the Jar file is the following one:
NamePath
briques.xsd
logo.gif img\
Manifest.mf meta-inf\
Process.class tst
saxon-licence.lic
xsl2.xslt
I call the web service with the following parameters:
xml = ?xml version='1.0' encoding='UTF-8'?+
Catalog+
Book+
TitleMastering EJB/Title+
AuthorEd Roman/Author+
Price$45.00/Price+
/Book+
Book+
TitleDesign Patterns/Title+
AuthorErich Gamma/Author+
Price$50.00/Price+
/Book+
Book+
TitleEffective Java/Title+
AuthorJosch Bloch/Author+
Price$30.00/Price+
/Book +
/Catalog;
xsl = xsl2.xslt;
In the xsl2.xslt I have a part of code like this to insert the image on the
pdf:
...
fo:block
fo:external-graphic src=img/logo.gif/
/fo:block
...
The XSL is found in the JAR because the PDF file is generated. But the
following error still appearing and the image is not inserted on the PDF:
[ERROR] Image not found: img/logo.gif
What am I doing wrong?
Thanks
Regards
--
Paulo Carvalho
1 rue du Chateau
57710 Aumetz
France
http://forum-informatico.forumeiros.com/index.htm
http://ummundoecologico.blogspot.com
fop.jar's MANIFEST.MF
Hi all, Does anyone know the why the Build-Id property of the MANIFEST.MF file should include the ant property 'java.runtime.version', yet not the 'javac.target' property used by the javac task in the compile target? I appreciate that the version of the JVM running ant may perhaps affect the build process, but is it not more useful to have info on the JVM that the fop.jar is compiled for? Thanks for any comments in advance, Peter
Re: trying to debug using eclipse
Hi Martin Is build/gensrc on your classpath? This gets generated during the default ant task. Pete On Sat, Feb 6, 2010 at 3:28 AM, martin.e...@asmorphic.net.au wrote: Hi Guys, Wondering if there are any tips of what i'm doing wrong - have built the application using ant, and it says it was built successfully. Can see the event-models.xml in the accessibility section, however, when running the application from eclipse, I get: NFO: Default page-width set to: 210mm Exception in thread main java.lang.ExceptionInInitializerError at org.apache.fop.apps.FOUserAgent.init(FOUserAgent.java:102) at org.apache.fop.apps.FopFactory.newFOUserAgent(FopFactory.java:188) at org.apache.fop.cli.CommandLineOptions.parse(CommandLineOptions.java:171) at org.apache.fop.cli.Main.startFOP(Main.java:158) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.util.MissingResourceException: File event-model.xml not found at org.apache.fop.events.model.AbstractEventModelFactory.loadModel(AbstractEven tModelFactory.java:46) at org.apache.fop.accessibility.AccessibilityEventProducer$EventModelFactory.cr eateEventModel(AccessibilityEventProducer.java:54) at org.apache.fop.events.DefaultEventBroadcaster.clinit(DefaultEventBroadcast er.java:73) ... 5 more Any suggestions on where I should start looking? THanks Martin
Re: trying to debug using eclipse
Hi Martin, Putting build/gensrc on the Java build path should have done it. Try deleting the project (not the source) and running 'ant clean' then 'ant' from the command line. Then create the project again in eclipse and try running fop again. I assume you hve fop-hyph.jar in your fop/lib folder too. I hope this does it for you! Pete On Sun, Feb 7, 2010 at 8:35 AM, Martin Edge martin.e...@intellimail.com.auwrote: Within eclipse it says it's within the 'build path' or do you mean within Java's class path?* * *From:* Peter Hancock [mailto:peter.hanc...@gmail.com] *Sent:* Sunday, 7 February 2010 7:08 PM *To:* fop-dev@xmlgraphics.apache.org; martin.e...@intellimail.com.au *Subject:* Re: trying to debug using eclipse Hi Martin Is build/gensrc on your classpath? This gets generated during the default ant task. Pete On Sat, Feb 6, 2010 at 3:28 AM, martin.e...@asmorphic.net.au wrote: Hi Guys, Wondering if there are any tips of what i'm doing wrong - have built the application using ant, and it says it was built successfully. Can see the event-models.xml in the accessibility section, however, when running the application from eclipse, I get: NFO: Default page-width set to: 210mm Exception in thread main java.lang.ExceptionInInitializerError at org.apache.fop.apps.FOUserAgent.init(FOUserAgent.java:102) at org.apache.fop.apps.FopFactory.newFOUserAgent(FopFactory.java:188) at org.apache.fop.cli.CommandLineOptions.parse(CommandLineOptions.java:171) at org.apache.fop.cli.Main.startFOP(Main.java:158) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.util.MissingResourceException: File event-model.xml not found at org.apache.fop.events.model.AbstractEventModelFactory.loadModel(AbstractEven tModelFactory.java:46) at org.apache.fop.accessibility.AccessibilityEventProducer$EventModelFactory.cr eateEventModel(AccessibilityEventProducer.java:54) at org.apache.fop.events.DefaultEventBroadcaster.clinit(DefaultEventBroadcast er.java:73) ... 5 more Any suggestions on where I should start looking? THanks Martin
Re: DO NOT REPLY [Bug 48575] New: When generating EPS from SVG image content doesn't fit borders
Hi Paul,
I am a little unclear what the problem is here. I rendered your svg and
produced the attached eps an pdf to compare. They both look the same to
me. Can you elaborate on the problem with reference to my attached images,
please?
Thanks,
Peter
On Tue, Jan 19, 2010 at 8:39 PM, bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=48575
Summary: When generating EPS from SVG image content doesn't fit
borders
Product: Fop
Version: 0.95
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ps
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: paul.ly...@gmail.com
org.apache.fop.render.ps.EPSTranscoder produces EPS file from SVG DOM, and
image content doesn't fit image borders (so that picture is croped), though
viewBox parameter in svg file covers all content.
If specify area of interest (by EPSTranscoder.KEY_AOI hint) aproximately
1.38
times larger then actual viewBox then content fit borders well.
Versions 0.93 and 0.94 generate EPS file well, image content fits borders
as it
should.
Batik 1.7 was used to create SVG DOM.
Code being used for conversion:
public static byte[] serialize2EPS(Document document){
ByteArrayOutputStream baos = new ByteArrayOutputStream();
EPSTranscoder tr = new EPSTranscoder();
try {
tr.transcode(new TranscoderInput(document),new
TranscoderOutput(baos));
} catch (TranscoderException e) {
e.printStackTrace();
}
return baos.toByteArray();
}
SVG file being processed:
?xml version=1.0?
svg transform=scale(1.0)
width=100.0mm xmlns:xlink=http://www.w3.org/1999/xlink;
height=100.0mm
viewBox=0.0 0.0 100.0 100.0 xmlns=http://www.w3.org/2000/svg;
rect fill=#ff x=0 width=100.0 height=100.0 y=0
style=stroke:#ff/
path stroke-linecap=square fill-opacity=1.0 fill=none
fill-rule=nonzero stroke-linejoin=miter style=stroke:#000
d=M48.913043478260875,13.539282990083906
C64.97395582555245,13.539282990083906
77.99389778794813,20.881676490189015 77.99389778794813,29.938977879481314
C77.99389778794813,38.99627926877361 64.97395582555245,46.33867276887872
48.913043478260875,46.33867276887872 C32.852131130969305,46.33867276887872
19.83218916857361,38.99627926877361 19.83218916857361,29.938977879481314
C19.83218916857361,20.881676490189015 32.852131130969305,13.539282990083906
48.913043478260875,13.539282990083906Z
stroke-width=0.1 stroke-opacity=1.0 stroke-miterlimit=1.0/
path stroke-linecap=square fill-opacity=1.0 fill=none
fill-rule=nonzero stroke-linejoin=miter style=stroke:#000
d=M1.0526315789473684,1.4736842105263157
C1.0526315789473684,1.4736842105263157 98.73684210526316,1.4736842105263157
98.73684210526316,1.4736842105263157 C98.73684210526316,1.4736842105263157
98.73684210526316,98.52631578947368 98.73684210526316,98.52631578947368
C98.73684210526316,98.52631578947368 1.0526315789473684,98.52631578947368
1.0526315789473684,98.52631578947368 C1.0526315789473684,98.52631578947368
1.0526315789473684,1.4736842105263157
1.0526315789473684,1.4736842105263157Z
stroke-width=0.1 stroke-opacity=1.0 stroke-miterlimit=1.0/path
stroke-linecap=square fill-opacity=1.0 fill=none fill-rule=nonzero
stroke-linejoin=miter style=stroke:#000
d=M5.684210526315789,5.473684210526316
C5.684210526315789,5.473684210526316
86.52631578947368,90.52631578947368 86.52631578947368,90.52631578947368
stroke-width=0.1 stroke-opacity=1.0 stroke-miterlimit=1.0/path
stroke-linecap=square fill-opacity=1.0 fill=none fill-rule=nonzero
stroke-linejoin=miter style=stroke:#000
d=M6.105263157894737,89.6842105263158 C6.105263157894737,89.6842105263158
93.89473684210526,6.736842105263165 93.89473684210526,6.736842105263165
stroke-width=0.1 stroke-opacity=1.0 stroke-miterlimit=1.0//svg
--
Configure bugmail:
https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
out.eps
Description: PostScript document
out.pdf
Description: Adobe PDF document
Re: Thoughts on Bug 48237
Hi Jeremias, Would such a ColorConverter interface be useful as part of xmlgraphics commons? I think there may be other color related classes that could be re-housed like ColorExt. Pete On Thu, Nov 26, 2009 at 8:20 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Hi Peter On 26.11.2009 21:06:42 Peter Hancock wrote: Hi Jeremias, I think I see what you have in mind - the interface could simply expose methods like *Color convertXtoY(Color)*. Or did you have in mind the methods returning output type-specific color representaions? Pretty much just one very simple Color convert(Color) method. Not sure, yet, if it's too simple. ;-) But at least this wouldn't make any assumption what kind of color conversion happens. The setup is done elsewhere. Having a simple interface has the advantage that a converter can be used in different places. Should AbstractPaintingState be responsible holding the ColorConverter and exposing it as a property e.g for the utility of AFPGraphics2D before calling setColor() on the GraphicsObject instance? I haven't really thought that far, but that sounds about right. The original color should be preserved as long as possible IMO, and only be changed where it makes sense. And that would most probably be at the point where it is set on the AFP graphics object. Cheers, Pete On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Hi Peter See my question I attached to bug 48237. But of course, the ideal case is to have the color converted properly if possible. On 24.11.2009 15:30:30 Peter Hancock wrote: At present FOP does not respect an image color setting of 'b+w' when rendering svg to afp (see Bug 48237) According to the AFP spec ( http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320DT=20001002123303 ) it does not seem possible to specify a grayscale color space, and so my question is how should colour be controlled? I think there are two general approached besides just using RGB: - CMYK with only the K component (that is a clear indication that we want a fully black color or shades of that) - using a Highlight color space (assuming black as a highlight/spot color) But I have no experience with highlight colors on AFP, so I can't tell if it would work. Since AFPGraphics2D is responsible for setting the color on the MODCA GraphicsObject prior to calling drawing methods, would a sensible fix to the problem be to convert the awt.Color before calling this setter? Probably. I have some tentative need to have a general color conversion facility for FOP (not just AFP). For example, at some point we may want to have color conversion from sRGB to CMYK. Another use case for a color converter would be a detector which would convert any grayscale color (R, G, B or C, M, Y with equal values) to a CMYK value (with only K) which might in certain situations improve output quality because otherwise a RIP might be inclined to mix black by mixing CMY. I can imagine that a general interface could be defined for which there could be multiple implementations depending on the use case and configuration. For the present case, one implementation of that interface per color setting could be written for AFP. Not sure, just brainstorming. Any thoughts would be most welcome, Pete Jeremias Maerki Jeremias Maerki
Re: Thoughts on Bug 48237
Hi Jeremias, I think I see what you have in mind - the interface could simply expose methods like *Color convertXtoY(Color)*. Or did you have in mind the methods returning output type-specific color representaions? Should AbstractPaintingState be responsible holding the ColorConverter and exposing it as a property e.g for the utility of AFPGraphics2D before calling setColor() on the GraphicsObject instance? Cheers, Pete On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Hi Peter See my question I attached to bug 48237. But of course, the ideal case is to have the color converted properly if possible. On 24.11.2009 15:30:30 Peter Hancock wrote: At present FOP does not respect an image color setting of 'b+w' when rendering svg to afp (see Bug 48237) According to the AFP spec ( http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320DT=20001002123303 ) it does not seem possible to specify a grayscale color space, and so my question is how should colour be controlled? I think there are two general approached besides just using RGB: - CMYK with only the K component (that is a clear indication that we want a fully black color or shades of that) - using a Highlight color space (assuming black as a highlight/spot color) But I have no experience with highlight colors on AFP, so I can't tell if it would work. Since AFPGraphics2D is responsible for setting the color on the MODCA GraphicsObject prior to calling drawing methods, would a sensible fix to the problem be to convert the awt.Color before calling this setter? Probably. I have some tentative need to have a general color conversion facility for FOP (not just AFP). For example, at some point we may want to have color conversion from sRGB to CMYK. Another use case for a color converter would be a detector which would convert any grayscale color (R, G, B or C, M, Y with equal values) to a CMYK value (with only K) which might in certain situations improve output quality because otherwise a RIP might be inclined to mix black by mixing CMY. I can imagine that a general interface could be defined for which there could be multiple implementations depending on the use case and configuration. For the present case, one implementation of that interface per color setting could be written for AFP. Not sure, just brainstorming. Any thoughts would be most welcome, Pete Jeremias Maerki
