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

Ok, that's interesting, but would still be some effort to work into my
build scripts and would add processing overhead and complexity. Also,
every xep customer has to redo the work of adding what is basically a
hack into their build scripts when there's a feature that would handle
it easily for all users that is:

   1. In the spec.
   2. Important to a reasonable subset of your customers,
   3. Implemented in both
          * the open source alternative:
            http://xmlgraphics.apache.org/fop/0.95/releaseNotes_0.95beta.html
            , see "Major Changes in Version 0.95beta...Added support for
            scale-down-to-fit and scale-up-to-fit (introduced in XSL
            1.1). Committed by JM." AND
          * the competing commercial renderer, Antenna House,
            http://www.antennahouse.com/xslfo/xsl1.1-testsuite.html (see
            Graphic Scaling, graphic-scaling-01.pdf
            <http://www.antennahouse.com/xslfo/results/graphic-scaling-01.pdf>),
            and
   4. Apparently something that XEP can easily do already (i.e. the
      renderer has all the information it needs to do the right thing).

Thanks,
David

>> 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
>

-------------------
(*) 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 20:02:40 2010