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





--- Comment #22 from Vincent Hennebert <vhenneb...@gmail.com>  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.

Reply via email to