> You mentioned that I could use another application to look at the image
and determine it's size and then adjust the scaling. That would be a lot of
work and hard to fit into an xslt workflow
Just a comment on this one.
1) Create a simple XSL that just processes all images, no scaling, set page
dimensions to something like 200in x 200in. Use RenderX to output XEP
Intermediate Format. You can obtain such a file using "-xep" as the output
format.
The output file would look like this:
<?xml version="1.0" encoding="UTF-8"?>
<xep:document xmlns:xep="http://www.renderx.com/XEP/xep" producer="XEP
CURRENT build 20100226" creator="Unknown" author="Unknown" title="Untitled">
<xep:page width="7200000" height="7200000" page-number="1" page-id="1">
<xep:gray-color gray="0.0"/>
<xep:image
src="file:/C:/Users/kbrown01/Desktop/Scale-to-fit/product_goodflakes.gif"
type="image/gif" x-from="0" y-from="6835800" scale-x="1.0" scale-y="1.0"
width="225600" height="364200" role="none"/>
<xep:image
src="file:/C:/Users/kbrown01/Desktop/Scale-to-fit/big-peng_00001.jpg"
type="image/jpeg" x-from="0" y-from="4499800" scale-x="1.0" scale-y="1.0"
width="2336000" height="2336000" role="none"/>
<xep:image src="file:/C:/Users/kbrown01/Desktop/Scale-to-fit/4morpap0.png"
type="image/png" x-from="0" y-from="3574061" scale-x="1.0" scale-y="1.0"
width="1068028" height="925739" role="none"/>
<xep:image src="file:/C:/Users/kbrown01/Desktop/Scale-to-fit/duck.svg"
type="image/svg+xml" x-from="0" y-from="2974061" scale-x="1.0" scale-y="1.0"
width="720000" height="600000" role="none"/>
</xep:page>
</xep:document>
You would have an XML file that has the complete picture ...
Image: file:/C:/Users/kbrown01/Desktop/Scale-to-fit/product_goodflakes.gif
width: 225600 (which is 225.600 pts)
height: 364200 (which is 364.200 pts)
...
2) Use that XML file in a document() lookup to get every exact image
dimension in your main XSL
Kevin
From: David Cramer [mailto:david@thingbag.net]
Sent: Friday, March 05, 2010 10:41 AM
To: kevin@renderx.com
Subject: Re: [xep-support] Loosing content / Image scaling issue
No, but it shows how easily xep could do what I want. The problem with that
solution (as I understand it) is that it scales the image up if it is too
small for the page. I want to scale it down only if it is too big to fit.
Scaling bitmaps up reduces quality, so I never want to do that. Also, if the
image fits anyway and leaves extra space, I want to use that space for text.
The person creating the source document doesn't know ahead of time that the
image is going to be too big for the page size that the stylesheet writer
chooses (a choice that is independent of authoring). As a stylesheet writer,
I would write my xslt so that all images have scale-down-to-fit if not size
is specified or if one of the dimensions specified is too big for the chosen
page size (that's all easy to do in the xslt).
When you said "Scaling to fit in both directions (whichever fits best) is
only a solution for images slightly wider then high OR slightly higher than
wide" that is exactly the situation we often have and exactly the situation
that often comes up for Stefan's users. That is our pain point. I believe
Bob Stayton also asked about this feature (and he deals with clients who
have the same use cases I do).
What xep does now when an image won't fit makes no sense at all. It throws
away the image and emits a non-fatal warning. You example shows that
internally, XEP can already scale the image down to fit with no problem. But
the best thing would be to implement the scale-down-to-fit attribute in the
spec. You mentioned that I could use another application to look at the
image and determine it's size and then adjust the scaling. That would be a
lot of work and hard to fit into an xslt workflow, especially when there's a
perfectly good solution in the spec. The reason I use a commercial renderer
in the first place is that it saves me the effort of coming up with weird
hacks to compensate for parts of the spec that aren't implemented.
Thanks,
David
On 3/5/2010 12:05 PM, Kevin Brown wrote:
I sent an email to xep-support also ...
This will not work? see attached.
-----Original Message-----
From: owner-xep-support@renderx.com [mailto:owner-xep-support@renderx.com]
On Behalf Of David Cramer
Sent: Friday, March 05, 2010 8:45 AM
To: xep-support@renderx.com
Subject: Re: [xep-support] Loosing content / Image scaling issue
Hi Kevin,
First, I'll establish that I'm no talking about inline images, so
there's no need to kick me out of the field of publishing :-)
For the technical documentation use case, the ONLY reason we still
deliver pdfs (and so the ONLY reason we've purchased XEP) is so that our
users can print our documentation on the US Letter or A4 paper that is
in their printers. Our primary output is html but people still like to
have the option to print portions of the documentation. Printing from
html, even with fancy css doesn't produce acceptable results. So it's
impressive that XEP can produce a pdf with different page sizes, but the
resulting pdfs would be useless to me and the users of my documents.
Of course if the image is only legible at 2" x 42" or 42" x 2" it's
going to be a blob if you scale it to fix an 8.5" x 11" page. In fact,
it would be unusable viewing online whether viewed in a browser or
Acrobat. What you have there is a poster and we sometimes use those for
ER diagrams and such, but that's not the situation we're talking about here.
Say you have an image that's 2" x 11" but still looks ok when scaled to
9" high or even 7" high. Images like that do exist. Right now, we have
to set our contentheight (DocBook) attribute to 9". This is used as the
content-height attribute in the xsl-fo and XEP sets the content-width
proportionally and things are fine on US Letter and A4. That alone is an
unnecessary manual step that we have to explain to our writers. But
what if we give this document to a partner and they render it xslts
according to their company style which use a 7" x 9" page size? If they
use XEP, the image quietly disappears from the page without even an easy
way to have it break the build or any indication on the page that
content was dropped! What I want to do is say "scale this image to fit
the page" and have XEP do the best it can. Sure, if the space is too
small, the result will be illegible, but I frequently have images that I
would like to be as big as they can be for a given page size. Leave it
to me and my writers to use our judgment regarding whether the content
will fit in the range of pages sizes likely to be used for the document.
We already do that for text in table cells.
For use cases where the content comes from a source like a wiki,
scale-down-to-fit is even more important. The person who created the
wiki page may have no idea that the page will someday become a pdf. If
the fo renderer can scale a large image down to fit the page size,
though, most of the time this will turn out ok.
If you support scale-down-to-fit, I would definitely renew our
maintenance to get it. Without it, I don't have much reason to.
Thanks,
David
On 3/4/2010 9:29 PM, Kevin Brown wrote:
One of my regular emailers asked me to explain this further ...
Without such a distinction, no one doing publishing should be.
What I meant by that is that you cannot tell me that you wish to create a
generic layout that handles an image 2" x 42" the same as one that is 42"
x
2". You should apply this thought to all possibilities. If the image is
11"
x 8.5" you probably want to handle it differently than 8.5" x 11" and you
should not believe scaling to fit in both directions (whichever fits best)
is the right solution for all things. It is highly likely NOT what anyone
wants.
The data needs to indicate what you want to do and if it does, there is no
need for scaling to fit in both directions. You have the opportunity to
make
the decision, and as others have posted before ... if the data doesn;t
indicate the proper hanlding then maybe the solution needs to preprocess
the
data to apply this information to the data (like have an application that
reads images and adds sizes to the metadata about the images).
Scaling to fit in both directions (whichever fits best) is only a solution
for images slightly wider then high OR slightly higher than wide ... It is
certainly NOT a general solution for any real implementation and is of no
high priority importance for us to implement. Most applications I know
don't
even do this --- if I insert something too big in Word, Powerpoint, etc.
it
just goes off the page and has me resize it by hand. Precisely because I
may
want to resize appropriate to the document I am working on.
Kevin
-----Original Message-----
From: owner-xep-support@renderx.com [mailto:owner-xep-support@renderx.com]
On Behalf Of Kevin Brown
Sent: Thursday, March 04, 2010 6:27 PM
To: xep-support@renderx.com
Subject: RE: [xep-support] Loosing content / Image scaling issue
We solved this differently for a recent project. We did solve it this way
because no one cares about the "size" of a page PDF. It is not relevant to
what was trying to be accomplished.
What likely is different is that there is a distinction in the inline
content about:
1) What is an inline image and
2) What is an image that should take a full page (Or more but that is
irrelevant)
Without such a distinction, no one doing publishing should be. You need to
know this before figuring out how to create *real* published pages. As in,
you should have some notion about how to layout a page within your
templates
and full-page or very large images should be marked differently than a
half-page or a small inline graphic.
For our solution, we process those very large images into a separate page
sequence. This page sequence is set to very large page dimensions --
larger
than any expected size for a page (read: 5ft by 5ft or something like
that).
We process this to intermediate format and in that intermediate format we
read actual dimensions and then automatically trim the page dimensions to
match that size. This done server side through post processing the
intermediate format and because it is manipulation of XML results in 0.001
secs additional processing time.
We then format the document to PDF.
The result is a PDF with (or course) mixed page dimensions. That huge
image
(and in our case the 42 column, 768 row table) is on a single page in the
PDF. The end user's PDF viewer supports the panning and zooming needed to
see the whole thing or zoom in. The page is not trying to be predictive to
fit some pre-conceived notion of size, the size expands to fit the
content.
If you are not delivering print materials and you are delivering PDF then
this is a much better solution.
Kevin Brown
RenderX
-----Original Message-----
From: owner-xep-support@renderx.com [mailto:owner-xep-support@renderx.com]
On Behalf Of Stefan Kleineikenscheidt [k15t.com]
Sent: Tuesday, February 23, 2010 12:59 PM
To: xep-support@renderx.com
Subject: Re: [xep-support] Loosing content / Image scaling issue
Hi all,
I work with Tobias and we have tried various workaround, but it seems
that this can only properly fixed with support for "scale-down-to-fit"
as defined by XSL 1.1 [1]. We do know that this is XSL 1.1 and XEP is
only supporting 1.0 officially, however it is still hard for us to
explain to customers why we are losing content.
I noticed that this has been already a topic on this list [2] and I
wonder whether RenderX is planning to implement this anytime soon?
-Stefan
[1] http://www.w3.org/TR/xsl/
[2] http://services.renderx.com/lists/xep-support/6099.html
On Tue, Feb 9, 2010 at 8:18 PM, Tobias Anstett [k15t.com]
<tobias@k15t.com> wrote:
Hi,
we recently noticed that in some situations XEP drops images.
The problem occurs sometimes when exporting very big pictures which
need to be resized. Therefore we use the scale-to-fit property to
scale the image with respect to its width as illustrated below:
<fo:external-graphic
src="url(picture.jpg)"
width="100%"
height="auto"
content-width="scale-to-fit"
content-height="100%"/>
This works fine in most of the cases. However, if the height of the
image is still to big to get rendered properly to the page after it
was already resized, XEP drops the image with the following error:
[core.export.impl.XepExporter$XepLogger] error no space for an
element, trying to recover.
For us, loosing information is a very big issue. Is there any known
workaround?
Cheers,
Tobias
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
http://www.renderx.com/terms-of-service.html
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
http://www.renderx.com/terms-of-service.html
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html
Received on Fri Mar 5 16:02:14 2010
This archive was generated by hypermail 2.1.8 : Fri Mar 05 2010 - 16:02:22 PST