Hi Bernard
Thanks for ultra-rapid and comprehensive response, and Yves Barbion, Paul
Wilbraham and John Posada too. Structure doesn't seem quite so scary with you
guys around ;-)
>I think the big issue is to know what the structure of this is. For example,
>do you have something like:
>
><Fig>
><FigTitle>Widget Illustration</FigTitle>
><FigImage attributes="many" />
></Fig>
>
>In which case you can format the FigTitle as you see fit. However, the
>FigImage may appear weird (at first) if you then Esc m p the thing (hope that
>makes sense). I take the EDD and change FigTitle to have a suffix of \r to
>force a line break after the caption...
>
>If you simply have this:
>
><Fig>
><FigImage attributes="many" />
></Fig>
>
>The it gets a bit more tricky. Can't come up with a functional solution right
>away, but I'm sure it's out there. Can you email more info with the 'rules'
>you associate with the figure that you are working with?
Well, the slate's bare at present, as I am writing the EDD from scratch. I am
also considering structured FrameMaker only as a writing tool, but if content
is to be imported, it will currently be based on a hacked version of DocBook.
This seems to create titled figures as:
Figure title<frameanchor>ΒΆ
[anchored frame]
I don't at present know how that would map to XML - and I've got enough to
worry about just creating the EDD ;-)
>Having the text frame inside the anchored frame is a real headache (my opinion)
...ok, that's good enough for me ;-) Others agree with you (no surprises there).
> and I strongly suggest busting them out.
[Done]
> If you have a lot of them, you could do so by using a FrameScript (right
> Rick?).
FrameScript isn't an option here: client doesn't want the complexity.
> You can use the keep with next/prev features to ensure the caption and image
> stay together.
Sorry: which 'next/prev' features are you referring to? The para-tag level
ones, whether implemented in a tag or an element definition, won't keep a para
and an anchored frame together, surely, if the frame is floated? Paul Wilbraham
also suggested this ('You can then apply keep with next/previous to the Figure
and Title elements in the EDD to keep these elements together.'), but I'm
baffled.
Maybe what you and others are suggesting is pairing the figure's title, with
'keep with next' set on, with a dummy para to contain the anchored frame's
anchor? Ok, yes, I get that: I'm doing that elsewhere in this template. But if
the anchored frame's *anchor* is actually in the figure title (in this design
the figure's title is always above the figure), then the title and the anchored
frame will stay together unless the anchored frame is floated: there's no need
for a 'keep with next', surely?
> Finally, a single cell table with a title above/below would also do the trick
> and give you cleaner XML.
Yes, Yves Barbion suggested this approach too. I'm using 'non-tables' to model
other complex elements in the client's design, but FrameMaker's built-in table
title support won't work here because of other design aspects, such as some
colored pages.
>Feel free to email me a sample file (off list) and I can review it quickly.
Thanks, and also to Yves B, Paul Wilbraham and John P. The consensus is that
using text boxes in anchored frames is bad juju in structure, which was what I
suspected. Onward with the learning process...
--
Steve
_______________________________________________
You are currently subscribed to Framers as [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [EMAIL PROTECTED] Visit
http://www.frameusers.com/ for more resources and info.
