[Cuis-dev] [Ann] Major updates to VectorGraphics

[Hilaire Fernandes]

So far, your implementation of VectorGraphics engine followed the SVG 
specification. I discovered that when I implemented the DrGeoSVGCanvas 
to render a DrGeo sketch to a SVG file.

Particularly in the style of the element, the dashArray attribute was of 
same nature in VG and SVG:

  1
  2
  3
  4
  5
  6
  7
  8
  9
10
11
12
13
14
15
16
17

	

DrGSVGCanvas>>styleOf: element StrokeWidth: strokeWidth color: strokeColor strokeDashArray: sda fillColor: fillColor
"
Apply style to a given element (node)
"
	strokeWidth ifNotNil: [element attributeAt: #'stroke-width' put: strokeWidth asString].
	strokeColor ifNotNil: [	element attributeAt: #stroke put: 
		(strokeColor isTransparent ifTrue: ['transparent']ifFalse:	strokeColor hexHtml)].
	sda ifNotNil: [
		element 
			attributeAt: #'stroke-dasharray' 
			put: (String streamContents: [:s | sda do: [:e | s store: e]separatedBy: [s space]])].
" sdao ifNotNil: [element attributeAt: #'stroke-dashoffset' put: sdao 
asString]."
	fillColor 
		ifNotNil: [
			element attributeAt: #fill put: fillColor hexHtml.
			fillColor isOpaque ifFalse: [element attributeAt: #'fill-opacity' put: fillColor alpha asString] ]
		ifNil: [element attributeAt: #fill put: 'none']



 From my understanding, now your implementation differs in the way 
dashes are represented in SVG. It is just an observation not a complain.
To minimize my code change, I implemented a backward compatible method 
in AbstractVectorCanvas, it converts my dash (composed of only two 
numbers) from the former format to your new format:

  1
  2
  3
  4
  5
  6
  7
  8
  9
10
11
12
13
14
15
16

	

strokeWidth: borderWidth color: borderColor strokeDashArray: dashedBorder do: pathCommandsBlock
"
dashedBorder = array of 2 elements, for example #(1 6), one pixel on, 6 off
"
	dashedBorder 
		ifNil: [
			self 
			strokeWidth: borderWidth 
			color:  borderColor 
			do: pathCommandsBlock]
		ifNotNil: [
			self 
			strokeWidth: borderWidth 
			color:  borderColor 
			dashedStrokeBits:  (2 raisedTo: dashedBorder first)- 1  << dashedBorder second
			do: pathCommandsBlock ]



It works pretty well and keep DrGSVGCavnas working. It does not work 
well for my Locus Morph though. A locus is a collection of points 
connected by line. See the below the blue sinus curve should be dashed. 
Of course it is related to the way the locus sample are computed, some 
samples may be too close to each other to see the dash painted.
*Surprisingly for me, this problem was not present in your Smalltalk 
previous implementation of dash. *




When playing a bit with the Morph Locus parameters to alter the sampling 
of the locus, we can reveal what is going on, see below.
All this is not a bug in your implementation, but your previous 
implementation could hide this problem related to sampling at a dynamic 
rate, and it was pretty cool.







Le 27/05/2025 à 17:53, Juan Vuletich a écrit :
> Not sure what you mean. Can you give an example? Is there some quick 
> test I can do that works without the updates?
>
> Thanks,

-- 
http://mamot.fr/@drgeo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250527/44e750d3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture d??cran du 2025-05-27 19-51-15.png
Type: image/png
Size: 43613 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250527/44e750d3/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qtrYUCzmU3Wo0wRr.png
Type: image/png
Size: 18969 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250527/44e750d3/attachment-0003.png>