DO NOT REPLY [Bug 47311] New: [PATCH] Support for bleed, trim and crop box and scaling

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

           Summary: [PATCH] Support for bleed, trim and crop box and
                    scaling
           Product: Fop
           Version: all
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: general
        AssignedTo: fop-dev@...
        ReportedBy: pc.subscriptions@...


Created an attachment (id=23751)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23751)
Patch adding support for bleed, trim and crop box and scaling

The attached patch adds support for 4 new simple-page-master fop extension
attributes, namely

- fox:crop-box
- fox:trim-box
- fox:bleed-box
- fox:scale

The box attributes can consist out of up to 4 numeric values (top,left, width,
height) and can have units as suffix to each of the numbers.

The scale attribute can consist out of two numbers each between 0 and 1

It is implemented for PDF and Java2D renderers.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #1 from Andreas L. Delmelle <adelmelle@...>  2009-06-03 11:53:21 PST ---

Thanks for this patch, Peter!

I know this is going to be very useful, as questions regarding that
functionality pop up on the user list from time to time. We'll look into it,
and will keep you informed. I currently have other priorities, but as soon as I
see an available slot of time, if no one beats me to it, I'll go into it in
more detail.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #2 from Peter Coppens <pc.subscriptions@...>  2009-06-17 22:46:19 PST ---
(In reply to comment #1)
> Thanks for this patch, Peter!
>
> I know this is going to be very useful, as questions regarding that
> functionality pop up on the user list from time to time. We'll look into it,
> and will keep you informed. I currently have other priorities, but as soon as I
> see an available slot of time, if no one beats me to it, I'll go into it in
> more detail.


I was wondering whether there is anything I can do to make this move forward.

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.

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





--- Comment #3 from Vincent Hennebert <vhennebert@...>  2009-06-18 04:07:38 PST ---
Hi Peter,

(In reply to comment #2)

> (In reply to comment #1)
> > Thanks for this patch, Peter!
> >
> > I know this is going to be very useful, as questions regarding that
> > functionality pop up on the user list from time to time. We'll look into it,
> > and will keep you informed. I currently have other priorities, but as soon as I
> > see an available slot of time, if no one beats me to it, I'll go into it in
> > more detail.
>
>
> I was wondering whether there is anything I can do to make this move forward.

Not much until we have reviewed the patch and provided comments. Then, if
modifications are needed you may want to do them yourself and provide an
updated patch, which would speed up its integration in the code base.

I've only had a quick look so far and can't give much feedback yet. I'll try to
have a deeper look in the next days. A few things I noticed, though:
- the IllegalArgumentException in ExtensionElementMapping will have to be
replaced by a call to FOP's event notification mechanism (so that the message
can be localized, among others things). Have a look in, e.g.,
org.apache.fop.fo.flow.Table.java to see how it is used (TableEventProducer in
that case)
- the new features will have to be documented on the website. The corresponding
source files may be found in the src/documentation/content/xdocs/trunk
directory. The ideal place probably is extensions.xml, with a link in
output.xml.
- there are Checkstyle warnings in the new code. You can set up Checkstyle
using the checkstyle-4.0.xml at the root of the project.

Those are things that we will have to do before applying the patch anyway, so
if you want to speed up the process you can have a go at them.

Back later, hopefully, for comments on the functionalities themselves.

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.

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





--- Comment #4 from Vincent Hennebert <vhennebert@...>  2009-06-26 03:08:28 PST ---
I've had a more detailed look at the patch and it looks good to me. A few other
comments:
- the definition and parsing of the extension properties should not be put in
ExtensionElementMapping, but in a class (and a sub-package) of its own. Where
exactly it should be put is not entirely clear to me yet. Probably in a new
o.a.f.render.extensions package. How to name the new sub-package also is an
open question (scalingcropbleedtrim? rather ugly... pageboundaries (taken from
the PDF spec)? prepress?).
- amendment to what I said about the event notification mechanism: the
extension should not use it, rather throw appropriate exceptions, which would
be passed over by the PDF library (the classes in o.a.f.pdf) to the
PDFDocumentHandler. The former two should remain independent of the
notification mechanism to allow later extraction from the FOP codebase and
modularization. Only the PDFDocumentHandler must be aware of the notification
mechanism.
- the regexp parsing properties should be made slightly more robust and
unit-tested.
- I have a concern about when the properties are actually parsed. Like it is
now they will be parsed only at rendering stage, so if there is a mistake in
them the error will be thrown rather 'late' in the process (only after layout
has been performed). May that be a problem? Do we want a 'fail-fast' behaviour
instead? Open question.

I'm happy to do all the mentioned changes myself, but this will be in one week
at the earliest as I'm away next week. Peter, if meanwhile you want to submit
an updated patch feel free to do so :-)

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.

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





--- Comment #5 from Andreas L. Delmelle <adelmelle@...>  2009-06-26 03:54:12 PST ---
(In reply to comment #4)
> - I have a concern about when the properties are actually parsed. Like it is
> now they will be parsed only at rendering stage, so if there is a mistake in
> them the error will be thrown rather 'late' in the process (only after layout
> has been performed). May that be a problem? Do we want a 'fail-fast' behaviour
> instead? Open question.

Well, since the extension attributes are specific to the PDF renderer, I think
it is not a blocker to treat them as plain 'foreign attributes' at parse-time.
One case comes to mind where we would need to treat them as genuine
'properties': suppose we want to be able to specify them as expressions, based
on other properties.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #6 from Andreas L. Delmelle <adelmelle@...>  2009-06-26 04:02:05 PST ---
(In reply to comment #5)
>
> Well, since the extension attributes are specific to the PDF renderer, I think

Sorry, ignore this. I just noticed that in the patch, the extension is also
implemented for the Java2D-based renderers...

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #7 from Andreas L. Delmelle <adelmelle@...>  2009-06-26 04:37:10 PST ---

Just noting this for general interest (has little or nothing to do with this
issue per se):
The previous comments suddenly reminded me that I have always considered the
current way that extension /properties/ are handled, as lacking in robustness.
We practically force potential implementors of extension properties to modify
FOP's codebase. For extension elements or attributes, the pattern is much more
open and generic. They can be implemented without necessarily having to modify
FOP and recompile. The same should become the case for extension properties,
eventually. We probably will want to take a look at offering something like an
'ExtensionPropertyMapping' (currently non-existent), so that implementors can
re-use existing PropertyMakers, define their own initial values/enums/keywords,
mark properties as inherited, and so on...

There are already a few 'native' extension properties, for which we define
symbolic literals in fo.Constants and which are also registered in
fo.FOPropertyMapping. I have never really been too happy with that practice.
Contributors are invited to follow that pattern, which will only lead to more
clutter.

Tackling that issue, however, is not for the faint of heart. It would likely
also imply revisiting the way properties are attached to the FONodes and how
they are exposed to the outside (layoutengine & renderers), so would lead to
changes in a Lot of classes (capital 'L', if you catch the drift...)

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #8 from Peter Coppens <pc.subscriptions@...>  2009-07-08 07:01:16 PST ---
Created an attachment (id=23941)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23941)
updated patch in an attempt to address fop-dev suggestions

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #9 from Sean Griffin <sgriffin@...>  2009-07-09 07:01:12 PST ---
I think I might have missed something on the mailing lists explaining these
features, but Peter, can you explain what these new properties do?  What they
offer that it's in the spec?

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #10 from Peter Coppens <pc.subscriptions@...>  2009-07-09 07:21:32 PST ---
(In reply to comment #9)
> I think I might have missed something on the mailing lists explaining these
> features, but Peter, can you explain what these new properties do?  What they
> offer that it's in the spec?

See beginning of bugzilla entry which says
<quote>

Patch adding support for bleed, trim and crop box and scaling

The attached patch adds support for 4 new simple-page-master fop extension
attributes, namely

- fox:crop-box
- fox:trim-box
- fox:bleed-box
- fox:scale

The box attributes can consist out of up to 4 numeric values (top,left, width,
height) and can have units as suffix to each of the numbers.

The scale attribute can consist out of two numbers each between 0 and 1

It is implemented for PDF and Java2D renderers.
</quote>

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #11 from Sean Griffin <sgriffin@...>  2009-07-09 07:29:51 PST ---
Yeah, I saw that, but that still doesn't tell me what I'm looking for.  What's
the use case for using these properties?  What functionality do they offer
that's not in other properties in the specification?  Is this for background
images or something?  Watermarks?

Based on Andreas's comments in this bug this sounds like a common feature
request, I've just never heard of it.

I'm only curious because I use FOP pretty extensively and wonder if these
extensions add something I would find useful.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #12 from Peter Coppens <pc.subscriptions@...>  2009-07-09 07:42:02 PST ---
(In reply to comment #11)

> Yeah, I saw that, but that still doesn't tell me what I'm looking for.  What's
> the use case for using these properties?  What functionality do they offer
> that's not in other properties in the specification?  Is this for background
> images or something?  Watermarks?
>
> Based on Andreas's comments in this bug this sounds like a common feature
> request, I've just never heard of it.
>
> I'm only curious because I use FOP pretty extensively and wonder if these
> extensions add something I would find useful.

Ah..ic

The box'es set the pdf page boxes with the same name. I found
http://www.prepressure.com/pdf/basics/page_boxes useful (not necessarily
finding the pdf spec an easy read ;)). These boxes are often used to drive what
is actually printed as compared to what e.g. acrobat displays

Scale is something we needed to use fop for creating adverts. The size of the
output depends on e.g. the magazine you want your advert to be published in. As
we want to use same stylesheet for different magazines a scale factor makes
that possible

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #13 from Vincent Hennebert <vhennebert@...>  2009-07-14 04:23:42 PST ---
(In reply to comment #8)
> Created an attachment (id=23941)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23941) [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.

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





--- Comment #14 from Peter Coppens <pc.subscriptions@...>  2009-07-14 05:07:06 PST ---
>
> 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

Oops...that is not so good

>
> I'll investigate (but: do you really need this feature also for the AWT
> renderer? ;-) )
>
Actually 'only' for png output but both awt and png output probably originate
from the Java2DRenderer ?

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #15 from Peter Coppens <pc.subscriptions@...>  2009-07-14 08:25:06 PST ---
Created an attachment (id=23978)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23978)
Updated patch avoid awt issue

