<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
In that situation, b1 and c1, of course, but that's not the situation
that causes pain. If the image will not fit in the remaining space in
the current page AND will not fit on the space available on the new
page, then I want XEP to scale it down: <br>
<blockquote>scale-down-to-fit
<dl>
<dd>
<p>If the intrinsic content-height is less than or equal to
the height of the viewport the content-height should be the
intrinsic content-height.
Otherwise the largest scaling-factor permitted will be applied to
the content so that the scaled content-height is less than or equal
to the height of the viewport.
</p>
</dd>
</dl>
</blockquote>
Currently, if you have an image for which the width or height is too
large for the page, XEP leaves the image out, emits a warning,
and produces a pdf.<br>
<br>
Thanks,<br>
David<br>
<br>
On 3/5/2010 1:32 PM, Kevin Brown wrote:
<blockquote cite="mid:0adc01cabc9a$a2cfbff0$e86f3fd0$@com" type="cite">
<pre wrap="">OK. So I understand from the questions the actual problem and can get my
head around this for the team
... what do you wish to happen if ...
you are in a page-sequence who's available total height is 8" and you have a
7" (height) image to place and:
a) it occurs at the beginning of the page?
- this is easy I am sure ... put it here and don't scale anything
and continue flowing content
b) it occurs at exactly 1.2" on the page?
1) Put it unscaled on a new page and leave 6.8" blank?
2) Scale-it-down to fit on this page? making it 6.8" tall.
c) it occurs with exactly 1.2" left on the page?
1) Put it unscaled on a new page and leave 1.2" blank?
2) Scale-it-down to fit on this page? making it 1.2" tall.
If the answers are (b1) and (c2) then what is the point at which you change?
Or are there different answers than the two choices above ... like float to
the next page ...
Kevin
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-xep-support@renderx.com">owner-xep-support@renderx.com</a> [<a class="moz-txt-link-freetext" href="mailto:owner-xep-support@renderx.com">mailto:owner-xep-support@renderx.com</a>]
On Behalf Of Kevin Brown
Sent: Friday, March 05, 2010 10:09 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:xep-support@renderx.com">xep-support@renderx.com</a>
Subject: RE: [xep-support] Loosing content / Image scaling issue
David:
I hit send before I typed the note.
In other words. Put the image in as background (to something -- table-cell,
block-container, page itself) and use RenderX extensions for scaling set to
scale-to-fit.
This will scale-to-fit the respective container. Including scaling down or
up.
Kevin
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-xep-support@renderx.com">owner-xep-support@renderx.com</a> [<a class="moz-txt-link-freetext" href="mailto:owner-xep-support@renderx.com">mailto:owner-xep-support@renderx.com</a>]
On Behalf Of David Cramer
Sent: Friday, March 05, 2010 8:45 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:xep-support@renderx.com">xep-support@renderx.com</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">One of my regular emailers asked me to explain this further ...
</pre>
<blockquote type="cite">
<pre wrap="">Without such a distinction, no one doing publishing should be.
</pre>
</blockquote>
<pre wrap="">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"
</pre>
</blockquote>
<pre wrap="">x
</pre>
<blockquote type="cite">
<pre wrap="">2". You should apply this thought to all possibilities. If the image is
</pre>
</blockquote>
<pre wrap="">11"
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">make
</pre>
<blockquote type="cite">
<pre wrap="">the decision, and as others have posted before ... if the data doesn;t
indicate the proper hanlding then maybe the solution needs to preprocess
</pre>
</blockquote>
<pre wrap="">the
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">don't
</pre>
<blockquote type="cite">
<pre wrap="">even do this --- if I insert something too big in Word, Powerpoint, etc.
</pre>
</blockquote>
<pre wrap="">it
</pre>
<blockquote type="cite">
<pre wrap="">just goes off the page and has me resize it by hand. Precisely because I
</pre>
</blockquote>
<pre wrap="">may
</pre>
<blockquote type="cite">
<pre wrap="">want to resize appropriate to the document I am working on.
Kevin
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-xep-support@renderx.com">owner-xep-support@renderx.com</a> [<a class="moz-txt-link-freetext" href="mailto:owner-xep-support@renderx.com">mailto:owner-xep-support@renderx.com</a>]
On Behalf Of Kevin Brown
Sent: Thursday, March 04, 2010 6:27 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:xep-support@renderx.com">xep-support@renderx.com</a>
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
</pre>
</blockquote>
<pre wrap="">templates
</pre>
<blockquote type="cite">
<pre wrap="">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 --
</pre>
</blockquote>
<pre wrap="">larger
</pre>
<blockquote type="cite">
<pre wrap="">than any expected size for a page (read: 5ft by 5ft or something like
</pre>
</blockquote>
<pre wrap="">that).
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">image
</pre>
<blockquote type="cite">
<pre wrap="">(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
</pre>
</blockquote>
<pre wrap="">content.
</pre>
<blockquote type="cite">
<pre wrap="">
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: <a class="moz-txt-link-abbreviated" href="mailto:owner-xep-support@renderx.com">owner-xep-support@renderx.com</a> [<a class="moz-txt-link-freetext" href="mailto:owner-xep-support@renderx.com">mailto:owner-xep-support@renderx.com</a>]
On Behalf Of Stefan Kleineikenscheidt [k15t.com]
Sent: Tuesday, February 23, 2010 12:59 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:xep-support@renderx.com">xep-support@renderx.com</a>
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] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/xsl/">http://www.w3.org/TR/xsl/</a>
[2] <a class="moz-txt-link-freetext" href="http://services.renderx.com/lists/xep-support/6099.html">http://services.renderx.com/lists/xep-support/6099.html</a>
On Tue, Feb 9, 2010 at 8:18 PM, Tobias Anstett [k15t.com]
<a class="moz-txt-link-rfc2396E" href="mailto:tobias@k15t.com"><tobias@k15t.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">workaround?
</pre>
<blockquote type="cite">
<pre wrap="">Cheers,
Tobias
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to <a class="moz-txt-link-abbreviated" href="mailto:majordomo@renderx.com">majordomo@renderx.com</a> from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-freetext" href="http://www.renderx.com/terms-of-service.html">http://www.renderx.com/terms-of-service.html</a>
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to <a class="moz-txt-link-abbreviated" href="mailto:majordomo@renderx.com">majordomo@renderx.com</a> from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
<a class="moz-txt-link-freetext" href="http://www.renderx.com/terms-of-service.html">http://www.renderx.com/terms-of-service.html</a>
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to <a class="moz-txt-link-abbreviated" href="mailto:majordomo@renderx.com">majordomo@renderx.com</a> from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
<a class="moz-txt-link-freetext" href="http://www.renderx.com/terms-of-service.html">http://www.renderx.com/terms-of-service.html</a>
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to <a class="moz-txt-link-abbreviated" href="mailto:majordomo@renderx.com">majordomo@renderx.com</a> from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service <a class="moz-txt-link-freetext" href="http://www.renderx.com/terms-of-service.html">http://www.renderx.com/terms-of-service.html</a>
</pre>
</blockquote>
<br>
</body>
</html>