bug fix with performance and clip

[Thierry Kormann <Th...@sophia.inria.fr>]

Hi,

After my fix for the clip (ie. use an Area instead of a GeneralPath in the 
CompositeShapePainter.getPaintedArea(Shape) - used by the getOutline() method 
on ShapeNode) - we had some regressions in terms of performance.

I fix that by :

- Add a new method on ShapePainter : getPaintedOutline.
  Now, the getPaintedOutline uses an Area and getPaintedArea uses GeneralPath
- Remove all dependencies on getOutline() in the methods on GraphicsNode and
  ShapeNode (ie. contains and intersects).

*** Warning: never use getOutline anymore !

I also improve performance by creating a CompositeShapePainter in 
CSSUtilities.convertStrokeAndFill only when necessary (stroke and fill are 
defined) - sorry that was not the case.

The samples/tests/clip.svg is still working correctly.

Regards,
Thierry.


-- 
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis

Re: bug fix with performance and clip

[Vincent Hardy <vi...@eng.sun.com>]

Thierry Kormann wrote:
> I also improve performance by creating a CompositeShapePainter in
> CSSUtilities.convertStrokeAndFill only when necessary (stroke and fill are
> defined) - sorry that was not the case.

In my work on pattern, I had also seen that (but not commited yet): this
was causing problems with the bounds, as it would take the stroke
into account, even when the stroke paint was null. 

V.

Re: Clarification of spec: whitespace

[Bill Haneman <bi...@ireland.sun.com>]

Hi again:

I should point out, while we're on the topic, that we pass
text-whiteSpace-BE-06.  

That may not be apparent from the output, but the apparent
discrepancies are entirely due to differences in font metrics
between our platform and the platform that generated the 
.png file and the host for the BE test composition... this
BE test has some hard-coded x positions for text substrings:

If you comment out the above code and un-comment the 
spaces-only equivalent:

you will see that we are in fact compliant.

There are three impediments to compliance with
text-decoration-BE-12:  

(1) Our strikethrough does not get stroked (limitation 
    in TextLayout);
(2) we are introducing extra spaces in the concatenated
    tspans (thus the previous email about "correct" behavior);
(3) we don't track underline fill, stroke, and stroke-paint independant
of
    the text stroke, fill, stroke-paint (I have a fix for this 
    that will require a tweak in SVGTextElementBridge)

(1) and (3) are easily fixed, and I have a fix for (2) that does not
    appear to regress any tests including BE tests, however it
    requires stripping whitespace from <tspan> elements.

-Bill

Re: Clarification of spec: whitespace

[Bill Haneman <bi...@ireland.sun.com>]

Stephane Hillion replied:

> > "Text includes tspan element." [leading and trailing whitespace stripped
> > from tspan]
> 
> Agree with the result, not the explanation. Here is mine: [All the contents
> are merged and then spaces are collapsed].

The trouble with this explanation is that it is ambiguous where
attributes are concerned - for instance, if the tspan element is
underlined, and the whitespace between tspan and the text is reduced
to one space, whose attributes does that space have?

Re: Clarification of spec: whitespace

[Stephane Hillion <St...@sophia.inria.fr>]

Bill Haneman wrote:

>  1) <text>Text includes <tspan>tspan</tspan> element.</text>
>
> This one is clear, the spaces around the tspan element are preserved and
> we see:
>
> "Text includes tspan element."

I agree.

> 2) <text>Text includes <tspan> tspan </tspan> element.</text>
>
> "Text includes tspan element." [leading and trailing whitespace stripped
> from tspan]

Agree with the result, not the explanation. Here is mine: [All the contents
are merged and then spaces are collapsed].

> 3) <text>Text includes
>    <tspan>tspan</tspan>
>    element.</text>
>
> "Text includes tspan element." [whitespace before and after tspan
> element compressed to ' ']

Again I have my version: [All the contents are merged, carriage returns are
replaced by single spaces].

> 4) <text>Text includes<tspan>tspan</tspan>element.</text>
>
> "Text includestspanelement."
>
> So far so good.  But here it gets interesting:
>
> 4) <text>Text includes<tspan> tspan </tspan>element.
>
> "Text includestspanelement."
> [I think the spaces around tspan should be stripped, but I am not sure]

I am pretty sure <tspan> should not be considered as a break in the content
of a <text> element.
The name <tspan> was choosen from <span> element in HTML. For clarification
see CSS2 and elements with style="display:inline".

> 5) <text>Text includes
>    <tspan>two</tspan>
>    <tspan>tspan</tspan>
>    elements.</text>
>
> (a) "Text includes twotspan elements." ??? OR
> (b) "Text includes two tspan elements."

I vote for (b) ;)

--
    Stephane.

Re: Clarification of spec: whitespace

[Bill Haneman <bi...@ireland.sun.com>]

Sorry, here are the lines from BE test text-whitespace:

Comment out three lines starting with:

<text x="85" y="250" style="fill:black; font-size:12; ...>
[... etc.]


and un-comment:

<text x="25" y="250" style="fill:red; font-size:12; ...>


-Bill

Clarification of spec: whitespace

[Bill Haneman <bi...@ireland.sun.com>]

Hi folks:

I need some clarification before I can commit a bug fix.  It has to do
with
whitespace-only text subelements (with whitespace-default).  If you
want, skip
to example (4) since I believe that examples 1-3 are straightforward and
I
don't have questions about them...

Examples:

1) <text>Text includes <tspan>tspan</tspan> element.</text>

This one is clear, the spaces around the tspan element are preserved and
we see:

"Text includes tspan element."

2) <text>Text includes <tspan> tspan </tspan> element.</text>

"Text includes tspan element." [leading and trailing whitespace stripped
from tspan]

3) <text>Text includes
   <tspan>tspan</tspan>
   element.</text>

"Text includes tspan element." [whitespace before and after tspan
element compressed to ' ']

4) <text>Text includes<tspan>tspan</tspan>element.</text>

"Text includestspanelement."

So far so good.  But here it gets interesting:

4) <text>Text includes<tspan> tspan </tspan>element.

"Text includestspanelement." 
[I think the spaces around tspan should be stripped, but I am not sure]

5) <text>Text includes
   <tspan>two</tspan>
   <tspan>tspan</tspan>
   elements.</text>

(a) "Text includes twotspan elements." ??? OR 
(b) "Text includes two tspan elements."

BE test text-decoration-BE-12 seems to support either (b) with
stripping of leading/trailing whitespace from tspan, or (a)
without.  I notice that the SVGTextElementBridge explicitly sets a
flag telling tspan not to strip leading/trailing whitespace,
but I wonder if this is correct?  

We get the best comformance by stripping <tspan>, but that means
that

<text>Text with <tspan>tspan</tspan>.</text>

is different from

<text>Text with<tspan> tspan</tspan>.</text>

-Bill