Another attempt (hopefully) not breaking awt renderer

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #16 from Vincent Hennebert <vhennebert@...>  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.

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





--- Comment #17 from Peter Coppens <pc.subscriptions@...>  2009-07-22 00:04:55 PST ---
Created an attachment (id=24018)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24018)
AWTRenderer change to take into account fop:scale setting

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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





--- Comment #18 from Peter Coppens <pc.subscriptions@...>  2009-07-22 00:16:37 PST ---
>>I fixed that by multiplying the scales by scaleFactor instead of
>>overwriting that latter:
Yeah..that seems correct.


> 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).
>
Obviously scaling can be handled through a post processing step, just like
adding the pdf boxes can be handled using e.g. PDFBox after fop has rendered
the stylesheet to pdf. This is what we currently use. But it is very inelegant
as we now need to also store 'template/stylesheet' information outside the
stylesheet, dispatch postprocessing based on output type, and it also adds
extra processing overhead where, with the integrated approach, almost no extra
overhead is needed. Once confronted with things like 'adverts' where page size
options are very restricted by publishers it does seem to make sense to
integrate it all together, at least from a 'users' perspective. Whether it
makes sense for fo(p), I feel not very well placed to comment (at lease the box
requirement has been requested before)

>
> 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...
>
Publishers do restrict aspect ratio's. It does not make sense, layout wise, to
do 'big' non-proportional scalings, but small factors allow to reuse the same
stylesheet page content, for different 'publishers' and that does make the
amount of maintenance a lot more manageable.

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.

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





