[jira] [Closed] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers

[Peter Hancock (JIRA)]

 [ 
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

[Peter Hancock (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers

[Peter Hancock (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers

[Peter Hancock (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[jira] [Updated] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers

[Peter Hancock (JIRA)]

 [ 
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

Re: [jira] [Commented] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers

[Peter Hancock]

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)  wrote:
>
> [ 
> https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Peter Hancock]

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

[Peter Hancock (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

Re: [Vote] Add dependency to fontbox for OTF CFF

[Peter Hancock]

+1 if usage is restricted to OTF CFF fonts at first.


On Thu, Jan 10, 2013 at 2:20 PM, Vincent Hennebert wrote:

> +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
> >
> >
>

[jira] [Resolved] (FOP-1069) No error message on illegal/unknown values on a property

[Peter Hancock (JIRA)]

 [ 
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

[jira] [Resolved] (FOP-2180) [PATCH] TTFReader: Output bounding box information for glyphs

[Peter Hancock (JIRA)]

 [ 
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

Re: svn commit: r1401607 [1/3] - in /xmlgraphics/fop/trunk: ./ examples/fo/advanced/ src/documentation/intermediate-format-ng/ src/java/org/apache/fop/afp/ src/java/org/apache/fop/area/ src/java/org/a

[Peter Hancock]

Well spotted Pascal and sorry for the late reply.

This was introduced in error during a merge - I am guessing my IDE
generated the import statement, choosing the version of the class in
FOP - I really should have spotted this!

 I have fixed this in the trunk and I have no other reason to believe
there are any other regressions.

Thanks,

Peter

On Thu, Oct 25, 2012 at 9:21 AM, Pascal Sancho  wrote:
> Hi,
>
> it appears that the change from r687369 is lost (replacing
> org.apache.fop.util.UnitConv with
> org.apache.xmlgraphics.util.UnitConv).
>
> This regression starts with the branch (r1003017), so I guess it was
> branched from a local modified WC.
> I think that this merge should be reverted, and the branch should be
> checked, regarding all changes introduced during the branch creation,
> I suspect other potential regressions.
>
> 2012/10/24 Pascal Sancho :
>> Hi,
>>
>> This merge seems introduce 3 deprecated warning.
>> I'm not sure, but it is possible that UnitConv has migrated to
>> xmlgraphics.commons
>>
>>
>>
>> compile-java:
>> [mkdir] Created dir: D:\bin\java\fop\trunk\build\classes
>> [javac] Compiling 1441 source files to 
>> D:\bin\java\fop\trunk\build\classes
>> [javac] 
>> D:\bin\java\fop\trunk\src\java\org\apache\fop\render\AbstractPathOrientedRenderer.java:52:
>> warning: [deprecation] org.apache.fop.util.UnitConv in
>> org.apache.fop.util has been deprecated
>> [javac] import org.apache.fop.util.UnitConv;
>> [javac]   ^
>> [javac] 
>> D:\bin\java\fop\trunk\src\java\org\apache\fop\render\AbstractPathOrientedRenderer.java:999:
>> warning: [deprecation] org.apache.fop.util.UnitConv in
>> org.apache.fop.util has been deprecated
>> [javac] concatenateTransformationMatrix(UnitConv.mptToPt(at));
>> [javac] ^
>> [javac] 
>> D:\bin\java\fop\trunk\src\java\org\apache\fop\render\AbstractPathOrientedRenderer.java:999:
>> warning: [deprecation] mptToPt(java.awt.geom.AffineTransform) in
>> org.apache.fop.util.UnitConv has been deprecated
>> [javac] concatenateTransformationMatrix(UnitConv.mptToPt(at));
>> [javac] ^
>> [javac] Note: Some input files use unchecked or unsafe operations.
>> [javac] Note: Recompile with -Xlint:unchecked for details.
>> [javac] 3 warnings
>>
>>
>> 2012/10/24  :
>>> Author: phancock
>>> Date: Wed Oct 24 10:20:17 2012
>>> New Revision: 1401607
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1401607&view=rev
>>> Log:
>>> Added support for Rounded Corners (see Bugzilla 54041).
>>>
>>> Contributions made by PH, JM and LB
>>> (...)
>
> --
> pascal

Re: [Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

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  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

[Peter Hancock]

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  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

[Peter Hancock]

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
 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

[Peter Hancock]

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

[Peter Hancock]

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
 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

Re: [Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

Thanks for taking the time to review this!

On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams  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

[Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

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: Comments on FopFactory.getRendererConfig (Temp_URI_Unification)

[Peter Hancock]

Hi Alexios,

Thanks for taking a look at this.

On Thu, Jul 5, 2012 at 1:41 PM, Alexios Giotis  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 (Map 
> 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

[Peter Hancock]

Hi Vincent, FOP Dev,

On Wed, Jul 4, 2012 at 12:32 PM, Vincent Hennebert  wrote:

> 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: [VOTE] Merge Temp_URI_Unification

[Peter Hancock]

+1

On Tue, Jun 26, 2012 at 3:39 PM, mehdi houshmand  wrote:
> Sorry, added "[VOTE]" to subject line... My bad
>
> On 26 June 2012 15:38, mehdi houshmand  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  and 
>> 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

[Peter Hancock]

+1

On Mon, Jun 18, 2012 at 12:02 PM, Chris Bowditch
 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

[Peter Hancock]

+1

On Tue, Apr 17, 2012 at 9:15 AM, Chris Bowditch
 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

[Peter Hancock]

Hi Jeremias,

Thanks for your feedback!

On Wed, Mar 28, 2012 at 7:08 PM, Jeremias Maerki
 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  
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

[Peter Hancock]

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

[Peter Hancock]

+1

Thanks for launching the vote Vincent!

Peter


On Thu, Mar 22, 2012 at 7:54 AM, Pascal Sancho  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 > > 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 RESULTS] Glenn Adams for committer

[Peter Hancock]

Good news and welcome Glenn!

On Fri, Feb 24, 2012 at 4:05 PM, Glenn Adams  wrote:
> thank you chris and team, i appreciate the positive support; i intend to
> move forward on merging the complex script work asap
>
> regards, glenn
>
>
> On Fri, Feb 24, 2012 at 4:06 AM, Chris Bowditch 
> wrote:
>>
>> On 20/02/2012 09:16, Chris Bowditch wrote:
>>>
>>> Hi All,
>>>
>>> Glenn Adams is the author of the Complex Scripts branch for FOP. He has
>>> been developing it for over 1 year now, providing regular updates to the
>>> patch as well as support for it via the fop-users Mailing List. I therefore
>>> propose Glenn is made a committer as reward for his dedication to the FOP
>>> project. Glenn is an expert in eastern languages (amonst other things) and
>>> will bring a wealth of valuable knowledge to the FOP development team.
>>>
>>> +1 from me.
>>
>>
>> I meant to say when I opened the vote that I planned to conclude it today.
>> I think all active committers have voted anyway. The results are:
>>
>> 9 +1s, no other votes. Therefore the vote passes.
>>
>> Congratulations Glenn and welcome to the team. Glenn sent me his preferred
>> ID offlist and we already have an ICLA on file, so I will file a new account
>> request.
>>
>> Thanks,
>>
>> Chris
>>
>>
>>
>>>
>>> Votes on general@ only please.
>>>
>>> Thanks,
>>>
>>> Chris
>>>
>>>
>>
>

Re: [VOTE] merge Temp_ImproveAccessibility to trunk

[Peter Hancock]

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  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  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

[Peter Hancock]

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
 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 “#”.

[Peter Hancock]

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  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

[Peter Hancock]

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  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

[Peter Hancock]

On Wed, Oct 26, 2011 at 2:13 PM, Glenn Adams  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

[Peter Hancock]

> 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

[Peter Hancock]

>> 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  wrote:
> inline
> On Wed, Oct 26, 2011 at 7:17 PM, Vincent Hennebert 
> wrote:
>>
>> On 24/10/11 14:05, Glenn Adams wrote:
>> > On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl
>> > wrote:
>> >
>> >> 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 enfor

Re: Merge Request - Temp_ComplexScripts into Trunk

[Peter Hancock]

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  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 a

Re: [VOTE] to include the Mockito framework

[Peter Hancock]

6 +1 votes and Mockito has has been accepted.

Peter

On Mon, Oct 17, 2011 at 2:51 PM, Pascal Sancho  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  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

[Peter Hancock]

> 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

[Peter Hancock]

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

[Peter Hancock]

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  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 
> 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  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 
>> > 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=1177251&view=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

[Peter Hancock]

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  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 
> 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=1177251&view=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

[Peter Hancock]

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  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

[Peter Hancock]

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
wrote:

> 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  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.com
> www.thunderhead.com
>
>
>
> Thunderhead featured in The Sunday Times Profit Track 100 league table of
> companies with fastest-growing profits. Click 
> hereto read more.
>  [image: LinkedIn]  
> [image:
> twitter] [image: 
> RSS][image:
> YouTube] 
> 
>  [image:
> were-hiring] 
>
> 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

[Peter Hancock]

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  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:
>
>
> 
>   xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
>  xmlns:fo="http://www.w3.org/1999/XSL/Format";>
>
>
>  
>
>
>  
>
>    
>         page-height="11.5in">
>           margin-left="0.20in" margin-right="0.20in" />
>        
>      
>
>      
>
>        
>         
>           
>
>                
>                
>
>
>             
>                  
>                        
>                        
>                  
>             
>
>             
>
>
>                         select="report-bO/candidate-ro-details"/>
>
>             
>
>           
>          
>         
>        
>       
>      
>
>
>             
>
>                
>
>                         number-rows-spanned="2"
> number-columns-spanned="1">
>                                
>                                 margin-left="40pt" font-size="8pt"
> white-space-collapse="false" white-space-treatment="preserve"> select="attendancenumber"/>
>                                 margin-left="40pt" font-size="8pt"
> white-space-collapse="false" white-space-treatment="preserve"> select="roname"/>
>                                 margin-left="40pt" font-size="8pt"
>>
>                                 margin-left="40pt" font-size="8pt"
>>
>                                 margin-left="40pt" font-size="8pt"
>>
>                                 margin-left="40pt" font-size="8pt"
>>
>                                 margin-left="40pt" font-size="8pt"
>>
>                                        
>                                                 test="(string-length(addressline4)>0)">
>                                                        ,  select="addressline4"/>
>                                                
>                                                
>                                                        
>                                                
>                                        
>
>                                
>                                 font-size="8pt">
>                                
>                                                 test="(string-length(addressline6)>0)">
>                                                        ,  select="addressline6"/>
>                                                
>                                                
>                                                        
>                                                
>                                        
>
>                                
>
>                                
>                
>
>
>                
>             
>    
>
> --
> 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]

[Peter Hancock]

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
 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  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

[Peter Hancock]

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  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

[Peter Hancock]

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

[Peter Hancock]

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  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  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  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

[Peter Hancock]

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
 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  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

[Peter Hancock]

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  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

[Peter Hancock]

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
 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=1036179&view=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: Printing FOP generated PDF using PCL6 drivers

[Peter Hancock]

Hi Jeremias,

> Sorry for the late feedback. I don't see anything wrong with the paint
> sequences you show here. These are basic painting operations. And I
> assume they work perfectly when viewed in Acrobat Reader or GhostScript.

Yes, and printed fine with a PS print driver.

> Out of experience, I can say that the PCL printer drivers of Microsoft
> origin have had problems for years (not just with FOP/Acrobat but also
> with MS Word and other tools). And each time the equivalent PostScript
> driver was used, the problem went away (see fop-users archive, too).

Thanks for pointing this out to me!

> To a certain degree, you can play with the driver settings. In many cases,
> I saw that the PCL driver rasterizes full pages rather than using text
> operator. Not sure if that's part of the problem.

The documents producedmay be distribution electronically to the end
customer and we will not have control over their printing setup.

> In the end, I'm unclear how one should be able to find out why one
> snippet below works and the other doesn't. The only real difference is
> the 90° rotation in the second example. But I can't imagine that such a
> basic operation should cause the problem. If it does, that driver is

I have been able to print examples of rounded borders that contain
these rotation commands.

> simply buggy and it doesn't make sense to go through hoops to try to work
> around the bug. And I can't imagine that two decimal digits more or less
> will cause any such problem.

I agree.


> Have you tried printing the PDF from GhostScript/GhostView to the PCL
> printer? Or from another PDF viewer? Does the same problem occur? Have

I have printed successfully to the printer using GhostScript, not
however, with a PCL print driver
.
> you tried enabling "Print as Bitmap" in Acrobat (found in the printing
> dialog under "Advanced")?

That worked fine for me too.

I am continually leaning to the conclusion that the PCL print driver
is at fault but I do have doubts since SVG's describing complex curves
seem to be transformed to PDF commands that survive the PCL driver.
And since I have had some success printing rounded corners I would
really like to know what difference is causing the problem.

Oh well, perhaps this is one of those problems that will be solved
when we find simpler examples of passes and fails.

Thanks for taking the time to consider the problem.

Pete

Re: Problem with FOP when generating a PNG

[Peter Hancock]

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
 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
>>  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
>> >>  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

[Peter Hancock]

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

[Peter Hancock]

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
 wrote:
> Le jeudi 04 novembre 2010 à 10:02 +0000, 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
>>  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

[Peter Hancock]

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
 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

[Peter Hancock]

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,   wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
>
> Jeremias Maerki  changed:
>
>           What    |Removed                     |Added
> 
>             Status|NEW                         |RESOLVED
>         Resolution|                            |FIXED
>
> --- Comment #3 from Jeremias Maerki  2010-10-07 03:48:24 
> EDT ---
> Patch applied with modifications as discussed:
> http://svn.apache.org/viewvc?rev=1005350&view=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

[Peter Hancock]

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  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
>> 
>> 
>> 
>> >     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
>>  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

Rounded Corners

[Peter Hancock]

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





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
 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

[Peter Hancock]

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,   wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
>
> --- Comment #2 from Jeremias Maerki  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

[Peter Hancock]

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
 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

[Peter Hancock]

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

[Peter Hancock]

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
wrote:

> 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

[Peter Hancock]

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
>

Re: new patch, bug 48975

[Peter Hancock]

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
>

Interactive PDF

[Peter Hancock]

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

[Peter Hancock]

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 wrote:

> 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 = ""+
>  ""+
>  ""+
> "Mastering EJB"+
>  "Ed Roman"+
> "$45.00"+
>  ""+
> ""+
> "Design Patterns"+
>  "Erich Gamma"+
> "$50.00"+
>  ""+
> ""+
> "Effective Java"+
>  "Josch Bloch"+
> "$30.00"+
>  "" +
> "";
>
> xsl = "xsl2.xslt";
>
> In the xsl2.xslt I have a part of code like this to insert the image on the
> pdf:
> ...
> 
>   
> 
> ...
>
>
> 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

[Peter Hancock]

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

[Peter Hancock]

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
wrote:

>  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,  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.(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.(DefaultEventBroadcast
> er.java:73)
>... 5 more
>
>
> Any suggestions on where I should start looking?
>
> THanks
> Martin
>
>
>
>

Re: trying to debug using eclipse

[Peter Hancock]

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,  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.(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.(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

[Peter Hancock]

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,  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:
>
> 
>  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";>
>  style="stroke:#ff"/>
>  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"/>
>  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"/> 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"/> 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"/>
>
> --
> 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: Font metrics problems implementing AFP Unicode support

[Peter Hancock]

Hi Jeremias,

I have come to the same conclusion, but because the print out looked good I
originally assumed that if the font outline was being extracted, then the
font metrics were there too.  I am now wondering if the printer  derived the
font from elsewhere!

Thanks for your help!

Pete

I have observed that the fallback widths are indeed being used, messing up
my layout.
On Mon, Jan 11, 2010 at 9:21 PM, Jeremias Maerki wrote:

> Hi Peter
>
> Hmm, maybe it is my lack of knowledge about the Japanese language (and
> as a result I'm talking utter BS), but if you look at your FO file, the
> first character in the text is 0x306F (HIRAGANA LETTER HA). But there is
> no width information in CZJHMNU for the character U000306F. What I do
> find in this font are Katakana and Hangul characters (x0xFF**) as well
> as latin characters (0x00**). Could it be that you picked text with
> characters from a different character set than the one the font offers?
> In that case it wouldn't be surprising if the line breaking is off
> because FOP would just fallback to the width of the space (?) character.
> Have you tried viewing the generated files in more than one AFP viewer?
> I don't trust any single AFP viewer to provide a reliable result.
>
> HTH
>
> On 11.01.2010 11:45:13 Peter Hancock wrote:
> > Hi All,
> >
> > I am having problems determining the font-metrics of double-byte afp
> fonts
> > and wonder if you can help.
> >
> > I am currently trying to implement support for double-byte fonts in the
> AFP
> > renderer.  I am following the  outline in
> > http://wiki.apache.org/xmlgraphics-fop/AFPFonts as a guide.
> >
> > I am using the* J-Heisei Mincho* Unicode font resources, as suggested in
> the
> > wiki.  I have managed to reference this font in my fop.xconf and, with
> minor
> > code changes, I have managed to produce the  .afp from the attached
> xsl-fo
> > (see attached screen shot of the .afp rendered in an AFP viewer - note
> the
> > font not supported).  When I print this out the correct font is used
> which I
> > assume is extgracted from the embedded outline definitions.
> >
> > The problem I am now addressing affects the layout of the text.
>  Comparing
> > the attached pdf to the screen image of the afp (ignore the glyphs used
> by
> > the afp viewer), you will note that the line-breaking is not respecting
> the
> > font metrics (I am aware that the single fo:block  specified in the
> xsl-fo
> > will not layout the text nicely but it should be bounded by the page
> > boundary).  The correct character width is required by the layout engine
> to
> > determine page breaks.  Fop tries to extract this data from the font
> > resource "CZJHMNU" by reading from the bytes within the 'Font Index'
> > structured field (see org.apache.fop.afp.fonts.
> > AFPFontReader.java).  This data represents a mapping from font metric
> data
> > to the 'Graphic Character UCS Identifier' -e.g  'U000FFAA' for the
> > code-point FFAA is mapped to font width etc.However the GCUIDs of the
> > characters in my text  cannot be found in this structured field (although
> > the relevant GCUIDs do appear in the TT11200 codepage).
> >
> > At the moment I am assuming I the font resource is either not meant
> > double-byte fonts, or the font metrics are somehow reused for the
> characters
> > that are not mapped?
> >
> > I am aware that this post is a little vague and due to the size and
> > licensing issues I am unable to attach the CZJHMNU font resource - but if
> > you can point me in the right direction that would be great.
>
>
>
>
> Jeremias Maerki
>
>

Re: Thoughts on Bug 48237

[Peter Hancock]

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 wrote:

> 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  >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=APSBK320&DT=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

[Peter Hancock]

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 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=APSBK320&DT=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
>
>

Re: Thoughts on Bug 48237

[Peter Hancock]

Hi Venkat,

The bug is with svg images (embedded and extrernal) - you are correct that
it works with bitmaps as demonstrated in the files attached to the bug
report.  Were you able to test those?

Cheers,
Pete

On Tue, Nov 24, 2009 at 4:59 PM, Venkat Reddy <
vanukuri.ven...@googlemail.com> wrote:

> Hi Peter,
>
> There is no bug with this functionality. You can have a look at the FO file
> that I have used...
>
> 1. Update the configuration file for the image mode (b+w  or  color)
> 2. Run the following command from the command prompt...
>   *C:\mywork\FOP\fop-0.95> fop -c C:\fop.xconf -fo
> C:\mywork\JavaXSLTSamples\XSLFOSamples\hello.fo -afp
> C:\mywork\JavaXSLTSamples\XSLFOSamples\hellotest.afp
> *
> According to the mode, the image will be rendered with color or black and
> white...
>
> Thanks,
> Venkat.
>
>
> 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=APSBK320&DT=20001002123303<
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303>)
>> it does not seem possible to specify a grayscale color space, and so my
>>  question is how should colour be controlled?
>>
>>
>> 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?
>>
>> Any thoughts would be most welcome,
>>
>> Pete
>>
>
>

Thoughts on Bug 48237

[Peter Hancock]

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=APSBK320&DT=20001002123303)
it does not seem possible to specify a grayscale color space, and so my
question is how should colour be controlled?

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?

Any thoughts would be most welcome,

Pete