[Framers] Automatic shrinkwrap?

Wed Apr 17 03:03:16 PDT 2019

Hi Rick

You wrote: "It actually happens "live"; when you scale the image, the
anchored frame shrinkwraps to the imported image. My client has created a
composite FrameMaker document from his ditamap and is formatting that for
print, including scaling images, adding some FrameMaker objects, etc"

I've just done a test with a structured binary Fm file which I generated
from a ditamap, using DITA-FMx. I had one image in an AFrame, scaled it
but... the AFrame did *not* shrinkwrap. The shrinkwrapping does happen
however, when I import a second image into the same AFrame.

To stop the skinkwrapping, you could indeed do Structure > Remove Structure
from Flow, as Scott suggested.

But I agree with Scott: all this cleanup and formatting in the *generated*
binary Fm file should not be necessary (and definitely not if you use
DITA-FMx). All these formatting changes will be lost when your customer
regenerates the Fm file from the ditamap. One of the *many* interesting
features in DITA-FMx, for example, is the ability to add the resolution of
an image as an outputclass attribute (outputclass="fmdpi:150"). When the
binary Fm file is generated, this attribute value will be applied as the
dpi value on the imported image to scale it correspondingly. Here's a
feature comparison (but Scott needs to update this list for Fm 2017 and
2019):

http://leximation.com/dita-fmx/featurecomparison.php

I think your customer needs some more DITA(+FMx) training:

https://flowtime.be/en/training/dita-fmx/

(sorry for this shameless plug ;-)   )

Cheers

Yves Barbion
www.flowtime.be

On Tue, 16 Apr 2019 at 23:58, Scott Prentice <sp14 at leximation.com> wrote:

> Rick...
>
> Yes .. would be good to be able to disable this "feature" (despite this
> not being a recommended workflow). I assume this person realizes that
> any cleanup must be repeated the next time the content is updated. I'd
> suggest trying to automate this cleanup process, since they are probably
> defeating any benefit they gain from using DITA.
>
> However, there must be a way to make FM not aware that this is a "DITA"
> file, so it stops fixing the images. There are a number of ways that FM
> could know that this is a DITA file .. probably something to do with the
> structure app that's imported into the FM file. It might be keying off
> of the structure app name, and that it matches one of the DITA apps that
> is registered in the app definition file. Could try changing it to
> something that doesn't match. Or it could be keying off of a pre-defined
> element/attribute structure at the root of the file. Try
> mangling/deleting some attributes on the root element, or renaming the
> root element. Once you figure out how FM knows to do this special
> processing, you can make a special "off-line" app that you import into
> the files after conversion to composite FM binary.
>
> Or .. as an extreme option, you could comment out the fmdita client in
> the maker.ini file. This will completely disable DITA, and should make
> this stop (although it may break other things that are useful).
>
> OR .. you could strip the structure from the file (since this is a
> one-way process anyway, maybe not such a bad idea) .. that'll do the
> trick!  :-)
>
> Good luck,
> ...scott
>
>
> On 4/16/19 12:54 PM, Rick Quatro wrote:
> > Hi Scott and Lynne,
> >
> > It actually happens "live"; when you scale the image, the anchored frame
> shrinkwraps to the imported image. My client has created a composite
> FrameMaker document from his ditamap and is formatting that for print,
> including scaling images, adding some FrameMaker objects, etc. I agree that
> this may not be the ideal workflow, but in my opinion, this should be an
> option that the user should be able to turn off. Thanks for the replies.
> >
> > Rick
> >
> > -----Original Message-----
> > From: Framers <framers-bounces+rick=rickquatro.com at lists.frameusers.com>
> On Behalf Of Scott Prentice
> > Sent: Tuesday, April 16, 2019 1:43 PM
> > To: framers at lists.frameusers.com
> > Subject: Re: [Framers] Automatic shrinkwrap?
> >
> > Hi Lynne...
> >
> > Nope .. anything other than a referenced image will be ignored. DITA
> doesn't support "graphic objects" and knows noting about a "frame" so those
> bits are not considered valid. Could try pasting from another file, but I'd
> bet it won't work. This isn't how the structure app (and DITA support) was
> intended to be used, so it's not supported.
> >
> > Rick ..
> >
> > I'm not exactly sure where this processing is done and how FM knows that
> the file is "DITA". If this processing is done "on save" then it's likely
> the import/export client. I think that FMx knows when you're in a binary
> file vs. XML and allows this flexibility in the binary file (would need to
> test to be sure).
> >
> > If the customer wants to work in a DITA structured model in an FM binary
> file, I would create a new structure app that doesn't use the ditafm_app
> import/export client. That's not needed if they are sticking in the binary
> world, and may eliminate this processing.
> >
> > Cheers,
> > ...scott
> >
> >
> > On 4/16/19 10:26 AM, Lynne A. Price wrote:
> >> Scott,
> >>     What happens if you put a rectangle of the desired aframe size with
> >> no border and no fill in the anchored frame? Will that hold the
> >> desired space? Also, can you create the aframe with all desired
> >> objects in another document and paste it where it's needed?
> >>      --Lynne
> >>
> >> On 4/16/2019 10:09 AM, Scott Prentice wrote:
> >>> While it would seem that you can use DITA as the model for a
> >>> structured FM binary file, it's really not a good idea. There are a
> >>> handful of areas (like this) that it's assuming you're working in
> >>> XML, and will cause trouble. All I can suggest is that if you do want
> >>> to put multiple objects in the frame, make sure that the first object
> >>> is a referenced image and that image is large enough (extra white
> >>> space) to accommodate all of the expected content. That way the
> >>> auto-shrinkwrap will size to that image, and *should* work reasonably.
> >>
> > _______________________________________________
> >
> > This message is from the Framers mailing list
> >
> > Send messages to framers at lists.frameusers.com
> > Visit the list's homepage at  http://www.frameusers.com
> > Archives located at
> http://www.mail-archive.com/framers%40lists.frameusers.com/
> > Subscribe and unsubscribe at
> http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
> > Send administrative questions to listadmin at frameusers.com
> >
> > _______________________________________________
> >
> > This message is from the Framers mailing list
> >
> > Send messages to framers at lists.frameusers.com
> > Visit the list's homepage at  http://www.frameusers.com
> > Archives located at
> http://www.mail-archive.com/framers%40lists.frameusers.com/
> > Subscribe and unsubscribe at
> http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
> > Send administrative questions to listadmin at frameusers.com
> >
> _______________________________________________
>
> This message is from the Framers mailing list
>
> Send messages to framers at lists.frameusers.com
> Visit the list's homepage at  http://www.frameusers.com
> Archives located at
> http://www.mail-archive.com/framers%40lists.frameusers.com/
> Subscribe and unsubscribe at
> http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
> Send administrative questions to listadmin at frameusers.com