Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF
(some comments inline...) On 13.12.2005 22:02:52 JBryant wrote: Hi, Jeremias, Jay, if you'd like to help systematic testing here that would be fantastic. Please note that quite a few test cases already exist in test/layoutengine/standard-testcases (everything that starts with external-graphic and instream-foreign-object). Please note that the size calculations for both formatting objects use the same code (AbstractGraphicsLayoutManager) which means that fixing one, fixes the other, too. Having more test cases like the existing ones would be great and is the first important step towards fixing all remaining problems. Well, I wrote some XSLT code that produced 124 test files. Here's a typical file: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=only margin-top=1in margin-left=1in margin-right=1in margin-bottom=1in fo:region-body region-name=only/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=only fo:flow flow-name=only fo:block fo:external-graphic src=tooWideGraphic.jpg content-height=auto content-width=468px height=auto width=auto/ /fo:block /fo:flow /fo:page-sequence /fo:root Here's the XML file I used to define the testing: ?xml version=1.0 encoding=UTF-8? test-values test name=content-width valueauto/value valuescale-to-fit/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=content-height valueauto/value valuescale-to-fit/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=height valueauto/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=width valueauto/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=image-type valuegif/value valuejpg/value /test test name=image-name valuetooNarrowGraphic/value valuetooWideGraphic/value /test /test-values (tooNarrowGraphic and tooWideGraphic are just simple images that are, respectively, narrower or wider than the content area.) I wound up with 124 files rather than 20736 files because I blocked any test that had more than one value that wasn't auto. I could generate the other files, but 124 is about my limit for visually checking PDF files to see if I got the proper output. The good news is that I got the output I expected in all cases (though I had to check the spec pretty carefully to be sure of that in some cases). From an implementor's point of view, blocking files with more than one non-auto value may not be ideal because sometimes combination with more restrictions uncover problems. On the other side, the various widths you used are rather testing the property subsystem than the image layout code. Also, it's not necessary to test different image formats. The code is the same. The only thing here is to make sure that the image loaders are reporting the image's intrinsic size correctly. I'd rather go after things like a width bigger and smaller than the available space or than the image size, respectively. I figure I'll skip checking them all into your testing system, as it would be massive overkill, but I thought you might want to know the results of my testing. If you do want them (or some subset of them), let me know. Also, if you'd like me to programatically generate test files for other elements or properties, let me know. It's not hard to do. Concerning your suggestion of a scale-down-to-fit I'd say that this is not necessary provided I've understood your requirement. I can certainly get by without it, but it seems like a nice convenience feature. It's in the 1.1 spec, so maybe I'll get to use it someday. I didn't know it was in the 1.1 spec. That changes the situation, of course. I was under the impression that the option is not necessary but I guess from a user's point of view this is easier than doing strange property combinations like I suggested. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF
Hi, Jeremias, Jay, if you'd like to help systematic testing here that would be fantastic. Please note that quite a few test cases already exist in test/layoutengine/standard-testcases (everything that starts with external-graphic and instream-foreign-object). Please note that the size calculations for both formatting objects use the same code (AbstractGraphicsLayoutManager) which means that fixing one, fixes the other, too. Having more test cases like the existing ones would be great and is the first important step towards fixing all remaining problems. Well, I wrote some XSLT code that produced 124 test files. Here's a typical file: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=only margin-top=1in margin-left=1in margin-right=1in margin-bottom=1in fo:region-body region-name=only/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=only fo:flow flow-name=only fo:block fo:external-graphic src=tooWideGraphic.jpg content-height=auto content-width=468px height=auto width=auto/ /fo:block /fo:flow /fo:page-sequence /fo:root Here's the XML file I used to define the testing: ?xml version=1.0 encoding=UTF-8? test-values test name=content-width valueauto/value valuescale-to-fit/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=content-height valueauto/value valuescale-to-fit/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=height valueauto/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=width valueauto/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=image-type valuegif/value valuejpg/value /test test name=image-name valuetooNarrowGraphic/value valuetooWideGraphic/value /test /test-values (tooNarrowGraphic and tooWideGraphic are just simple images that are, respectively, narrower or wider than the content area.) I wound up with 124 files rather than 20736 files because I blocked any test that had more than one value that wasn't auto. I could generate the other files, but 124 is about my limit for visually checking PDF files to see if I got the proper output. The good news is that I got the output I expected in all cases (though I had to check the spec pretty carefully to be sure of that in some cases). I figure I'll skip checking them all into your testing system, as it would be massive overkill, but I thought you might want to know the results of my testing. If you do want them (or some subset of them), let me know. Also, if you'd like me to programatically generate test files for other elements or properties, let me know. It's not hard to do. Concerning your suggestion of a scale-down-to-fit I'd say that this is not necessary provided I've understood your requirement. I can certainly get by without it, but it seems like a nice convenience feature. It's in the 1.1 spec, so maybe I'll get to use it someday. Jay Bryant Bryant Communication Services (presently consulting at Synergistic Solution Technologies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF
Ok, guys. Time for me to chime in. I've read through all the messages and have a few things to add: java.lang.RuntimeException: Some content could not fit into a line/page after 50 attempts. Giving up to avoid an endless loop. This messages in our context here says nothing about the image not fitting into the available width, although the message might suggest so. The problem is actually that the image does not fit vertically in the available height. The feature that tries to fit a box into a later page if it doesn't fit into the current page is currently only enabled for page breaking (i.e. vertical direction). The same algorithm is used for line breaking but has this feature currently disabled because we don't have changing available width from line to line as we don't support side-floats, yet. Andreas was right that the broken PDF is a result of the above error message which is actually an exception that stops processing. In general, The error message itself is not a bug. It may simply be that your images are too big to fit into the page. In my tests I found no bugs, only images that didn't fit vertically due to settings on the external-graphic. But that doesn't mean there are no bugs or no missing features in external-graphic(read on) Andreas is right about the bug for scaling=non-uniform, height set and content-height set to scale-to-fit. Jay, if you'd like to help systematic testing here that would be fantastic. Please note that quite a few test cases already exist in test/layoutengine/standard-testcases (everything that starts with external-graphic and instream-foreign-object). Please note that the size calculations for both formatting objects use the same code (AbstractGraphicsLayoutManager) which means that fixing one, fixes the other, too. Having more test cases like the existing ones would be great and is the first important step towards fixing all remaining problems. Concerning your suggestion of a scale-down-to-fit I'd say that this is not necessary provided I've understood your requirement. In theory, I think you'd need to do this: fo:external-graphic src=... inline-progression-dimension.maximum=100% content-width=scale-to-fit/ This will leave inline-progression-dimension.optimum to auto which means the image (viewport) size can adjust itself based on its contents, but only up to the maximum which I specified as 100% of the available width. Due to the scale-to-fit, the image will be painted at 100% size as long as it's no wider than the available width, as if content-width were specified as auto. But as soon as the intrinsic width grows beyong the limit it is scaled down to fit. The only problem: i-p-d.maximum is currently not used in the whole process. I've started to hack something in but realized that it will make some additional refactoring necessary. Not a 5-minute job. The whole calculation gets more complicated all the time. Also, Andreas' bug shows that there are certain cases, that currently aren't handled correctly. So let's better create more test cases before we change anything. Get the whole picture and such... On 11.12.2005 00:52:45 Jay Bryant wrote: I wasn't being very methodical with my earlier testing. Rather, I was pursuing whatever ideas my intuition brought to me. I think a test plan that works all combinations of the width, content-width, height, content-height, and scaling properties (in each unit of measure, too) is in order. I'll see what I can do along that line. Jay Bryant Bryant Communication Services - Original Message - From: Andreas L Delmelle [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Saturday, December 10, 2005 3:09 PM Subject: Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF On Dec 10, 2005, at 22:03, Andreas L Delmelle wrote: fo:external-graphic src=... width=auto content-width=auto height=auto content-height=scale-to-fit scaling=non-uniform / Correction: this is OK - width/height = auto means use content-size - content-height=scale-to-fit, so content-width is our last hope, and that is auto so that means we should be using the intrinsic image-width, determine width from there, so the e-g height becomes intrinsic image-height (and the block height). and fo:external-graphic src=... width=auto content-width=auto height=2.9cm content-height=scale-to-fit scaling=non-uniform / but here I'd expect the block height to be at most 2.9cm. That is currently not the case. This seems to be giving strange results... Those interested, try it out. On my side, it seems like the intrinsic image height is used to determine the block height (?) Not the behavior I would expect... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF - workaround found
On Dec 10, 2005, at 00:34, [EMAIL PROTECTED] wrote: Hi Jay, After reading the spec, I thought of trying to make the image a fixed width, so I tried fo:external-graphic src=someimage.gif content-width=5.5in/ That makes images less than 5.5 inches wide be 5.5 inches wide, Errm... Now you're losing me. I thought you were trying to avoid smaller images being scaled up (?) A fixed value for content-width per se implies scaling if the image is smaller/larger... but the PDF file created by FOP still blows up when it encounters images larger than 5.5 inches wide. Have you tried adding width=... to the fo:external-graphic? Works fine for me. I must say that it is weird that specifying the width seems to be mandatory ATM. If width is absent (= implicit value of 'auto'), then for an fo:external-graphic it should become the content-width of the graphic, but currently it makes FOP crash in case the image is larger than the specified content-width... Writing fo:external-graphic src=image.gif width=5.5in content- width=5.5in / should come down to the same as what you have above. Even stranger is that I also checked fo:external-graphic src=... width=auto content-width=5.5in / and that worked nicely. So currently there is a difference between an explicit or an implicit auto-width... Then I tried it with content-width=396px, and that worked. Yay! ... except when the content-width is specified in pixels. I still think there's a bug in there somewhere, but at least there's a workaround. Yup, definitely a bug somewhere. As for a workaround, again, I was under the impression that you needed images smaller than 5.5in to remain as wide as they intrinsically are, but only need scaling down for larger graphics... Have I misinterpreted something? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF
On Dec 10, 2005, at 00:14, [EMAIL PROTECTED] wrote: Hi Jay, See above: If you're not overriding the default resolution, this is caused by the fact that 528px is 7.33in in the default resolution. I don't think that's the issue. The algorithm in that template is if the image is more than 396 pixels wide, scale the image. It doesn't try to scale the image to 396 pixels. So, the line in the FO file is What I meant was that you would only scale images that are larger than the assumed 5.5in, which is actually 7.33in in default resolution. So, the images between 5.5in and 7.33in won't be scaled down, but they won't fit either... fo:external-graphic src=someimage.gif content-width=scale-to- fit/ This is tricky. See the remark about auto-width in my previous mail. How is the formatter supposed to determine the width here if the content-size isn't a fixed value? I suppose it then takes the intrinsic image-height as a basis, so again, the image may end up too large to fit in the area... snip / It's my understanding that content-width=scale-to-fit should shrink larger images and expand smaller images to fill the width of the content area. The content-area is that of the external-graphic itself, so... Yes, but only if the width specified on the external-graphic is fixed/ absolute or a percentage of the width of the containing block. If the width is 'auto', the formatter must use the content-size... At this point, I suspect that content-width=scale-to-fit is not working correctly. On the contrary, it is working almost perfectly, apart from the minor bugger I mentioned in the previous mail... and now that I come to think of it, even that could turn out to not be erroneous. Think of it this way: fo:external-graphic src=image.gif content-width=scale-to-fit / is the same as fo:external-graphic src=image.gif width=auto content- width=scale-to-fit height=auto content-height=auto / which would mean... Right! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF
On Dec 10, 2005, at 22:03, Andreas L Delmelle wrote: fo:external-graphic src=... width=auto content-width=auto height=auto content-height=scale-to-fit scaling=non-uniform / Correction: this is OK - width/height = auto means use content-size - content-height=scale-to-fit, so content-width is our last hope, and that is auto so that means we should be using the intrinsic image-width, determine width from there, so the e-g height becomes intrinsic image-height (and the block height). and fo:external-graphic src=... width=auto content-width=auto height=2.9cm content-height=scale-to-fit scaling=non-uniform / but here I'd expect the block height to be at most 2.9cm. That is currently not the case. This seems to be giving strange results... Those interested, try it out. On my side, it seems like the intrinsic image height is used to determine the block height (?) Not the behavior I would expect... Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF
I wasn't being very methodical with my earlier testing. Rather, I was pursuing whatever ideas my intuition brought to me. I think a test plan that works all combinations of the width, content-width, height, content-height, and scaling properties (in each unit of measure, too) is in order. I'll see what I can do along that line. Jay Bryant Bryant Communication Services - Original Message - From: Andreas L Delmelle [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Saturday, December 10, 2005 3:09 PM Subject: Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF On Dec 10, 2005, at 22:03, Andreas L Delmelle wrote: fo:external-graphic src=... width=auto content-width=auto height=auto content-height=scale-to-fit scaling=non-uniform / Correction: this is OK - width/height = auto means use content-size - content-height=scale-to-fit, so content-width is our last hope, and that is auto so that means we should be using the intrinsic image-width, determine width from there, so the e-g height becomes intrinsic image-height (and the block height). and fo:external-graphic src=... width=auto content-width=auto height=2.9cm content-height=scale-to-fit scaling=non-uniform / but here I'd expect the block height to be at most 2.9cm. That is currently not the case. This seems to be giving strange results... Those interested, try it out. On my side, it seems like the intrinsic image height is used to determine the block height (?) Not the behavior I would expect... Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF - workaround found
An additional update to my testing: After reading the spec, I thought of trying to make the image a fixed width, so I tried fo:external-graphic src=someimage.gif content-width=5.5in/ That makes images less than 5.5 inches wide be 5.5 inches wide, but the PDF file created by FOP still blows up when it encounters images larger than 5.5 inches wide. Then I tried it with content-width=396px, and that worked. Yay! I still think there's a bug in there somewhere, but at least there's a workaround. FWIW Jay Bryant Bryant Communication Services (presently consulting at Synergistic Solution Technologies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
