Re: [xep-support] Loosing content / Image scaling issue

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:

    scale-down-to-fit

        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.

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.

Thanks,
David

On 3/5/2010 1:32 PM, Kevin Brown wrote:
> 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@renderx.com [mailto:owner-xep-support@renderx.com]
> On Behalf Of Kevin Brown
> Sent: Friday, March 05, 2010 10:09 AM
> To: xep-support@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@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
>
> -------------------
> (*) 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 13:46:52 2010