[jira] [Updated] (FOP-2280) [PATCH] Retrieved marker content ignores writing-mode
[ https://issues.apache.org/jira/browse/FOP-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2280: - Attachment: (was: hebrew_marker.fo) > [PATCH] Retrieved marker content ignores writing-mode > - > > Key: FOP-2280 > URL: https://issues.apache.org/jira/browse/FOP-2280 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Reporter: Matthias Reischenbacher > Attachments: 2280_hebrew_marker.patch, hebrew_marker.pdf, > hebrew_marker.xml > > > Retrieve-marker inside static content ignores current writing-mode. See > sample fo file and current PDF output. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2280) [PATCH] Retrieved marker content ignores writing-mode
[ https://issues.apache.org/jira/browse/FOP-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2280: - Attachment: hebrew_marker.xml Updated test file that also includes markers with block-container. > [PATCH] Retrieved marker content ignores writing-mode > - > > Key: FOP-2280 > URL: https://issues.apache.org/jira/browse/FOP-2280 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Reporter: Matthias Reischenbacher > Attachments: 2280_hebrew_marker.patch, hebrew_marker.pdf, > hebrew_marker.xml > > > Retrieve-marker inside static content ignores current writing-mode. See > sample fo file and current PDF output. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2280) [PATCH] Retrieved marker content ignores writing-mode
[ https://issues.apache.org/jira/browse/FOP-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2280: - Attachment: (was: 2280_hebrew_marker.patch) > [PATCH] Retrieved marker content ignores writing-mode > - > > Key: FOP-2280 > URL: https://issues.apache.org/jira/browse/FOP-2280 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Reporter: Matthias Reischenbacher > Attachments: 2280_hebrew_marker.patch, hebrew_marker.pdf, > hebrew_marker.xml > > > Retrieve-marker inside static content ignores current writing-mode. See > sample fo file and current PDF output. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2280) [PATCH] Retrieved marker content ignores writing-mode
[ https://issues.apache.org/jira/browse/FOP-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2280: - Attachment: 2280_hebrew_marker.patch Updated patch. BidiResolver.resolveInlineDirectionality caused a NPE when processing a block-container which is child of a marker. I removed the resolving completely (is it really necessary?) and just copy the bidilevel inside AbstractRetrieveMarker. > [PATCH] Retrieved marker content ignores writing-mode > - > > Key: FOP-2280 > URL: https://issues.apache.org/jira/browse/FOP-2280 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Reporter: Matthias Reischenbacher > Attachments: 2280_hebrew_marker.patch, hebrew_marker.pdf, > hebrew_marker.xml > > > Retrieve-marker inside static content ignores current writing-mode. See > sample fo file and current PDF output. -- This message was sent by Atlassian JIRA (v6.2#6252)
New FOP Release [was: Re: FOP Release Automation]
Hi, On 15/07/14 16:53, Clay Leeds wrote: On Jul 15, 2014, at 7:46 AM, Glenn Adams wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. Clay, your offer to help would be greatly appreciated! And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version). In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0. Thanks, Vincent
RE: New FOP Release [was: Re: FOP Release Automation]
Hi, I switched fop back to fontbox 1.8, so its only the pdfplugin that uses 2.0 and the user would delete 1.8 jar if copying pdfplugin to fop. Thanks -Original Message- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: 16 July 2014 12:56 To: fop-dev@xmlgraphics.apache.org Subject: New FOP Release [was: Re: FOP Release Automation] Hi, On 15/07/14 16:53, Clay Leeds wrote: > On Jul 15, 2014, at 7:46 AM, Glenn Adams wrote: >> I suppose it depends on whether or not we need to hack perl to use the >> facility. If there is any alternative that doesn't use perl, then that would >> be preferable. >> >> Frankly, I've never been happy with the new MD based documentation, though >> Clay has spent an inordinate amount of time tweaking it. > > Yeah... It's not my favorite either, but at least edits are pretty quick, > saved to SVN and we've got a solution to incorporate javadoc, etc. > > In the meantime, please let me know when we're ready to update the > documentation for the Release. It doesn't take me very long to go > through the code to make these types of batch edits. Clay, your offer to help would be greatly appreciated! And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version). In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0. Thanks, Vincent
Re: New FOP Release [was: Re: FOP Release Automation]
On 16/07/14 17:42, Simon Steiner wrote: Hi, I switched fop back to fontbox 1.8, so its only the pdfplugin that uses 2.0 and the user would delete 1.8 jar if copying pdfplugin to fop. Thanks Simon. That’s great because that means that we can start the release process of FOP as soon as we are ready. Vincent Thanks -Original Message- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: 16 July 2014 12:56 To: fop-dev@xmlgraphics.apache.org Subject: New FOP Release [was: Re: FOP Release Automation] Hi, On 15/07/14 16:53, Clay Leeds wrote: On Jul 15, 2014, at 7:46 AM, Glenn Adams wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. Clay, your offer to help would be greatly appreciated! And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version). In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0. Thanks, Vincent
Re: New FOP Release [was: Re: FOP Release Automation]
On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert wrote: > On 16/07/14 17:42, Simon Steiner wrote: > >> Hi, >> >> I switched fop back to fontbox 1.8, so its only the pdfplugin that uses >> 2.0 and the user would delete 1.8 jar if copying pdfplugin to fop. >> > > Thanks Simon. That’s great because that means that we can start the > release process of FOP as soon as we are ready. > It would be nice to share the following info: - who is going to take the lead on performing the release? - what is a tentative schedule for release, e.g., when should last changes be integrated? - what additional integrations (if known) are planned before release? > > Vincent > > > Thanks >> >> -Original Message- >> From: Vincent Hennebert [mailto:vhenneb...@gmail.com] >> Sent: 16 July 2014 12:56 >> To: fop-dev@xmlgraphics.apache.org >> Subject: New FOP Release [was: Re: FOP Release Automation] >> >> Hi, >> >> On 15/07/14 16:53, Clay Leeds wrote: >> >>> On Jul 15, 2014, at 7:46 AM, Glenn Adams wrote: >>> I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. >>> >>> Yeah... It's not my favorite either, but at least edits are pretty >>> quick, saved to SVN and we've got a solution to incorporate javadoc, etc. >>> >>> In the meantime, please let me know when we're ready to update the >>> documentation for the Release. It doesn't take me very long to go >>> through the code to make these types of batch edits. >>> >> >> >> Clay, your offer to help would be greatly appreciated! >> >> And since you’re mentioning it, maybe it’s time to think about making a >> new release of FOP. Although now that the font merging code has been merged >> to trunk, and introduces a dependency on FontBox 2.0.0, we would have to >> wait that FontBox 2.0.0 is released first. Or adapt the code to keep the >> former 1.8.5 dependency (or the newer 1.8.6 released version). >> >> In the meantime, can anybody think of features that should definitely be >> implemented before the release, or bugs fixed? Remember that due to API >> changes, that release will have to be called 2.0. >> >> Thanks, >> Vincent >> >>
