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





--- Comment #26 from Jeremias Maerki <jerem...@apache.org>  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.

Reply via email to