FOSI when is a topfloat not at the top?

[ptc-953343]

In general I have the floats working on my figures but there are a couple
odd things I am puzzled over. I have my float with the following settings:

<floatloc floatid="figfloat" floattyp="once" maxdepth="6in"&lt;br"/>minspace="13pt" nomspace="13pt" maxspace="13pt">


<rectopg bind="lleft" chgmkplc="pright" xvjstretch="max"&lt;br"/>topfloat="table-title.top figfloat" >

<float flidref="figfloat" width="page" scope="chapter" pagetype="afterref">

I have a situation where the figure is less than a page height but there
is no more content on the page for one reason or another. In one case the
figure is more or less centered on the page - it takes maybe 3/4 of the
space. In another situation the figure is place at the bottom of the page.
In this last case the figure only occupies less than 1/4.

In the last case I'm playing with the sizing attributes on the graphic tag
as it was setting too large. I've now shrunk it to a very small size and
it is placed at the botom of thee page and there is content following
(additional paras) that could be filled in below the figure if it was
placed at the top of the page.

I had one last situation where a figure started at the bottom of the page
but overfills it by at least a hlf page. I've checked all the keeps and
such of the content before andafter it and I see nothing that is forcing
it on that page. Why doesn't the float move it? The only way I've been
able to fix this is to put additional text before or after it (more paras
- same as what was there). This is just a test document so I can do this,
but it isn't a good production solution. Also I don't want to use the
formatting PIs

..dan

[ptc-953343]

In playing around I duplicated the graphic that was producing too large
and not floating. I placed a second copy down into another section and
several paras away to see if it would float properly. When composed the
first page is still too long, but now it is also trying to bring in the
second instance within the same float so it is EXTRA overrun. The two
figures are produced one after the other with no text between them. It is
like the second instance floated forward instead of next.

..dan


> In general I have the floats working on my figures but there are a couple
> odd things I am puzzled over. I have my float with the following settings:
>
> <floatloc floatid="figfloat" floattyp="once" maxdepth="6in"&lt;br"/>> minspace="13pt" nomspace="13pt" maxspace="13pt">
>
>
> <rectopg bind="lleft" chgmkplc="pright" xvjstretch="max"&lt;br"/>> topfloat="table-title.top figfloat" >
>
> <float flidref="figfloat" width="page" scope="chapter"&lt;br"/>> pagetype="afterref">
>
> I have a situation where the figure is less than a page height but there
> is no more content on the page for one reason or another. In one case the
> figure is more or less centered on the page - it takes maybe 3/4 of the
> space. In another situation the figure is place at the bottom of the page.
> In this last case the figure only occupies less than 1/4.
>
> In the last case I'm playing with the sizing attributes on the graphic tag
> as it was setting too large. I've now shrunk it to a very small size and
> it is placed at the botom of thee page and there is content following
> (additional paras) that could be filled in below the figure if it was
> placed at the top of the page.
>
> I had one last situation where a figure started at the bottom of the page
> but overfills it by at least a hlf page. I've checked all the keeps and
> such of the content before andafter it and I see nothing that is forcing
> it on that page. Why doesn't the float move it? The only way I've been
> able to fix this is to put additional text before or after it (more paras
> - same as what was there). This is just a test document so I can do this,
> but it isn't a good production solution. Also I don't want to use the
> formatting PIs
>
> ..dan
>

[GarethOakes]

Hi Dan,

In my experience, the FOSI floats in Arbortext are not quite bulletproof...
I had some weird issues, sounds similar to what you're seeing, and had to
work it out via PTC Support.

It turned out that what I was trying to do was basically not supported, so
we were screwed anyway, but we also uncovered some bugs along the way.

Examples:
- If you floated something that was also rotated then sometimes the rotation
would apply to later floats even though they were not at all related to the
original rotated thing! I think this is now fixed on recent 5.3 and 5.4.
- If you encounter say 5 or 6 references to floats on a given page then
there is no way to get Arbortext to correctly float them on the subsequent
pages. The floats system will basically drop those floats into the document
wherever it feels like it. The 6th float in my example could appear like 20
pages away from its original reference. Using pagetype="nextpage" can force
them to all appear on the subsequent pages but then Arbortext won't run the
main text around those floats, i.e. it delays the main text until all 6
floats are placed.

