DO NOT REPLY [Bug 47311] New: [PATCH] Support for bleed, trim and crop box and scaling

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #20 from Peter Coppens <pc.subscriptions@...>  2009-07-28 00:02:42 PST ---
Created an attachment (id=24048)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24048)
Box implementation for Java2d now uses "pdf box settings"

The attached patch fixes the previous comment

"There is an inconsistency between PDF and Java2D regarding the coordinates of
the boxes: in PDF the x and y coordinates are relative to the left and bottom
sides, in Java2D they are relative to the left and /top/ sides. One of the two
possibilities will have to be chosen, probably the PDF way."

The boxes for the Java2D renderer now also follows the "PDF way"

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #21 from Jeremias Maerki <jeremias@...>  2009-07-28 01:39:04 PST ---
Hi Peter,
incidentally, I need this functionality myself in a project I'm currently
working on. I've locally applied your patch to play with it. I apologize for
the late feedback.

I notice you chose the page size of the simple-page-master as the baseline for
the MediaBox. I would have expected the SPM's size to define the TrimBox
instead. Bleed and cut marks would then lie outside the actual logical page.
I've checked what other FO implementations do and they seem to follow that
pattern rather than your approach.

I'm also finding the specification of the areas a bit counter-intuitive. A
simple value only sets the left side, rather than the value for all four sides
as with other FO properties. I guess that also points to Andreas' comment about
reusing property infrastructure where this is already handled. Granted, it is
not easy to use. I'm not even sure myself if this can easily be reused with
some serious refactoring. At any rate, a print shop will usually just give you
the information that you should use 2 or 3 mm for the bleed area. Just
specifying one simple value is quite handy.

Rather than just criticizing, I'm willing to invest some time to help with
this. I would like to make a counter-proposal for the extensions:

The simple-page-master's width and height properties shall define the TrimBox.
If there is no bleed and crop mark area, the MediaBox will be equal to the
TrimBox, or rather just the MediaBox is generated in this case, like it happens
today.

