RE: [XaraXtreme-dev] Text on path indents

[Martin Wuerthner <lists@xxxxxxxxxxxxxxx>]

In message <5056CBC646CB4047BB26120F4377DB71D71C84@xxxxxxxxxxxxxxxxxxx 
>
          "Gerry Iles" <GerryI@xxxxxxxx> wrote:

> Ideally it would use a contour but a lot of paths will generate shorter
> contours than the original (especially closed paths) and you will run
> out of path eventually and there will be nowhere sensible to put the
> next line.

True, but with a rectangular text frame, there is limited space, too, 
so I do not see this as a big problem. We will soon have the concept 
of text objects being "full" anyway.

> If this could be overcome sensibly then it would still be
> necessary to support the old system for old files that use it.

True, but I guess that nobody will want to create any old style 
objects any more once we have the new method, so this would not have 
an impact on the user interface - though to convert from old to new, 
users would have to remove the text from the path and re-fit it.

Martin

> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
> Behalf Of Martin Wuerthner
> Sent: 06 July 2006 09:21
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Text on path indents
> 
> In message <5056CBC646CB4047BB26120F4377DB719BA77B@xxxxxxxxxxxxxxxxxxx
>>
>           "Charles Moir" <CharlesM@xxxxxxxx> wrote:
> 
>> In fact wrapping text on a path is not very smart either and I think
>> just moves the next line down vertically, when it would be a lot
>> better to offset the path perpendicular to the line at the initial
>> insertion point.
> 
> It does not move the next line down vertically. What it does is to
> move it down perpendicularly from the start of the path. I guess this
> is a hangover from the time when text on path always started at the
> start of the path. There is even a Help file entry describing how to
> add a tiny line segment to the start of the path in order to control
> where the next line goes.
> 
> However, does nobody else feel that just offsetting the path for the
> next line does not do the right thing anyway? For anything but the
> most trivial paths it means that the distance between the lines varies
> along the path and in most cases, the text lines even overlap. Should
> we not use the contour code to compute a parallel line at an even
> distance?
> 
> Martin