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. |
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. > 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. |
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. >> >> >> > > |
Free forum by Nabble | Edit this page |