[squeak-dev] Bezier filled shape rendering artifacts

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] #createSegmentsFromSVG: [was: Bezier filled shape rendering artifacts]

Igor Stasenko
On 25/03/2008, Klaus D. Witzel <[hidden email]> wrote:

> On Tue, 25 Mar 2008 14:36:49 +0100, Gary Chambers wrote:
>
>  > Though I did find a bug (rarely encountered) in
>  > SVGPathMorph>>createSegmentsFromSVG.
>  >
>  > Replace
>  >
>  >       data do: [:cmd |
>  >               ((cmd = $S or: [cmd = $s]) and: ['CcSs' includes: c not])
>  >                       ifTrue: [lastCubicControl := position].
>  >               ((cmd = $T or: [cmd = $t]) and: ['QqTt' includes: c not])
>  >                       ifTrue: [lastQuadraticControl := position].
>  >
>  > with
>  >
>  >       data do: [:cmd |
>  >               ((cmd key = $S or: [cmd key = $s]) and: ['CcSs' includes: c not])
>  >                       ifTrue: [lastCubicControl := position].
>  >               ((cmd key = $T or: [cmd key = $t]) and: ['QqTt' includes: c not])
>  >                       ifTrue: [lastQuadraticControl := position].
>
>  Yes, seen that. But the glyph files that I tested never did the #ifTrue:
>  part in the patched (last week, by me) version, because, otherwise
>  aCharacter would have DNU'ed #not ;-)
>
>  Also[1], command $Z is not handeled in #createSegmentsFromSVG: and in
>  #pathDataFromSVG: ($z is, both methods can do what $z does when it's $Z
>  and when after the data do: it's not $Z). I had just converted $Z to $z in
>  #pathDataFromSVG: and let the rest as is.
>
>  Also[2], use of temp names lastCubicControl,lastQuadraticControl seems not
>  to be consistent in the $t branch (compared to the $T branch).
>
>  >
>  > Also, never did get to the bottom of why the page bounds sometimes come
>  > out
>  > wrong... (perhaps because taken from the SVG rather than computed
>  > "after-the-fact").
>  >
>  > Glad someone is still using the old SVGMorph "experiment"!
>
>  Yay, and it works :) still can't believe it :)
>
>  There are BTW "only" some 6,000 known glyphs of this sort; my Inkskape
>  instance will surely get burned when I do change the scaling of the 2,500
>  [many duplicates] .svg files that I have in my directory.
>

If problem was with scale, you can normalize scale before rendering.
Like:
 determine the bounding box of svg shape points, let the scale be the
length of shorter box side. Multiply all coordinates by 20/scale.

Then render morph with scale transform:

scale/20 *  [ (points) ]

>  /Klaus
>
>  > Regards, Gary.
>
>
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Moving SVGMorphs around [was: Bezier filled shape rendering artifacts]

Igor Stasenko
In reply to this post by Klaus D. Witzel
On 25/03/2008, Klaus D. Witzel <[hidden email]> wrote:

> On Tue, 25 Mar 2008 15:29:41 +0100, Igor Stasenko wrote:
>
>  ...
>  > Okay, one more test.
>  > open given morph
>  >
>  > (SVGMorph fromFileStream:
>  >  'http://squeak.cobss.ch/JSesh/resources/glyphs/varia/Y4.svg'
>  >   asUrl retrieveContents contentStream
>  >  ) openInWorld
>
>  This now renders what is expected, have changed width:=height:=180 for
>  {A1,A2,Y3,Y4].svg on the server :)
>
>  > then inspect SVGPathMorph submorph and evaluate following:
>  >
>  > 2 to: segments size do: [:i | self assert:(segments at:i) start =
>  > (segments at:i-1) end ]
>  >
>  > Does endpoints of adjusted segments should be equal?
>  > Because this test shows that some are not.
>
>  You're just duplicating my test code from the other week, which you
>  apparently have never seen before ;-)
>
>  > | good bad |
>  > good := bad := 0.
>  > 2 to: segments size do: [:i |  (segments at:i) start = (segments
>  > at:i-1) end ifTrue: [ good := good +1] ifFalse: [ bad := bad +1 ] ].
>  > { good. bad }
>  >
>  > prints: #(86 8)
>
>  Now that the glyphs renders OK, did you notice that when alt-click
>  + moving the glyphs farther than their bounding box, then they are blanked
>  (and un-blanked when moved back). Also, some artefacts suddenly appear
>  where the halo-button was located, when moving the SVGMorphs within their
>  bounding box.
>
>  This cannot be a problem with the constants in #defaultViewBox since the
>  parsed viewBox values are respected.
>
Open inspector of SVG Morph and eval:

self position:  (bounds extent -1)
self position:  (bounds extent)

a shape is not drawn simply because submorph (SVGPathMorph) don't
passes visibility test in canvas (.. canvas isVisible: self bounds
...), when it's bounds outside (0@0 corner: bounds extent).

A quick dirty hack:
copy SVGPathMorh>>drawOn:
to SVGPathMorh>>fullDrawOn:

I think it's because nesting with MatrixTransformMorph.
The bug is somewhere in it.
Since both SVGMorph and SVGPathMorph subclassed from it,
canvas tranformed twice to start drawing things.

>
>  /Klaus
>
>
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: #createSegmentsFromSVG: [was: Bezier filled shape rendering artifacts]

Klaus D. Witzel
In reply to this post by Igor Stasenko
On Tue, 25 Mar 2008 22:32:33 +0100, Igor Stasenko wrote:

> On 25/03/2008, Klaus D. Witzel wrote:
>> On Tue, 25 Mar 2008 14:36:49 +0100, Gary Chambers wrote:
...

>>  > Glad someone is still using the old SVGMorph "experiment"!
>>
>>  Yay, and it works :) still can't believe it :)
>>
>>  There are BTW "only" some 6,000 known glyphs of this sort; my Inkskape
>>  instance will surely get burned when I do change the scaling of the  
>> 2,500
>>  [many duplicates] .svg files that I have in my directory.
>>
>
> If problem was with scale, you can normalize scale before rendering.
> Like:
>  determine the bounding box of svg shape points, let the scale be the
> length of shorter box side. Multiply all coordinates by 20/scale.

Yes, wanted to investigate such a direction anyways.

> Then render morph with scale transform:
>
> scale/20 *  [ (points) ]
>
>>  /Klaus
>>
>>  > Regards, Gary.
>>
>>
>>
>
>



12