Re: SVG text wrapping (was: minutes, Tokyo 2013 SVG F2F Day 2, 4 June 2013)

Hi Doug

How are dx and dy treated in your proposal?  For example, does a positive
dx, for example, affect wrapping calculations, or is are the offsets
applied afterwards?

Also what about textLength?  It is supposed to apply to the whole element,
but if the element is wrapped, what happens then?

Paul



On 7 June 2013 02:08, Doug Schepers <schepers@w3.org> wrote:

> Hi, Brian, Alex-
>
> On 6/6/13 4:10 AM, Alex Danilo wrote:
>
>> Hi Brian,
>>
>> --Original Message--:
>>
>>> (2013/06/04 18:20), Cameron McCormack wrote:
>>>
>>>>      krit: what about using the text area element from 1.2?
>>>>
>>>>      heycam: the name is bad
>>>>
>>>>      shepazu: in 1.2 we define an algorithm and I don't think that's
>>>>      a good idea for what I'm proposing
>>>>      ... I just want to make it super easy to use and intuitive and
>>>>      rely on the behaviour that comes out of CSS
>>>>
>>>>      krit: the switch of behaviour of the text element with
>>>>      exclusion or width and height is confusing to me
>>>>      ... for shapes suddenly x and y are not relevant anymore
>>>>      ... and for your propsal y changes meaning
>>>>
>>>
>>> Sorry, I guess I wasn't following the conversation properly at this
>>> point but I just want to second Dirk's point here.
>>>
>>> I find the idea that x/y change meaning depending on the presence of the
>>> width attribute surprising. I can certainly imagine authors cursing SVG
>>> at the top of their lungs when their carefully positioned textbox
>>> suddenly shifts up because they removed a width attribute (which may not
>>> have even been having a noticeable effect depending on its value).
>>>
>>> (And I can likewise imagine WONTFIXing the corresponding bugs they file
>>> on UAs when they finally discover the link between the vertical jump and
>>> the presence/absence of the width attribute.)
>>>
>>> But perhaps I have misunderstood the proposal?
>>>
>>
>> Actually this isn't Doug's proposal. It's how Cam prototyped an
>> implementation.
>>
>> Doug originally intended that the x, y stay the same regardless of the
>> presence of a width
>> attribute. Cam just did a quick implementation and I guess for expedience
>> made the
>> x,y the flow bound box origin.
>>
>> So, the text would not jump based on the presence of the width attribute.
>>
>
> Thanks, Alex! Yes, that's correct, and I agree with you, Brian.
>
> I've now clarified my proposal on this point (see "Positioning (x and y)"):
>  http://www.w3.org/Graphics/**SVG/WG/wiki/Proposals/**Wrapping_Text<http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text>
>
> Another flaw to shifting the y-origin be default is that it is worse for
> the fallback case, where a browser doesn't yet support width.
>
> However, I agree with Cameron that empowering authors to explicitly set
> the y-origin to align to the top of the rendering area is a good idea, and
> alignment-baseline:top will let them do that (as I mention in the updated
> proposal).
>
>
>
>  If not, is it too late to consider <textbox>, <textrect> or some other
>>> name?
>>>
>>
>> I wish that 1.2 Tiny had never chosen textArea and stuck with the
>> original naming
>> since that would have been so much better. It's actually a very useful
>> primitive
>> for embedded engines doing TV guides and the like - but alas that's not
>> the
>> general web...
>>
>
> I proposed <textshape> for SVG Tiny 1.2, but alas, my feedback came too
> late for existing implementations.
>
> I still maintain that allowing authors to specify a width for <text> is
> more intuitive and has a better fallback than a new dedicated element, and
> I don't think it results in behavior any more confusing than any other
> property that changes the text positioning... for example,
> alignment-baseline or text-anchor.
>
>
> Brian, does this address your concerns? Do you still have worries about
> this proposal?
>
> Regards-
> -Doug
>
>