--- Comment #19 from Vincent Hennebert <vhennebert@...>  2009-07-23 04:16:23 PST ---
Hi,

(In reply to comment #18)
> >>I fixed that by multiplying the scales by scaleFactor instead of
> >>overwriting that latter:
> Yeah..that seems correct.

In the meantime, I found out why the Swing renderer doesn't take the scale
extension into account: the AWTRenderer class (which should have been named
SwingRenderer really) defines its own getPageImageSize method instead of
re-using the stuff from Java2DRenderer.getPageImage. I'll see if I find the
energy to fix that.

> > 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).
> >
> Obviously scaling can be handled through a post processing step, just like
> adding the pdf boxes can be handled using e.g. PDFBox after fop has rendered
> the stylesheet to pdf. This is what we currently use. But it is very inelegant
> as we now need to also store 'template/stylesheet' information outside the
> stylesheet, dispatch postprocessing based on output type, and it also adds
> extra processing overhead where, with the integrated approach, almost no extra
> overhead is needed. Once confronted with things like 'adverts' where page size
> options are very restricted by publishers it does seem to make sense to
> integrate it all together, at least from a 'users' perspective. Whether it
> makes sense for fo(p), I feel not very well placed to comment (at lease the box
> requirement has been requested before)

Note that I don't question the box extensions, which are indeed useful and have
already been requested in the past. Only the scale extension was looking very
specific to me.


> > 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...
> >
> Publishers do restrict aspect ratio's. It does not make sense, layout wise, to
> do 'big' non-proportional scalings, but small factors allow to reuse the same
> stylesheet page content, for different 'publishers' and that does make the
> amount of maintenance a lot more manageable.

Ok. Makes sense.

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.


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.