https://issues.apache.org/bugzilla/show_bug.cgi?id=47311
--- Comment #22 from Vincent Hennebert <[email protected]> 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.
