DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
https://issues.apache.org/bugzilla/show_bug.cgi?id=47311 --- Comment #20 from Peter Coppens pc.subscripti...@gmail.com 2009-07-28 00:02:42 PST --- Created an attachment (id=24048) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24048) Box implementation for Java2d now uses pdf box settings The attached patch fixes the previous comment There is an inconsistency between PDF and Java2D regarding the coordinates of the boxes: in PDF the x and y coordinates are relative to the left and bottom sides, in Java2D they are relative to the left and /top/ sides. One of the two possibilities will have to be chosen, probably the PDF way. The boxes for the Java2D renderer now also follows the PDF way -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
https://issues.apache.org/bugzilla/show_bug.cgi?id=47311
--- Comment #21 from Jeremias Maerki jerem...@apache.org 2009-07-28 01:39:04
PST ---
Hi Peter,
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
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.
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 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?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
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.
DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
https://issues.apache.org/bugzilla/show_bug.cgi?id=47311 --- Comment #24 from Peter Coppens pc.subscripti...@gmail.com 2009-07-28 04:42:22 PST --- We were just about to start to rework the patch according to the suggestions made by Jeremias which seem to make a lot of sense, but I am not so sure anymore that is still useful given Vincent's alternative implementation/efforts which we were unaware of. It's a bit unclear right now how we can continue to contribute given the different implementation efforts We still have a bit of bandwith to spare on this (it is important for us) but we'd rather make sure those efforts are part of a consolidated action Can someone advice? Thanks Peter -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
https://issues.apache.org/bugzilla/show_bug.cgi?id=47311 --- Comment #25 from Jeremias Maerki jerem...@apache.org 2009-07-28 04:54:14 PST --- Peter, I'll respond to Vincent's comments shortly. I think his changes shouldn't affect your changes too much. I think Vincent's comments make sense and I'll see to it that they can be committed separately (they don't really have much to do with the issue at hand). Then it will ideally just be a svn up on your side to resolve this. And a minor SVN conflict in the worst case. I suggest you just continue as intended. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
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.
DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
https://issues.apache.org/bugzilla/show_bug.cgi?id=47311 --- Comment #27 from Jeremias Maerki jerem...@apache.org 2009-07-28 05:57:22 PST --- Partially applied Vincent's patch (from today). I've also applied the undisputed parts of Peter's patch. So the next patch by Peter will only need to be about the extensions and their integration into the renderers. I hope the result will merge as painlessly as possible. http://svn.apache.org/viewvc?rev=798511view=rev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
https://issues.apache.org/bugzilla/show_bug.cgi?id=47311 --- Comment #28 from Peter Coppens pc.subscripti...@gmail.com 2009-07-28 06:46:26 PST --- 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/ Hmmm...not entirely happy with this unfortunately. We have a webapp that using a flex wysiwyg editor allows creation of print materials but that uses adobe's pdf browser plugin for end-user proofing and approval. In some cases we'd rather display the trimbox iso the mediabox so my guess is we should be able to control the CropBox setting, no? Perhaps a name change for the attribute is sufficient? E.g. something like crop-box-selector, or crop-box-source or something similar? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Work on ChangingIPDHack Finished
Hi, Vincent Hennebert wrote: Hi Simon, Thank you for giving a go at testing the branch. I could reproduce the hyphenation and flow_changing-ipd_4.xml problems. Regarding the stretch issue, could you send me a sample FO file? I suspect that this may be normal in the sense that the layout policy is slightly different when there is changing IPD: Instead of being full total-fit, it’s ‘n-pages total fit’ i.e., total-fit over the number of pages that have the same ipd. When the ipd changes, the best node /so far/ is selected, which may be different from the node that is part of the optimal solution, had the ipd remained the same. I had a look at the file Simon sent me off-list, and this is indeed what happens. Basically, the first page contains n lines with the ChangingIPD version, and n + 2 with the Trunk. The n-lines version is the one that is closest to the spaces’ natural lengths. In the n + 2 version spaces are shrunk quite a bit. The n-lines version has less demerits than the n + 2 one, so it’s the one that is chosen by the algorithm before re-generating the Knuth elements for the next page with a different width. But it appears that chosing the n + 2 version leads to less total demerits, so this is why it is selected by the Trunk. I committed yesterday fixes for the other bugs that Simon rose. snip/ Thanks again for testing, Vincent
