xep-support: RE: [xep-support] Loosing content / Image scaling i

From: Kevin Brown <kevin@renderx.com>
Date: Thu Mar 04 2010 - 19:29:33 PST

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

This archive was generated by hypermail 2.1.8 : Thu Mar 04 2010 - 19:56:44 PST