[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] Text on path indents

Charles,


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.


I think you are missing my point. I know exactly why you changed
the defaults. However, when the colour picker first went in, you
said it was doing wrong things when it selected the colour model.
This is precisely because the options YOU run the program with
and how YOU use it are different from 90% of users in this respect
(you have "edit colour in colour model" switched on). When you
thought the behaviour had changed you said "we can't change
behaviour like that" (actually you'd just missed the option).

Re the off-topic bit: well you can't remove the ability (at least
in a professional version) to set CMYK colours or you wouldn't
be able to specify things like built black, get overprint
working etc. - equally unfortunately RGB is sadly useful for
web usage, and greyscale is useful for black and white work.
I think though perhaps we should provide some sort of dialog
that pops up when they first select CMYK which gives them a short
exam on colour science, and only allow them to proceed once they
have attained full marks :-)


(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 agree with that one. I think it was in from when ATM had poor
kerning info some time in the early 90s.


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.


From page 141 of the current manual:

"Alternatively, select a curve of line and then in the Text tool, click
on the line, where you want the text to start, and type. This
automatically first the text along the line. When you reach the end of
the line the text will wrap onto a new line, immediately below the
start of the previous one. If you do not want the text to wrap to
a new line, SHIFT+click on the line". (i.e. the no-wrapping feature
is documented so we shouldn't break it).


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.


I think that would be OK provided the shift-click thing works, so you
can get the other behaviour if you want.


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.


I have no problem with fit-text-to-curve doing the same thing as the
line. I just want some way to be able to get at the old behaviour.
I think I've found it - shift click and type.

However, I do think the ability to convert simple text (i.e.
click and type) into column behaviour is very useful. Much more
useful than "don't autokern". If you want more button bar space,
making Bold and Italic double-decker would save some. (about 1.5
buttons worth). Or the ability to convert to a column (and
possibly back - which is really turning wrapping on and off)
could be on the right-button context menu like "reverse text on curves".

Alex