So, the floats can get tricky. That @pagetype attribute in particular has a
big bearing on what scheme Arbortext uses to place the floats. It's also
worth noting that the floats work with the variable spacing stuff, so
sometimes loosening up your spacing (eg. allowing bigger min/max variance)
allows the floats to place better.

If you end up banging your head against a wall (like I did) you should try
and get a test case to PTC Support and see if they can help.

Cheers,
Gareth

[ptc-953343]

Thanks I don't have any of the conditions you mention except for many
references together, but I do think I'm seeing some flaky results.
I'm testing right now so many of these graphics are the same filling
about a half page. I went through my 400 page sample and I had the
same image clear the page it was placed on (do to lots of figures
together) but a bunch would go to the bottom of the page and then in
another chapter the same string would go where I expected at the top
of the page.

I also found a dozen or so instances where the figure was started
within the last inch of the page and then overflows, in a couple of
cases it pulled a figure forward and overflowed content with 2 figures.

I did open the call and sent in an app save, I'll let you know what
the results are.

So what did you do to solve your problems?

..dan

[GarethOakes]

Hi Dan,

Yes, interested to learn more about this if you find out some good details
...

Our customer's problem was never properly solved. They have resigned
themselves to paging through every chapter they produce and manually move
the float reference tags around until the floats look right. That can often
take quite a few reformats and cursing to get right 😉

So, they weren't too happy about that, but we'll probably move them to an
APP (3B2) system in the not too distant future. That should fix their
floats! 🙂

Cheers,
Gareth

[ptc-953343]

> Hi Dan,
>
> Yes, interested to learn more about this if you find out some good details
> ...
>
> Our customer's problem was never properly solved. They have resigned
> themselves to paging through every chapter they produce and manually move
> the float reference tags around until the floats look right. That can
> often
> take quite a few reformats and cursing to get right 😉

Interesting, I was working for a different company that was using FOSIs.
The FOSI was maintained by someone else. I noticed that there were no
floats and when I asked them about it, they said they used the touchup
commands and moved the references around. I thought it was because they
just didn't figure out how to make them work - now I may know why.

I do get some different results with different runs. It seems like Print
Composer will detect the size of the graphic, draw the box but then the
actual image will be about 3/4 the size it should be. This happens after I
run the same document several times, seems to correct if I shut down and
restart.

>
> So, they weren't too happy about that, but we'll probably move them to an
> APP (3B2) system in the not too distant future. That should fix their
> floats! 🙂

I had some experience with 3B2 and it seemed like a good product. I wasn't
dealing with tech manuals and graphics though. Certainly gives you moe
control and the abilty to tweak the final page content before committing
to print or PDF looks cool if you need that level of control. That would
fix this problem - at least be a workaround.

..dan

>
> Cheers,
> Gareth
>

[ptc-953343]

In Reply to Gareth Oakes:

>> So my problems turned out to be a bug in the 5.2 f000 version I was using. By switcing to 5.2 m130 my floats are now working properly. I have a couple more issues that I'm trying to work out.

1) I have a situation where a table breaks and floats to the top and a figure also floats to the top of that page. Im getting the following:

Table 3-2 title (continued)

graphic

Figure 3-90 title

content of the table that flows to this page

2) when 2 half page graphics (multiple sheets set with subfig) land on the same page (grphics boxed) I get:

graphic sheet 1

top box line of grphic sheet 2

Figure 3-1 sheet 1 of 2

end of graphic 2

Figure 3-2 sheet 2 of 2

3) I end up with a graphic that takes about 3/4 of the page, there is about an inch of space and then short sentences for the rest of the section start.Not sure what is forcing this extra space.

So I've made good progress, but still have a couple more things to track down.

thanks

..dan

-----------------------------

Hi Dan,

Yes, interested to learn more about this if you find out some good details
...

Our customer's problem was never properly solved. They have resigned
themselves to paging through every chapter they produce and manually move
the float reference tags around until the floats look right. That can often
take quite a few reformats and cursing to get right 😉

So, they weren't too happy about that, but we'll probably move them to an
APP (3B2) system in the not too distant future. That should fix their
floats! 🙂

Cheers,
Gareth