RE: [XaraXtreme-dev] Text on path indents

["Charles Moir" <CharlesM@xxxxxxxx>]

Yes you're right text on closed paths is pretty un-usable.  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.

Charles


> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Gerry Iles
> Sent: 05 July 2006 17:54
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Text on path indents
> 
> Also, the status line text is wrong when clicking on closed 
> paths.  Both a plain click and a shift click create a 
> non-wrapping story...
> 
> Gerry
> 
> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Gerry Iles
> Sent: 05 July 2006 17:49
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Text on path indents
> 
> 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
>