Hi All,

Working with version 5.0.5.7 of PageStream running under OS X 10.6.4

At last, a small success with anchoring after all my bitching about failing to successfully Import... graphics that PageStream had saved in IFF ILUS format.

The trick "SEEMS" to be: Don't include a text frame! Now, I'll wait for Deron's message that the previous sentence is crap.

I discovered an OBVIOUS way to anchor a caption for the graphic, so that the caption floats with the graphic, but is not part of the graphic. Also saves space vertically.

Basically all I did was:

-- group the various elements into a single object using "Object -> Group", and included were text blocks.

-- save the grouped object with "File -> Export..." using format choice IFF ILUS. For me, this was just a safety measure so that the grouped object would not be lost when I screwed up .... again!

-- anchor the grouped object, then move it to a suitable left-right location on the page.

-- move the text cursor from the anchor point, down the page to a point where the caption should go and enter the caption. Push any offending text down so that it does not overwrite the graphic. Change the anchor line, a succession of x's ...xxxxx, to white.

I also checked that the saved .ILU file could be imported and anchored, in case the current anchor point was deleted, accidently or otherwise; and made sure the imported version was same as the original --- kept the 'original' on the pasteboard for comparison.

After a long succession of failures, it sure feels nice to win one!

The Float Test
==============
Go above an anchored object and push it toward the bottom of the page. I did this by simply entering blank lines. Floating down proceeds nicely UNTIL the bottom edge of the graphic reaches the 'bottom' of the text frame. Adding additional lines pushe the graphic below the boundary of the text frame. This results in one crappy page. Finally, with a few more blank lines,the graphic snaps to the top of the nest page.

In my opinion this behaviour is not satisfactory. With version 5.0.3.3 on the Amiga, the graphic never sneaks out of the text frame, but snaps to the next page as it "should"; i.e., as soon as the bottom of the graphic reaches the bottom of the text frame, it snaps to the next page.

By removing text above the graphic, it crawls back to the previous page in the same manner; i.e., it hangs over the bottom of the text frame until sufficient space is made available; i.e., it does not snap back.

Of course, the noted deficiency is easy to spot and eliminate, but in a 500 page document you may have to do a lot of checking with the current floating behaviour.

Nonetheless, I'm still in a happy frame of mind tonight! ) Thanks Deron.

Cheers from

Don Green Dragon
fergdc@Shaw.ca

>
> The Float Test
> ==============
> Go above an anchored object and push it toward the bottom of the page. I did this by simply entering blank lines. Floating down proceeds nicely UNTIL the bottom edge of the graphic reaches the 'bottom' of the text frame. Adding additional lines pushe the graphic below the boundary of the text frame. This results in one crappy page. Finally, with a few more blank lines,the graphic snaps to the top of the nest page.
>
>

I would guess that you are using a fixed leading. Since inline objects
are treated like a character (in this case a really big character), then
it stands to reason if you tell it "force the line spacing to xxx" then
that is what you will get, even though your "character" is much bigger
than the line spacing.

>
>
> Don Green Dragon
> fergdc@Shaw.ca
>
>

Deron

--
Deron Kazmaier - support@pagestream.org
Grasshopper LLC Publishing -http://www.pagestream.org
PageStream DTP for Amiga, Linux, Macintosh, and Windows

Hi Deron,

On 2010-1209-, at 9:36 AM, PageStream Support wrote:

>> The Float Test
>> ==============
>> Go above an anchored object and push it toward the bottom of the page. I did this by simply entering blank lines. Floating down proceeds nicely UNTIL the bottom edge of the graphic reaches the 'bottom' of the text frame. Adding additional lines pushe the graphic below the boundary of the text frame. This results in one crappy page. Finally, with a few more blank lines,the graphic snaps to the top of the nest page.
>>
> I would guess that you are using a fixed leading.

Yes, I normally use fixed leading.

However, I checked back -- for the n-th time -- and in an old file that I had received from Ernest Unrau I noticed that at the anchor point, the "Leading" panel revealed

Type: Automatic (pt)
Amount: 1pt
Mode: Proportional

With setting above, and using 5033 (Amiga), the inline object snapped to the next page. So I reset the text above and at the anchor point to

Type: Fixed
Amount: 16pt
Mode: Proportional

and tried again. With those settings above, the 'snap' did NOT occur, and the object could be pushed below the bottom of the text frame. Hence your analysis below is right on.

> Since inline objects
> are treated like a character (in this case a really big character), then
> it stands to reason if you tell it "force the line spacing to xxx" then
> that is what you will get, even though your "character" is much bigger
> than the line spacing.

So I went to the iMac and version 5057. After some fooling around -- some would call it 'experimentation' -- I found that the 'best' (for me) setting of the text to which the large inline object is anchored is:

Type: Relative(%)
Amount: 100%
Mode: Proportional

I'm not sure what the magic number for "Amount" is, but at 80% and 90%, the object would NOT snap, but at 99% it did!!! If "Amount" is set to a value greater that 100% -- the default is 120% -- then the snap was okay, but there was an 'overhang' i.e., the text cursor was larger than the vertical height of the inline object, which I found annoying.

Advantages of the "Relative(%)" settings appear to include:

(1) When there is no longer adequate vertical space for the inline object, it snaps to the next page -- provided "Amount" was approximately 100% or larger. Similar behaviour if one pulls the object back to the previous page.

(2) When to the left/right of the object the text cursor is the same height as the object (at Amount = 100%),and therefore is easy to see. So pushing or pulling the object, if that is desired, is easily visible.

(3) An appropriate caption for the object is easily placed below or above the object, and it moves nicely, except that:
3.1 If placed below, then the caption will push onto the next page, before the inline object snaps to the next page. If pulling, then the reverse order.
3.2 If placed above, then the inline object snaps before the caption.

(4) If is easy to place very large captions to the left or right of the inline object. Be careful as you increase the size of the letters in the caption. When not enough space remains on the line, then all hell breaks loose.

There is one advantage of the "Fixed" setting:

(5) When the "Fixed" setting is used, then the text cursor --- when in the location immediately to the left of the inline object --- appears as a bar 16 points high (or whatever your setting for "Amount" happens to be). Therefore, it can be easily moved down and to the left of the inline object (hit RETURN), to a suitable vertical location. At that point, the caption can be written to the left of the object. You can do the equivalent on the right. This does not waste vertical space for the caption, and is ideal for a long-winded caption.

There are possibly some disadvantages "Relative(%)" settings, including:

(6) If you push the inline object onto the next page with blank lines, then you may end up with a white hole. I.E.,if the inline object is 12 line high, then when it snaps, you may be left with 12 lines of blank space. It depends how you pushed or pulled the object. But with either the "Fixed" or "Relative(%)" approach, you can easily end up with a white hole. If you created a white hole, then you should probably fill it with text since a huge white hole will surely look amateurish.

(7) With the "Relative(%)" setting above, a caption is restricted to a single line, to the left or right (or both) of the object. And the the vertical location of the caption is limited by your setting

Amount: 100%

or whatever setting you use.

In general, there is no such thing as text flow around the inline object, since the inline object is treated like a character. I'm not saying that you cannot set up other objects and have the text flow around an additional object, and consequently effect a flow to the left (say) of the inline object. But each of my attempts was downright silly and did not stand the "float test."

Don Green Dragon
fergdc@Shaw.ca