[Framers] Automatic shrinkwrap?

Tue Apr 16 14:58:14 PDT 2019

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
>