--- Comment #21 from Jeremias Maerki <jerem...@apache.org> 2009-07-28 01:39:04
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
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
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.)
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.
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
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.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.