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 #16 from Vincent Hennebert vhenneb...@gmail.com 2009-07-16
04:21:28 PST ---
There seems to be another problem: in the Swing preview the zoom no longer
works. I fixed that by multiplying the scales by scaleFactor instead of
overwriting that latter:
if (scales != null) {
scaleX *= scales.getX();
scaleY *= scales.getY();
}
but then scrolling bars appear the same way as if fox:scale had not been
specified. When resizing the window they appear whereas there is obviously
still room for the whole document to fit in.
I have doubts about that scale extension, I must say. It seems very ad-hoc to
me. Can't that be left to some post-processing mechanism? For PDF output this
usually is a job that is handled by the printer. For PNG output I'm sure that
there are plenty of programs that can do that very well (actually I had a
better quality result when re-scaling the PNG output with an external program
than by using the new extension —might be a problem with the Java2D renderer
though).
Also, is there a use case for a non-proportional scale (x scale != y scale)?
Not that having different x and y factors makes the whole thing a lot more
complicated, but...
Thanks,
Vincent
(In reply to comment #13)
(In reply to comment #8)
Created an attachment (id=23941)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=23941) [details]
[details]
updated patch in an attempt to address fop-dev suggestions
Thanks for the updated patch. I tried to run the AWT renderer and it appears
to
have been broken by the changes. The main window is opened but no document is
displayed, and I get the following exception:
Exception in thread AWT-EventQueue-0 java.awt.image.RasterFormatException:
(x
+ width) is outside raster
at
sun.awt.image.IntegerInterleavedRaster.createWritableChild(IntegerInterleavedRaster.java:450)
at java.awt.image.BufferedImage.getSubimage(BufferedImage.java:1156)
at
org.apache.fop.render.java2d.Java2DRenderer.getPageImage(Java2DRenderer.java:379)
at
org.apache.fop.render.java2d.Java2DRenderer.getPageImage(Java2DRenderer.java:425)
at
org.apache.fop.render.awt.viewer.ImageProxyPanel.paintComponent(ImageProxyPanel.java:124)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5122)
at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:277)
at javax.swing.RepaintManager.paint(RepaintManager.java:1217)
at javax.swing.JComponent._paintImmediately(JComponent.java:5070)
at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:803)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:714)
at
javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:694)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
I'll investigate (but: do you really need this feature also for the AWT
renderer? ;-) )
Thanks,
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 47541] New: Wrong handling of retained conditionality when space-before is inherited
https://issues.apache.org/bugzilla/show_bug.cgi?id=47541 Summary: Wrong handling of retained conditionality when space-before is inherited Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: vhenneb...@gmail.com Created an attachment (id=23993) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23993) Sample FO file showing the problem See attached file: block b4 inherits the space-before property from the parent block and overrides the .conditionality component to retain. This results into a space before the first block, at the top of the first page. Normally block 4 should start the second page with a space before it. The bug doesn't occur if all the components of the space are specified on the block instead of being inherited. -- 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 47541] Wrong handling of retained conditionality when space-before is inherited
https://issues.apache.org/bugzilla/show_bug.cgi?id=47541 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Attachment #23993|0 |1 is obsolete|| --- Comment #1 from Vincent Hennebert vhenneb...@gmail.com 2009-07-16 06:08:55 PST --- Created an attachment (id=23994) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23994) The true sample file that shows the problem -- 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 47541] Wrong handling of retained conditionality when space-before is inherited
https://issues.apache.org/bugzilla/show_bug.cgi?id=47541 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2009-07-16 12:36:44 PST --- Not a 100% sure, but I think this behavior has been discussed (way back when), and this is actually not a bug. By specifying the .conditionality component, you implicitly set the other property components to their initial value. Either all the components are inherited, or none. To achieve the desired result, it is wrong to rely on implicit inheritance. Instead, specify a value of 'inherit' for the .length component to avoid using the initial value (0pt). -- 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 47541] Wrong handling of retained conditionality when space-before is inherited
https://issues.apache.org/bugzilla/show_bug.cgi?id=47541 --- Comment #3 from Andreas L. Delmelle adelme...@apache.org 2009-07-16 14:03:20 PST --- Just some additional notes explaining the behavior, that even though it seems unexpected, is actually OK. For compound properties, specifying only one of the components is equivalent to setting all the other components to their initial value. They are not initialized with the inherited value, since the components are NOT(!) separate properties. Implicit inheritance is always defined on the level of the complete property. If one of the components appears as a specified value, the entire property is no longer inherited. If we want to inherit some of the components and override others, we need to use explicit values of 'inherit'. (Seems to be precisely one of the prime use-cases for that keyword) IOW: block space-before=2em block space-before.conditionality=retain is semantically equivalent to block space-before.optimum=2em space-before.conditionality=discard space-before.precedence=0 block space-before.optimum=0pt space-before.conditionality=retain space-before.precedence=0 To achieve the expected result, the correct spec would be: block space-before=2em block space-before.optimum=inherit space-before.conditionality=retain Technically, in FOP (see also the Wiki about property resolution) specified values are always processed first and added to the PropertyList. Later, when binding the PropertyList to the FObj, if there was no specified value for a given applicable property, inheritance will always be tried before reverting to the initial value. When processing the specified properties, and encountering a specified component, we first check if the compound property already exists on the PropertyList. In this context, we don't try inheritance, as we're actually looking for a base property that possibly resulted from other components that were processed before (= appeared earlier in the Attributes). If it does not exist, then we generate that base property, also bypassing inheritance, since we're creating an instance for a specified value. I think this is completely in line with the Recommendation (5.1.4), which hints at the inherited value actually being a fallback for an absent specified value (not a replacement for the initial value; note the order of the resolution rules in 5.1.1). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
