You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2010/06/03 17:46:08 UTC
DO NOT REPLY [Bug 49379] New: [PATCH] Enhancement to the include
page segment functionality for AFP rendering
https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
Summary: [PATCH] Enhancement to the include page segment
functionality for AFP rendering
Product: Fop
Version: 1.0dev
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: peter.hancock@gmail.com
This patch facilitates the extraction and embedding of a page segment from a
resource file into the generated AFP. The include-page-segment extension
element permits the optional attribute 'resource-file' that is the URI to the
resource containing the named page segment.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page
segment functionality for AFP rendering
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
--- Comment #1 from Peter Hancock <pe...@gmail.com> 2010-06-03 11:47:50 EDT ---
Created an attachment (id=25519)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25519)
Patch
--
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: DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page
segment functionality for AFP rendering
Posted by Vincent Hennebert <vh...@gmail.com>.
If a MO:DCA parser is added, then that should definitely be in
a separate sub-project of XML Graphics.
For the rest, knowing next to nothing about AFP, I have no opinion.
Vincent
Peter Hancock wrote:
> 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, <bu...@apache.org> wrote:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
>>
>> --- Comment #2 from Jeremias Maerki <je...@apache.org> 2010-08-20 03:46:59 EDT ---
>> Peter, I've taken a look at your patch. I found that I get an IOException when
>> referencing the page segment "s1islogo.psg" that comes with IBM AFP Workbench:
>>
>> java.io.IOException: Malformed AFP resource with name 's1islogo': No Begin
>> structured field
>> at
>> org.apache.fop.afp.util.AFPResourceUtil.copyNamedResource(AFPResourceUtil.java:123)
>>
>> I have the impression that the method AFPResourceUtil.findStart() may not be
>> ideal to parse an MO:DCA file. I haven't investigated more closely why the
>> above file fails, but stepping through findStart() feels a bit weird in terms
>> of how that method looks for the requested resource. Some time ago I started a
>> rudimentary AFP parser I used to dump the Type 1 data from an outline font, or
>> to simply dump the basic structure of an AFP file. I could include that in FOP
>> and we build from there. It allows to return an object for each structured
>> field encountered. A generic MO:DCA parser would also allow future
>> functionality that involves parsing an AFP file. WDYT?
>>
>> --
>> Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> ------- You are receiving this mail because: -------
>> You are the assignee for the bug.
>>
Re: DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page
segment functionality for AFP rendering
Posted by Peter Hancock <pe...@gmail.com>.
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, <bu...@apache.org> wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
>
> --- Comment #2 from Jeremias Maerki <je...@apache.org> 2010-08-20 03:46:59 EDT ---
> Peter, I've taken a look at your patch. I found that I get an IOException when
> referencing the page segment "s1islogo.psg" that comes with IBM AFP Workbench:
>
> java.io.IOException: Malformed AFP resource with name 's1islogo': No Begin
> structured field
> at
> org.apache.fop.afp.util.AFPResourceUtil.copyNamedResource(AFPResourceUtil.java:123)
>
> I have the impression that the method AFPResourceUtil.findStart() may not be
> ideal to parse an MO:DCA file. I haven't investigated more closely why the
> above file fails, but stepping through findStart() feels a bit weird in terms
> of how that method looks for the requested resource. Some time ago I started a
> rudimentary AFP parser I used to dump the Type 1 data from an outline font, or
> to simply dump the basic structure of an AFP file. I could include that in FOP
> and we build from there. It allows to return an object for each structured
> field encountered. A generic MO:DCA parser would also allow future
> functionality that involves parsing an AFP file. WDYT?
>
> --
> Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
>
DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page
segment functionality for AFP rendering
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
--- Comment #2 from Jeremias Maerki <je...@apache.org> 2010-08-20 03:46:59 EDT ---
Peter, I've taken a look at your patch. I found that I get an IOException when
referencing the page segment "s1islogo.psg" that comes with IBM AFP Workbench:
java.io.IOException: Malformed AFP resource with name 's1islogo': No Begin
structured field
at
org.apache.fop.afp.util.AFPResourceUtil.copyNamedResource(AFPResourceUtil.java:123)
I have the impression that the method AFPResourceUtil.findStart() may not be
ideal to parse an MO:DCA file. I haven't investigated more closely why the
above file fails, but stepping through findStart() feels a bit weird in terms
of how that method looks for the requested resource. Some time ago I started a
rudimentary AFP parser I used to dump the Type 1 data from an outline font, or
to simply dump the basic structure of an AFP file. I could include that in FOP
and we build from there. It allows to return an object for each structured
field encountered. A generic MO:DCA parser would also allow future
functionality that involves parsing an AFP file. WDYT?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page
segment functionality for AFP rendering
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
Peter Hancock <pe...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--
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: DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page
segment functionality for AFP rendering
Posted by Peter Hancock <pe...@gmail.com>.
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, <bu...@apache.org> wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
>
> Jeremias Maerki <je...@apache.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |RESOLVED
> Resolution| |FIXED
>
> --- Comment #3 from Jeremias Maerki <je...@apache.org> 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.
>
DO NOT REPLY [Bug 49379] [PATCH] Enhancement to the include page
segment functionality for AFP rendering
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49379
Jeremias Maerki <je...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Jeremias Maerki <je...@apache.org> 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.