https://issues.apache.org/bugzilla/show_bug.cgi?id=47311
--- Comment #19 from Vincent Hennebert <vhenneb...@gmail.com> 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.
