[xep-support] Loosing content / Image scaling issue
Kevin Brown
kevin at renderx.com
Fri Mar 5 11:32:42 PST 2010
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: owner-xep-support at renderx.com [mailto:owner-xep-support at renderx.com]
On Behalf Of Kevin Brown
Sent: Friday, March 05, 2010 10:09 AM
To: xep-support at renderx.com
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: owner-xep-support at renderx.com [mailto:owner-xep-support at renderx.com]
On Behalf Of David Cramer
Sent: Friday, March 05, 2010 8:45 AM
To: xep-support at 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 at renderx.com [mailto:owner-xep-support at renderx.com]
> On Behalf Of Kevin Brown
> Sent: Thursday, March 04, 2010 6:27 PM
> To: xep-support at 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 at renderx.com [mailto:owner-xep-support at renderx.com]
> On Behalf Of Stefan Kleineikenscheidt [k15t.com]
> Sent: Tuesday, February 23, 2010 12:59 PM
> To: xep-support at 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 at 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 at 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 at 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 at 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 at 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
More information about the Xep-support
mailing list