fox:bleed: <length>{1,4}
Default: 0pt
If there is only one value, it applies to all sides. If there are two values,
the top and bottom bleed widths are set to the first value and the right and
left bleed widths are set to the second. If there are three values, the top is
set to the first value, the left and right are set to the second, and the
bottom is set to the third. If there are four values, they apply to the top,
right, bottom, and left, respectively. (Corresponds to
http://www.w3.org/TR/xsl11/#padding)
The BleedBox is calculated by expanding the TrimBox by the bleed widths.
(I'd prefer to call the property fox:bleed rather than fox:bleed-box as we
don't set the BleedBox values directly. We specify the bleed amount.)

fox:crop-offset: <length>{1,4}
Default: 0pt
Same behaviour as with fox:bleed.
The MediaBox is calculated by expanding the BleedBox by the crop offsets.

BTW, the naming above pretty much matches other FO implementations, so should
we ever have a standard for these properties (like by reviving exslfo.sf.net),
it's likely we probably don't have to change much besides the namespace prefix.

fox:crop-box: (trim-box|bleed-box|media-box)
Default: media-box
The crop box controls how Acrobat display the page or how the Java2DRenderer
sizes the output media. The PDF spec defines that the CropBox defaults to the
MediaBox, so it makes sense to do the same here. We could define a fox:crop-box
extension which could take three "magic" values: "trim-box", "bleed-box" and
"media-box" to set the CropBox to one of those three other boxes. That should
cover 95% of all use cases. If anyone needs more control, that could easily
added later.

I don't have much feedback on fox:scale. I guess it can be useful but I don't
see a big use case for an extension. I'd rather want to control that from
application code. But it shouldn't get in the way of anything so I have not
problem with it.

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.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #22 from Vincent Hennebert <vhennebert@...>  2009-07-28 04:28:01 PST ---
Hi Jeremias,

I can't afford to spend much time on this patch so I'm happy to hand over the
job to you. I'm attaching a new patch with my own modifications as I had
started to prepare it for commit. Not sure it's going to be any useful given
the different approach you'd like to take, but who knows.

A note about the patch: it seemed more sensible to me to deal with integer
values rather than double. Indeed every length value is internally converted
into a whole number expressed in mpt (AFAICT). That means that I'm using
Rectangle instead of Rectangle2D, and I changed some parameters into some
classes accordingly (mainly, o.a.f.layoutmgr.Page.java,
o.a.f.area.PageViewport.java). But then I noticed that the AreaTreeParser reads
the value of the "bounds" attribute as double instead of integer. AFAIK, the
XML area tree is produced with whole numbers for the page boundaries; I don't
see why a user would change that into decimal numbers (which would mean a
precision below the mpt!). So I also modified the AreaTreeParser. I don't think
this may create any problem?

Also, a few questions:

(In reply to comment #21)
<snip/>

>
> The simple-page-master's width and height properties shall define the TrimBox.
> If there is no bleed and crop mark area, the MediaBox will be equal to the
> TrimBox, or rather just the MediaBox is generated in this case, like it happens
> today.
>
> fox:bleed: <length>{1,4}
> Default: 0pt
> If there is only one value, it applies to all sides. If there are two values,
> the top and bottom bleed widths are set to the first value and the right and
> left bleed widths are set to the second. If there are three values, the top is
> set to the first value, the left and right are set to the second, and the
> bottom is set to the third. If there are four values, they apply to the top,
> right, bottom, and left, respectively. (Corresponds to
> http://www.w3.org/TR/xsl11/#padding)
> The BleedBox is calculated by expanding the TrimBox by the bleed widths.
> (I'd prefer to call the property fox:bleed rather than fox:bleed-box as we
> don't set the BleedBox values directly. We specify the bleed amount.)
>
> fox:crop-offset: <length>{1,4}
> Default: 0pt
> Same behaviour as with fox:bleed.
> The MediaBox is calculated by expanding the BleedBox by the crop offsets.

Just to be sure: values will be allowed to be negative, right?

It would make more sense to me to set the default value of crop-offset to the
value of bleed.

> BTW, the naming above pretty much matches other FO implementations, so should
> we ever have a standard for these properties (like by reviving exslfo.sf.net),
> it's likely we probably don't have to change much besides the namespace prefix.
>
> fox:crop-box: (trim-box|bleed-box|media-box)
> Default: media-box
> The crop box controls how Acrobat display the page or how the Java2DRenderer
> sizes the output media. The PDF spec defines that the CropBox defaults to the
> MediaBox, so it makes sense to do the same here. We could define a fox:crop-box
> extension which could take three "magic" values: "trim-box", "bleed-box" and
> "media-box" to set the CropBox to one of those three other boxes. That should
> cover 95% of all use cases. If anyone needs more control, that could easily
> added later.

I'm really not sure about that one. Calling it 'crop-box' is likely to create
confusion with the 'crop-offset' property above. Apparently the CropBox is not
used in prepress at all, so I would suggest to forget about that for the
moment. That is, make the CropBox match with the MediaBox.


> I don't have much feedback on fox:scale. I guess it can be useful but I don't
> see a big use case for an extension. I'd rather want to control that from
> application code. But it shouldn't get in the way of anything so I have not
> problem with it.
>
> WDYT?


Vincent

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311


Vincent Hennebert <vhennebert@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23751|0                           |1
        is obsolete|                            |
  Attachment #23941|0                           |1
        is obsolete|                            |
  Attachment #23978|0                           |1
        is obsolete|                            |
  Attachment #24018|0                           |1
        is obsolete|                            |
  Attachment #24048|0                           |1
        is obsolete|                            |




--- Comment #23 from Vincent Hennebert <vhennebert@...>  2009-07-28 04:31:34 PST ---
Created an attachment (id=24049)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24049)
Updated patch with some clean-up and modifications

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #24 from Peter Coppens <pc.subscriptions@...>  2009-07-28 04:42:22 PST ---
We were just about to start to rework the patch according to the suggestions
made by Jeremias which seem to make a lot of sense, but I am not so sure
anymore that is still useful given Vincent's alternative implementation/efforts
which we were unaware of.

It's a bit unclear right now how we can continue to contribute given the
different implementation efforts

We still have a bit of bandwith to spare on this (it is important for us) but
we'd rather make sure those efforts are part of a consolidated action

Can someone advice?

Thanks

Peter

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #25 from Jeremias Maerki <jeremias@...>  2009-07-28 04:54:14 PST ---
Peter, I'll respond to Vincent's comments shortly. I think his changes
shouldn't affect your changes too much. I think Vincent's comments make sense
and I'll see to it that they can be committed separately (they don't really
have much to do with the issue at hand). Then it will ideally just be a "svn
up" on your side to resolve this. And a minor SVN conflict in the worst case. I
suggest you just continue as intended.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #26 from Jeremias Maerki <jeremias@...>  2009-07-28 05:03:05 PST ---
Hi Vincent,

(In reply to comment #22)
> I can't afford to spend much time on this patch so I'm happy to hand over the
> job to you. I'm attaching a new patch with my own modifications as I had
> started to prepare it for commit. Not sure it's going to be any useful given
> the different approach you'd like to take, but who knows.

I'm glad to take over.

> A note about the patch: it seemed more sensible to me to deal with integer
> values rather than double. Indeed every length value is internally converted
> into a whole number expressed in mpt (AFAICT). That means that I'm using
> Rectangle instead of Rectangle2D, and I changed some parameters into some
> classes accordingly (mainly, o.a.f.layoutmgr.Page.java,
> o.a.f.area.PageViewport.java). But then I noticed that the AreaTreeParser reads
> the value of the "bounds" attribute as double instead of integer. AFAIK, the
> XML area tree is produced with whole numbers for the page boundaries; I don't
> see why a user would change that into decimal numbers (which would mean a
> precision below the mpt!). So I also modified the AreaTreeParser. I don't think
> this may create any problem?

I don't think so. I'll extract your changes from your patch and apply that
separately. That should make it easier for Peter, too.

> Also, a few questions:
<snip/>
> > fox:crop-offset: <length>{1,4}
> > Default: 0pt
> > Same behaviour as with fox:bleed.
> > The MediaBox is calculated by expanding the BleedBox by the crop offsets.
>
> Just to be sure: values will be allowed to be negative, right?

Negative values don't make much sense, if I didn't miss anything.

> It would make more sense to me to set the default value of crop-offset to the
> value of bleed.

Right.

> > BTW, the naming above pretty much matches other FO implementations, so should
> > we ever have a standard for these properties (like by reviving exslfo.sf.net),
> > it's likely we probably don't have to change much besides the namespace prefix.
> >
> > fox:crop-box: (trim-box|bleed-box|media-box)
> > Default: media-box
> > The crop box controls how Acrobat display the page or how the Java2DRenderer
> > sizes the output media. The PDF spec defines that the CropBox defaults to the
> > MediaBox, so it makes sense to do the same here. We could define a fox:crop-box
> > extension which could take three "magic" values: "trim-box", "bleed-box" and
> > "media-box" to set the CropBox to one of those three other boxes. That should
> > cover 95% of all use cases. If anyone needs more control, that could easily
> > added later.
>
> I'm really not sure about that one. Calling it 'crop-box' is likely to create
> confusion with the 'crop-offset' property above. Apparently the CropBox is not
> used in prepress at all, so I would suggest to forget about that for the
> moment. That is, make the CropBox match with the MediaBox.

Yes, I thought about that naming closeness, too. Not sure if that's so easy to
resolve. If Peter is OK with this, I guess the fox:crop-box could be left out
for the moment. I personally don't need it although at some point, such a
property might be useful to some.

<snip/>

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #27 from Jeremias Maerki <jeremias@...>  2009-07-28 05:57:22 PST ---
Partially applied Vincent's patch (from today). I've also applied the
undisputed parts of Peter's patch. So the next patch by Peter will only need to
be about the extensions and their integration into the renderers. I hope the
result will merge as painlessly as possible.
http://svn.apache.org/viewvc?rev=798511&view=rev

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #28 from Peter Coppens <pc.subscriptions@...>  2009-07-28 06:46:26 PST ---

> > >
> > > fox:crop-box: (trim-box|bleed-box|media-box)
> > > Default: media-box
> > > The crop box controls how Acrobat display the page or how the Java2DRenderer
> > > sizes the output media. The PDF spec defines that the CropBox defaults to the
> > > MediaBox, so it makes sense to do the same here. We could define a fox:crop-box
> > > extension which could take three "magic" values: "trim-box", "bleed-box" and
> > > "media-box" to set the CropBox to one of those three other boxes. That should
> > > cover 95% of all use cases. If anyone needs more control, that could easily
> > > added later.
> >
> > I'm really not sure about that one. Calling it 'crop-box' is likely to create
> > confusion with the 'crop-offset' property above. Apparently the CropBox is not
> > used in prepress at all, so I would suggest to forget about that for the
> > moment. That is, make the CropBox match with the MediaBox.
>
> Yes, I thought about that naming closeness, too. Not sure if that's so easy to
> resolve. If Peter is OK with this, I guess the fox:crop-box could be left out
> for the moment. I personally don't need it although at some point, such a
> property might be useful to some.
>
> <snip/>

Hmmm...not entirely happy with this unfortunately. We have a webapp that using
a flex wysiwyg editor allows creation of print materials but that uses adobe's
pdf browser plugin for end-user proofing and approval. In some cases we'd
rather display the trimbox iso the mediabox so my guess is we should be able to
control the CropBox setting, no?

Perhaps a name change for the attribute is sufficient? E.g. something like
crop-box-selector, or crop-box-source or something similar?

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #29 from Vincent Hennebert <vhennebert@...>  2009-07-28 07:23:29 PST ---
(In reply to comment #26)
> Hi Vincent,
>
> (In reply to comment #22)
<snip/>

> > A note about the patch: it seemed more sensible to me to deal with integer
> > values rather than double. Indeed every length value is internally converted
> > into a whole number expressed in mpt (AFAICT). That means that I'm using
> > Rectangle instead of Rectangle2D, and I changed some parameters into some
> > classes accordingly (mainly, o.a.f.layoutmgr.Page.java,
> > o.a.f.area.PageViewport.java). But then I noticed that the AreaTreeParser reads
> > the value of the "bounds" attribute as double instead of integer. AFAIK, the
> > XML area tree is produced with whole numbers for the page boundaries; I don't
> > see why a user would change that into decimal numbers (which would mean a
> > precision below the mpt!). So I also modified the AreaTreeParser. I don't think
> > this may create any problem?
>
> I don't think so. I'll extract your changes from your patch and apply that
> separately. That should make it easier for Peter, too.

I've just committed a change to also replace Rectangle2D with Rectangle in
PDFFactory and PDFPage. Forgot to do that in my patch.

> > Also, a few questions:
> <snip/>
> > > fox:crop-offset: <length>{1,4}
> > > Default: 0pt
> > > Same behaviour as with fox:bleed.
> > > The MediaBox is calculated by expanding the BleedBox by the crop offsets.
> >
> > Just to be sure: values will be allowed to be negative, right?
>
> Negative values don't make much sense, if I didn't miss anything.

Actually not, because the simple-page-master's width and height would define
the TrimBox. What I had in mind is to make the BleedBox coincide with the
simple-page-master's boundaries, and define a TrimBox inside it. I was thinking
that sometimes the document may be easier to design this way (especially when
you want areas with dark backgrounds to bleed off the boundary of the final
page). I guess it's not actually the case.

<snip/>

Vincent

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #30 from Jeremias Maerki <jeremias@...>  2009-07-28 23:54:23 PST ---
I've started a Wiki page for the prepress feature:
http://wiki.apache.org/xmlgraphics-fop/PrepressSupport

I'll follow up with some additional thoughts on the fop-dev list as discussion
in Bugzilla is a bit awkward.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Jeremias Maerki-2]

While putting the gathered thoughts on the Wiki, it occurred to me that
the crop mark area is only really relevant if you do have crop marks.
They have to come from somewhere. You can paint them using SVG in a
fixed positioned block-container with negative top/left coordinates.
However, such an SVG will always be designed for a particular page size.
I think it would be easy to offer a plug-in interface for
programmatically painting the crop marks (and color samples etc.). Get a
Graphics2D plus information about the page size and what else is
necessary and some code could paint crop marks for any page size.

We could even go so far and not offer the fox:crop-offset extension at
all and let the crop marks plug-in tell the renderer how big that area
should be. That would also solve the naming closeness (although I
personally don't find that too troublesome if it's properly documented).

I don't need crop marks myself (just the bleed area) but it has been a
topic every now. And everyone had to paint their own crop marks in some
way.

To make it super-flexible, we could define an extension that triggers
the crop-mark painting. Each crop mark plug-in could have a name and
possibly even parameters for customization. For example:

<fo:declarations>
  <fox:crop-marks style="mysimple1" color-bars="gray"/>
</fo:declarations>

However, crop marks are often coupled with imposition features. The crop
marks are different, for example, if you do a 2-up. So the above would
only cover cases with no imposition.

Just brainstorming....

Jeremias Maerki

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #31 from Peter Coppens <pc.subscriptions@...>  2009-07-30 01:25:35 PST ---
Created an attachment (id=24063)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24063)
Patch including Jeremias'es proposed changes

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #32 from Jeremias Maerki <jeremias@...>  2009-07-30 06:37:10 PST ---
Thanks for the new patch, Peter. I've taken a look and found a few issues. I've
already started fixing them. Among them:
- In the Wiki I've switched the meaning for crop-offset to align with what
AntennaHouse did (see their illustration): crop-offset expands from the
TrimBox, not the BleedBox. That is currently not reflected in the code, so I'll
change that, too, if there's no opposition.
- In the AWT preview, the positioning wasn't ok, yet, when there's a bleed or
crop-offset.
- The Java2DRenderer generates an ugly page border which I've disabled locally.
Not sure why we even had that in place. It doesn't make much sense.
- Also, I've changed the background painting in the Java2DRenderer to use the
BleedBox instead of the page size.

Otherwise, the patch makes a good impression. The whole thing is now very
intuitive to use, just like I imagined it should be. I'll just allow some time
for additional feedback from others. In the meantime, I'll finish the changes
to the patch I've started and finally commit the whole thing. BTW, I've also
written a little demo FO which demonstrates the features and how I would go
about doing crop marks with SVG. I'll commit that after the patch is processed.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #33 from Jeremias Maerki <jeremias@...>  2009-07-30 07:16:51 PST ---
Peter, why can fox:scale not have any number greater than 1? Why only support
shrinking but not upsizing?

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #34 from Peter Coppens <pc.subscriptions@...>  2009-07-30 07:27:33 PST ---
(In reply to comment #33)
> Peter, why can fox:scale not have any number greater than 1? Why only support
> shrinking but not upsizing?

Hmmm...probably just an oversight on our end. For the sake of generality it
should be possible to also use >1 values. You want us to send a new 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.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #35 from Peter Coppens <pc.subscriptions@...>  2009-07-30 07:28:18 PST ---
(In reply to comment #32)
> Thanks for the new patch, Peter. I've taken a look and found a few issues. I've
> already started fixing them. Among them:
> - In the Wiki I've switched the meaning for crop-offset to align with what
> AntennaHouse did (see their illustration): crop-offset expands from the
> TrimBox, not the BleedBox. That is currently not reflected in the code, so I'll
> change that, too, if there's no opposition.
Ok for me.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #36 from Jeremias Maerki <jeremias@...>  2009-07-30 07:47:10 PST ---
(In reply to comment #34)
> (In reply to comment #33)
> > Peter, why can fox:scale not have any number greater than 1? Why only support
> > shrinking but not upsizing?
>
> Hmmm...probably just an oversight on our end. For the sake of generality it
> should be possible to also use >1 values. You want us to send a new patch?

Not necessary, thanks. I'll just change that myself then.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311


Jeremias Maerki <jeremias@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #37 from Jeremias Maerki <jeremias@...>  2009-08-02 12:46:22 PST ---
Applied the patch with the changes already mentioned. Thanks a lot for your
patch Peter, and thanks also for your patience with my late involvement.
http://svn.apache.org/viewvc?rev=800142&view=rev

I hope we will have a chance some day to improve the property subsystem so we
can also handle extension like this more elegantly.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47311


Vincent Hennebert <vhennebert@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #38 from Vincent Hennebert <vhennebert@...>  2009-08-03 04:13:09 PST ---
(In reply to comment #37)
> Applied the patch with the changes already mentioned. Thanks a lot for your
> patch Peter, and thanks also for your patience with my late involvement.
> http://svn.apache.org/viewvc?rev=800142&view=rev
>
> I hope we will have a chance some day to improve the property subsystem so we
> can also handle extension like this more elegantly.

This is not quite finished I'm afraid:
- I thought we agreed to set the default value of crop-offset to bleed
- errors in the specification of extension properties are not redirected
through the event mechanism
- there are typos in the PageBoundariesAttributes and PageScaleAttributes
classes
- there is an encapsulation problem: the fall back boxes used when one of the
properties has not been defined are controlled by the client code, instead of
being handled inside the extension class itself (PageBoundariesAttributes).
This can easily lead to inconsistencies (one default value used in the PDF
renderer, another one in the Java2D renderer).

Re-opening the bug as a reminder, as I don't have the time to handle that right
now.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.