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 #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.
Work on ChangingIPDHack Finished
Hi All, I’m basically finished with the implementation of the hack to handle pages of different widths. As a remainder, tables and lists aren’t supported; this means that they will flow on the new page without taking the new width into account. So if there is a switch between e.g. a landscape page and a portrait page, part of the table/list will be silently rendered outside of the page. This is a limitation that I a not willing to fix as this implies too much work on something that will be made obsolete by the new layout approach anyway. All of the other FOs should be supported. I committed some simple test cases in the branch, but I’d be grateful if people could test it with their own (possibly real-life) FO files. I’d like to do it in two steps: first ask for feedback here (I know there are plenty of people silently watching this list ;-) ), then broaden the audience and ask on the users list. To ease the lives of users I’ll probably set up a web page in my personal area at people.apache.org, and provide links to ready-made binary archives, just like official releases. People who aren’t keen on building the branch from sources can feel free to wait for that phase. The branch is to be found here: http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack Or, for European users: http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack My hope is that if there are any ‘big’ bugs left that make FOP crash, they will be spotted in the first phase, and can quickly be fixed and re-tested in short commit/copy update/re-build/re-test cycles. Something that power users shouldn’t be afraid of, whereas too frequent updates of the web page might confuse less knowledgeable users. Thanks, Vincent
AFP: Font Embedding
Hi there, I'll work on AFP font embedding in the next few days. So far, all AFP fonts were always referenced (embedding is not supported right now). I'm planning to introduce the same behaviour as for PDF and PostScript: embed all fonts by default except if embedding is forbidden or the referenced-fonts element contains a match for a font. Embedding AFP fonts is best practice AFAIK. It also simplifies verification in various AFP viewers because you don't have to set up the fonts for all viewers and printers separately. But of course, this changes the current default behaviour which is why I bring this up. Does anybody see a problem with the course of action? Thanks, Jeremias Maerki
Re: AFP: Font Embedding
Hi Jeremias, Good to see you active again on FOP-related work. Welcome back. I hope you will enjoy it again. Simon On Thu, Jul 23, 2009 at 04:08:48PM +0200, Jeremias Maerki wrote: Hi there, I'll work on AFP font embedding in the next few days. So far, all AFP fonts were always referenced (embedding is not supported right now). I'm planning to introduce the same behaviour as for PDF and PostScript: embed all fonts by default except if embedding is forbidden or the referenced-fonts element contains a match for a font. Embedding AFP fonts is best practice AFAIK. It also simplifies verification in various AFP viewers because you don't have to set up the fonts for all viewers and printers separately. But of course, this changes the current default behaviour which is why I bring this up. Does anybody see a problem with the course of action? Thanks, Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.eu
