RE: [XaraXtreme-dev] Text on path indents

["Gerry Iles" <GerryI@xxxxxxxx>]

Unfortunately there is another complication/inconsistency.  The current
code has difficulties doing a wrapping text story on a closed path.  If
you click to type on a closed path you get a non-wrapping text story
(this is why the user in the forums recently couldn't see the margin
blobs).  There is very little point in having multi-line text on a
closed shape as each "line" is simply offset perpendicularly to the path
from the previous "line" so the complete rings of text end up
overlapping.

If you have a wrapping text story and you fit it to a closed shape then
it does remain wrapping but the two margin blobs are draw at the same
place and the EORing thus makes them invisible.  They can still be
dragged but it is not possible to make the story straddle the "start" of
the closed path.  The dragging operations ensure that the left margin is
always before the right measuring from the first point of the path.

When wrapping text stories were implemented it was decided (wrongly, in
my opinion) to make clicking on an open path create a wrapping text
story.  Originally, before wrapping was implemented, it would simply
insert a kern code to make the text start at the click position.  It
would have been more consistent to leave the click behaviour as it was
for both open and closed paths and require the user to drag the margin
extent on the curve if they want a wrapping text story just like they
have to do on the page.  E.g. the curve is simply a constraint on where
the baseline of the story can be...

This could also allow the direct creation of wrapping text stories on
closed paths (with a little extra work to allow the text story to
straddle the "start" of the closed path where the left margin would
conceptually be further along the path than the right margin).  This
could be useful if the user sets the margins to a sensible portion of
the shape.

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Charles Moir
Sent: 05 July 2006 17:14
To: dev@xxxxxxxxxxxxxx
Subject: RE: [XaraXtreme-dev] Text on path indents

> It's amazing the peculiar habits people get into. See (for 
> instance) the fact that by default the colour editor does not 
> edit in native colour model.

A relatively recent change to try and counter the appalling mess that
colour models bring. Just see the continuous ongoing stream of customer
confusion that the CMYK model brings, to even the most experienced and
"expert" Xara users. 99% of seasoned professional graphics designers
still don't understand any of it. Worse, most of them think they do
understand it.

Off topic I realise, but I know with absolute clarity that we should
remove all but the HSV colour editor, and we'd have a hugely simpler and
better system for the 99% of users who really just want to pick a
colour. They do not want to understand the implications of separations,
colour models, colour spaces, gamut, profiles and all the rest of the
techno-babble that clutters this area.

Defaulting to always showing HSV picker is part of way towards trying to
reduce confusion.

> You yourself often make the 
> argument for not changing UI unless absolutely necessary - 
> surely it's worse to change something and not support the old 
> UI at all?

No I make the argument for not adding to the UI. I'm quite happy to
remove pointless features and we should be doing, throughout Camelot. We
should be constantly struggling to cut, cut and cut more. Simplify,
simplify and then make it simpler still.

(A perfect example, right in this area, is the pointless Auto-kern
button the text tool Infobar. We're going to have a big space issue on
this Infobar soon with new stuff coming down the road. Anyway who has
ever, ever used this feature to not auto-kern text? Why on earth would
you not want auto-kerning. Bad decision making, and a mistake of mine
for allowing it to go in)

I make the argument for not changing things in Xara LX 1.0 for
completely different reasons. (a) All the documentation, manuals, help,
thousands of pages of web tutorial, and movies show the existing UI. We
simply cannot afford to re-do this, from a time or money point of view
in the race to create a "1.0" Linux version. (b) We know it works and we
know just how very costly it can be changing things (think colour edit
changes). Copying something exactly is 10x easier than inventing new
stuff, and it means, just as we've done with this text margins, it's
very easy to find out how it should behave.

So the goal for LX was always 'let's not invent anything or change
anything', which we're now breaking in some minor areas I admit.

But step back, consider the issue here.

A) We have a hugely unintuitive, very confusing, inconsistent feature.
It has a corresponding high support cost. "Why can't I see the margin
blobs, when you can".

B) The suggested solution involves adding or removing no buttons, or
adding any more UI at all. It involves the slight change to the
behaviour of one menu option, so 'Fit text to curve' does the same as
typing on a curve.

That is a huge, no-brainer, gain. This slight change solves the problem
completely. Now you'll always get your margins blobs, the questions will
stop and we have a consistent UI.

The downside is that we lose an obscure feature. Well that's a price
well worth paying. (The logic is: We gets lots of people wondering about
why they can't see margins on their text. We get no one (that I know of)
who uses or will miss the lost feature. So that makes it a very simple
decision)

The solution to the lost feature, adding a new button, is not a price
worth paying in my opinion UNLESS it has some other upside, which it
does. Then it might be worth it. But actually that's a separate point.

We should make the change to the menu - for the reasons listed above.

We can make a further change to add a new feature, and add a new button,
at the same time as restore the lost feature, at a later time.

> And if it's a curve? You need to add a line segment on the end, no?

No. You either just draw on the end of the curve with the freehand tool
or just drag extend the curve. In all the times I've ever had text on a
curve and the curve wasn't long enough, it's been trivial to extend the
curve without adding new segments. I just drag on the end and sometimes
drag on the curve and sometimes adjust the bezier control handle.

> It looks like Phil put the argument more eloquently than me 
> anyway. I agree that it is much more useful to change 
> unwrapped text into wrapped text than vice-versa, but if it's 
> free (given turning unwrapped into wrapped is 
> useful), and it maintains a feature that (the text going 
> beyond the end of a line) which we would not in retrospective 
> have introduced but which now people /may/ rely on, I don't 
> really see it as a bad thing.

Trouble is not free. We have to invent a new feature, the ability to
wrap / unwrap text, add a new button, get a new icon designed, document
the change and test it all.

I have no problem adding this to the long wish list of new features. But
it can't be a priority and should not be tied to the work of fixing the
behaviour of the 'fit text to curve' feature.

> You wouldn't put in a greying 
> action button that just converted it one way, would you?
No way.

Charles