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