You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by JB...@s-s-t.com on 2005/12/09 23:19:29 UTC
0.90alpha1: content-width="scale-to-fit" creates damaged PDF
I wrote an extension function in Java for Saxon that gives me the width
(and height, but that's less relevant) of an image. Then, if the width is
greater than 5.5 inches (the space I have available for screen shots in
this document format), the XSLT adds the content-width="scale-to-fit"
attribute to the external-graphic instruction, thus:
<fo:external-graphic src="{@source}" content-width="scale-to-fit">
<xsl:if test="ext:getImageWidth(@source) > 528">
<!-- 528 = 5.5 inches at 96 dpi -->
<xsl:attribute name="content-width" select="'scale-to-fit'"/>
</xsl:if>
</fo:external-graphic>
That all works fine and produces lines such as the following:
<fo:external-graphic src="login.gif" content-width="scale-to-fit">
But when I run FOP against the resulting FO file, I get the following
error message:
java.lang.RuntimeException: Some content could not fit into a line/page
after 50
attempts. Giving up to avoid an endless loop.
I also get a PDF file that is "damaged and could not be repaired."
I've tested the extension function on several images by having it print
the width in xsl:message instructions, so I know that works. Also, the
transform is properly creating external-graphic instructions with
content-width="scale-to-fit" attributes. So I'm a bit stumped at this
point.
Any idea why <fo:external-graphic src="login.gif"
content-width="scale-to-fit"> makes a PDF file that goes boom?
Thanks.
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
(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">
> <value>auto</value>
> <value>scale-to-fit</value>
> <value>16.51cm</value>
> <value>165.1mm</value>
> <value>6.5in</value>
> <value>468pt</value>
> <value>39pc</value>
> <value>468px</value>
> <value>100%</value>
> </test>
> <test name="content-height">
> <value>auto</value>
> <value>scale-to-fit</value>
> <value>16.51cm</value>
> <value>165.1mm</value>
> <value>6.5in</value>
> <value>468pt</value>
> <value>39pc</value>
> <value>468px</value>
> <value>100%</value>
> </test>
> <test name="height">
> <value>auto</value>
> <value>16.51cm</value>
> <value>165.1mm</value>
> <value>6.5in</value>
> <value>468pt</value>
> <value>39pc</value>
> <value>468px</value>
> <value>100%</value>
> </test>
> <test name="width">
> <value>auto</value>
> <value>16.51cm</value>
> <value>165.1mm</value>
> <value>6.5in</value>
> <value>468pt</value>
> <value>39pc</value>
> <value>468px</value>
> <value>100%</value>
> </test>
> <test name="image-type">
> <value>gif</value>
> <value>jpg</value>
> </test>
> <test name="image-name">
> <value>tooNarrowGraphic</value>
> <value>tooWideGraphic</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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by JB...@s-s-t.com.
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">
<value>auto</value>
<value>scale-to-fit</value>
<value>16.51cm</value>
<value>165.1mm</value>
<value>6.5in</value>
<value>468pt</value>
<value>39pc</value>
<value>468px</value>
<value>100%</value>
</test>
<test name="content-height">
<value>auto</value>
<value>scale-to-fit</value>
<value>16.51cm</value>
<value>165.1mm</value>
<value>6.5in</value>
<value>468pt</value>
<value>39pc</value>
<value>468px</value>
<value>100%</value>
</test>
<test name="height">
<value>auto</value>
<value>16.51cm</value>
<value>165.1mm</value>
<value>6.5in</value>
<value>468pt</value>
<value>39pc</value>
<value>468px</value>
<value>100%</value>
</test>
<test name="width">
<value>auto</value>
<value>16.51cm</value>
<value>165.1mm</value>
<value>6.5in</value>
<value>468pt</value>
<value>39pc</value>
<value>468px</value>
<value>100%</value>
</test>
<test name="image-type">
<value>gif</value>
<value>jpg</value>
</test>
<test name="image-name">
<value>tooNarrowGraphic</value>
<value>tooWideGraphic</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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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" <a_...@pandora.be>
> To: <fo...@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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by Jay Bryant <ja...@bryantcs.com>.
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" <a_...@pandora.be>
To: <fo...@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: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by Andreas L Delmelle <a_...@pandora.be>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 10, 2005, at 20:56, Andreas L Delmelle wrote:
> On the contrary, it is working almost perfectly,
I take that back...
While running a few tests trying to help Dirk Bromberg (see his
thread of today), I tried
<fo:external-graphic src="..."
width="auto" content-width="auto"
height="auto" content-height="scale-to-fit"
scaling="non-uniform" />
and
<fo:external-graphic src="..."
width="auto" content-width="auto"
height="2.9cm" content-height="scale-to-fit"
scaling="non-uniform" />
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 10, 2005, at 00:14, JBryant@s-s-t.com 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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF - workaround found
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 11, 2005, at 00:50, Jay Bryant wrote:
>> Have you tried adding width="..." to the fo:external-graphic? Works
>> fine for me.
>
> Yup. Tried that. It didn't work with images wider than the content
> area (at
> least not with inches as the unit of measure). It DID make images
> smaller
> than the content area fill more of the content area (again with
> units of
> measure = inches).
Hmm.. I wonder if this depends on the image format. It just occurred
to me that your tests use GIF, while I was using JPG. Another detail
to consider.
> My solution entails reading the width of the graphic (in pixels)
> through a
> Java extension to the XSL processor (Saxon). Then, if the image is
> less than
> 396 pixels wide, I just put it in (with <fo:external-graphic
> src="someimage.gif"/>. Else, if the image is more than 396 pixels
> wide, I
> force its width to be 396 pixels (with <fo:external-graphic
> src="someimage.gif" content-width="396px"/>). So, I'm trying to
> force the
> width only in the case where the graphic exceeds the available
> space. It was
> faster to write an extension function (took 15 minutes or so) than
> to try to
> scale all my screen captures.
Aaah, OK, now I get you.
> Thanks for looking into things.
>
You're welcome, of course.
And thanks to you for the feedback!
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF - workaround found
Posted by Jay Bryant <ja...@bryantcs.com>.
Hi, Andreas,
I'll respond below:
----- Original Message -----
From: "Andreas L Delmelle" <a_...@pandora.be>
To: <fo...@xmlgraphics.apache.org>
Sent: Saturday, December 10, 2005 1:37 PM
Subject: Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF -
workaround found
> On Dec 10, 2005, at 00:34, JBryant@s-s-t.com 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...
At that point, I was just testing in general rather than continuing to chase
what I needed. So I was trying to force both images that are smaller than
the content area and images that are larger than the content area to fit the
content area. Then I was trying to get both smaller and larger images to be
a particular size (5.5in). What I found is that I can specify the width in
pixels but not inches and that scale-to-fit does not work for images larger
than the content area. Sorry about the confusion.
>
> > 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.
Yup. Tried that. It didn't work with images wider than the content area (at
least not with inches as the unit of measure). It DID make images smaller
than the content area fill more of the content area (again with units of
measure = inches).
>
> 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?
My solution entails reading the width of the graphic (in pixels) through a
Java extension to the XSL processor (Saxon). Then, if the image is less than
396 pixels wide, I just put it in (with <fo:external-graphic
src="someimage.gif"/>. Else, if the image is more than 396 pixels wide, I
force its width to be 396 pixels (with <fo:external-graphic
src="someimage.gif" content-width="396px"/>). So, I'm trying to force the
width only in the case where the graphic exceeds the available space. It was
faster to write an extension function (took 15 minutes or so) than to try to
scale all my screen captures.
Thanks for looking into things.
>
> Cheers,
>
> Andreas
Jay Bryant
Bryant Communication Services
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF - workaround found
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 10, 2005, at 00:34, JBryant@s-s-t.com 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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF -
workaround found
Posted by JB...@s-s-t.com.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by JB...@s-s-t.com.
Hi, Andreas,
> Try 396 (= 5.5in at 72dpi), unless you're overriding the
> default resolution of course...
Yup. I caught that right after I posted that message. I used to use 96 dpi
screen captures (at a previous job), but I use 72 dpi these days.
> 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
<fo:external-graphic src="someimage.gif" content-width="scale-to-fit"/>
When FOP hits that line, whether the image's actual width is 2 pixels or
2000 pixels, it should be scaled to fit the available space, right? (Of
course, I'd have a bug somewhere on my side if I thought an image with two
pixels was more than 396 pixels wide, but that's a separate problem.)
Also, I have tried simply setting all the images to
content-width="scale-to-fit" with the following line:
<fo:external-graphic src="{@source}" content-width="scale-to-fit"/>
It still goes boom.
I have done some additional testing by setting
content-width="scale-to-fit" on images that are much smaller than the
available area. In those cases, FOP doesn't produce the error and does
produce a working PDF file, but it also does NOT scale the image to fill
the area. 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.
At this point, I suspect that content-width="scale-to-fit" is not working
correctly.
If you or any of the other developers would like to look into this issue,
I can provide test files (both FO files and images that cause problems).
Thanks.
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 9, 2005, at 23:19, JBryant@s-s-t.com wrote:
Hi Jay,
> I wrote an extension function in Java for Saxon that gives me the
> width
> (and height, but that's less relevant) of an image. Then, if the
> width is
> greater than 5.5 inches (the space I have available for screen
> shots in
> this document format), the XSLT adds the content-width="scale-to-fit"
> attribute to the external-graphic instruction, thus:
>
> <fo:external-graphic src="{@source}" content-width="scale-to-
> fit">
> <xsl:if test="ext:getImageWidth(@source) > 528">
> <!-- 528 = 5.5 inches at 96 dpi -->
Try 396 (= 5.5in at 72dpi), unless you're overriding the default
resolution of course...
> <xsl:attribute name="content-width" select="'scale-to-
> fit'"/>
> </xsl:if>
> </fo:external-graphic>
>
> That all works fine and produces lines such as the following:
>
> <fo:external-graphic src="login.gif" content-width="scale-to-fit">
>
> But when I run FOP against the resulting FO file, I get the following
> error message:
>
> java.lang.RuntimeException: Some content could not fit into a line/
> page
> after 50
> attempts. Giving up to avoid an endless loop.
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 also get a PDF file that is "damaged and could not be repaired."
>
> I've tested the extension function on several images by having it
> print
> the width in xsl:message instructions, so I know that works. Also, the
> transform is properly creating external-graphic instructions with
> content-width="scale-to-fit" attributes. So I'm a bit stumped at this
> point.
>
> Any idea why <fo:external-graphic src="login.gif"
> content-width="scale-to-fit"> makes a PDF file that goes boom?
Most logical explanation would be that the file isn't finished due to
the RuntimeException (?)
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org