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 #30 from Jeremias Maerki jerem...@apache.org 2009-07-28 23:54:23 PST --- I've started a Wiki page for the prepress feature: http://wiki.apache.org/xmlgraphics-fop/PrepressSupport I'll follow up with some additional thoughts on the fop-dev list as discussion in Bugzilla is a bit awkward. -- 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: Prepress features (was: DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling)
While putting the gathered thoughts on the Wiki, it occurred to me that the crop mark area is only really relevant if you do have crop marks. They have to come from somewhere. You can paint them using SVG in a fixed positioned block-container with negative top/left coordinates. However, such an SVG will always be designed for a particular page size. I think it would be easy to offer a plug-in interface for programmatically painting the crop marks (and color samples etc.). Get a Graphics2D plus information about the page size and what else is necessary and some code could paint crop marks for any page size. We could even go so far and not offer the fox:crop-offset extension at all and let the crop marks plug-in tell the renderer how big that area should be. That would also solve the naming closeness (although I personally don't find that too troublesome if it's properly documented). I don't need crop marks myself (just the bleed area) but it has been a topic every now. And everyone had to paint their own crop marks in some way. To make it super-flexible, we could define an extension that triggers the crop-mark painting. Each crop mark plug-in could have a name and possibly even parameters for customization. For example: fo:declarations fox:crop-marks style=mysimple1 color-bars=gray/ /fo:declarations However, crop marks are often coupled with imposition features. The crop marks are different, for example, if you do a 2-up. So the above would only cover cases with no imposition. Just brainstorming Jeremias Maerki
AIOOB from LineBreakUtils
Hi all,
When I am generating a PDF-file, the class LineBreakUtils and the method
public static byte getLineBreakPairProperty(int lineBreakPropertyBefore,int
lineBreakPropertyAfter) {
return
PAIR_TABLE[lineBreakPropertyBefore-1][lineBreakPropertyAfter-1];
}
keeps on giving me an ArrayIndexOutOfBoundsException -1 for what I am
guessing is some automatic trimming/line breaking for an especially long
string or something. The two values are
lineBreakPropertyBefore = 2
lineBreakPropertyAfter = 0
I have been searching around the forum for this for a long time and could
not find anything related to this. Have anyone else had any problems with
this? Any idea of what might cause this?
Thank you for your time,
Lars
--
View this message in context:
http://www.nabble.com/AIOOB-from-LineBreakUtils-tp24715350p24715350.html
Sent from the FOP - Dev mailing list archive at Nabble.com.
DO NOT REPLY [Bug 41999] [PATCH] Unassigned code points cause ArrayIndexOutOfBoundsException in LineBreakUtils
https://issues.apache.org/bugzilla/show_bug.cgi?id=41999 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added Summary|Unassigned code points |[PATCH] Unassigned code |cause |points cause |ArrayIndexOutOfBoundsExcept |ArrayIndexOutOfBoundsExcept |ion in LineBreakUtils |ion in LineBreakUtils -- 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: AIOOB from LineBreakUtils
Lars Andren wrote:
Hi all,
Hi Lars,
When I am generating a PDF-file, the class LineBreakUtils and the method
public static byte getLineBreakPairProperty(int lineBreakPropertyBefore,int
lineBreakPropertyAfter) {
return
PAIR_TABLE[lineBreakPropertyBefore-1][lineBreakPropertyAfter-1];
}
keeps on giving me an ArrayIndexOutOfBoundsException -1 for what I am
guessing is some automatic trimming/line breaking for an especially long
string or something. The two values are
lineBreakPropertyBefore = 2
lineBreakPropertyAfter = 0
There is already a bug logged for this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=41999. The bug
already contains a patch. I don't think there is any further information
on this issue. If you are having trouble applying the patch and
compiling then please paste your compilation errors to fop-user mailing
list and we will try to help you.
I have been searching around the forum for this for a long time and could
not find anything related to this. Have anyone else had any problems with
this? Any idea of what might cause this?
Thank you for your time,
Lars
Thanks,
Chris
