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 <[email protected]> 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 <[email protected]> > On Behalf Of Scott Prentice > > Sent: Tuesday, April 16, 2019 1:43 PM > > To: [email protected] > > 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 [email protected] > > 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 [email protected] > > > > _______________________________________________ > > > > This message is from the Framers mailing list > > > > Send messages to [email protected] > > 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 [email protected] > > > _______________________________________________ > > This message is from the Framers mailing list > > Send messages to [email protected] > 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 [email protected] _______________________________________________ This message is from the Framers mailing list Send messages to [email protected] 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 [email protected]
