svg not rendered completely

[coliss86]

Steps to make the bug happen

1. Load the attached svg
2. 2 parts are missings: "Joyeux Anniversaire" and the robot on the lower left
   

This file has been created with inkscape: original file

What was supposed to happen
the svg looks like this:

Platform (please complete the following information):

• Version: master
• OS: OSX
• Robot model (if any): [e.g. Makelangelo 5]

[PPAC37]

it seems that the text must be transformed into paths before saving in svg under inkscape (do a Shift+Ctrl+C on the text) but even with that, the svg obtained does not look better on Makelangelo...

there is surely the fact that the batik lib is to update ... and/or the fact that the system fonts are not necessarily well compatible with the JRE (when we do not transform the text in paths ) )

a workaround when the SVG does not render as you want, is an external transformation, of an SVG format into EPS with inkscape, then EPS into DXF format with pstoedit ... cf : https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Other_2D_formats

Of course it's not the easiest but it works well (especially when you have everything installed inkscape and pstoedit and make to use the Makefile

Create a directory put the .svg and the makefile and do make from a console in this dir. (Makefile in the zip with the svg and the dxf convertion output)
svg_to_eps_to_dxf_via_make.zip

$ make
inkscape -E joyeux_anniv.eps joyeux_anniv.svg
Gtk-Message: 18:41:19.073: Failed to load module "canberra-gtk-module"
pstoedit -dt -f "dxf: -polyaslines -mm" joyeux_anniv.eps joyeux_anniv.dxf
pstoedit: version 3.70 / DLL interface 108 (built: Aug 29 2017 - release build - g++ 7.2.0 - 64-bit) : Copyright (C) 1993 - 2014 Wolfgang Glunz
rm joyeux_anniv.eps

and make clean to delete all the .eps and .dxf (or else the make have nothing to do as the cible exist ... )
sorry i didn't have the font you used in the SVG

[coliss86]

Thx for the workaround !

[i-make-robots]

This is a part of #353

[coliss86]

closing for duplicate of #353

[PPAC37]

Hey not so fast cowboy ;)

In fact, from what I understood from LoadSVG,

the svg file you quote here does not have the problem of the lack of the getNormalizedPathSegList function in #353

but rather of the way in which the SVG/xml is exploited/explored. (do not take into account the parent elements (like g or symbol or pattern ...) of the path tags

(we just do a select all "path" elements without taking into account their level in the xml tree)

and therefore if an element (like the drawing of the robot from you file) is encapsulated in a tag g which has a transformation (like a move of position x,y ), this transformation is not taken into account. ...

so basically that's another story / another problem ...

[i-make-robots]

Changing bridgeContext.setDynamicState(BridgeContext.DYNAMIC); instead of BridgeContext.STATIC makes the robot appear where it should be.

[i-make-robots]

I see that xalan-2.7.2.jar from maven central has a META-INF/services/org.apache.xalan.extensions.bsf.BSFManager file declaring org.apache.bsf.BSFManager as a provider ... but org.apache.bsf doesn't exist in the JAR.

[coliss86]

yes, this in the problem and there is no fix on this jar :'( Before the java modularization introduced in java 9, it was not an issue.

[github-actions]

This issue is growing stale and will be automatically closed in 60 days if nothing is done.

[i-make-robots]

@PPAC37

and therefore if an element (like the drawing of the robot from you file) is encapsulated in a tag g which has a transformation (like a move of position x,y ), this transformation is not taken into account. ...

I'm not convinced this is the issue. Looking at only the robot in the bottom of the image I see the SVG code is

<path d="M 118.5,102.5 
C 118.5,80.168 136.668,62 159,62 
h 144 
c 22.332,0 40.5,18.168 40.5,40.5 
v 48 
c 0,8.239 -16.171,16.553 -30.019,21.169 
C 291.56,178.976 262.268,183 231,183 199.732,183 170.439,178.976 148.519,171.669 134.671,167.053 118.5,158.739 118.5,150.5 
Z
m 0,80 
v -8.518 
c 5.971,4.143 14.148,8.208 25.275,11.918 23.41,7.803 54.387,12.1 87.225,12.1 32.838,0 63.815,-4.297 87.225,-12.101 11.128,-3.709 19.304,-7.775 25.275,-11.918 
v 8.518 
c 0,22.332 -18.168,40.5 -40.5,40.5 
H 159 
C 136.668,223 118.5,204.832 118.5,182.5 
Z" />

Which is reported in the log file as (truncated numbers for clarity)

Move Abs (118.5,102.5)
Cubic curve (71.189,912.749) (79.190,904.441) (89.025,904.441)
Line Abs (303.0,62.0)
Cubic curve (162.278,904.441) (170.280,912.749) (170.280,922.961)
Line Abs (343.5,150.5)
Cubic curve (170.280,948.678) (163.158,952.480) (157.059,954.591)
Cubic curve (147.405,957.932) (134.505,959.772) (120.734,959.772)
Cubic curve (106.964,959.772) (94.063,957.932) (84.409,954.591)
Cubic curve (78.311,952.480) (71.189,948.678) (71.189,944.911)
Close path
Move Abs (118.5,230.5)
Line Abs (118.5,221.982)
Cubic curve (73.819,979.493) (77.420,981.352) (82.320,983.048)
Cubic curve (92.630,986.616) (106.272,988.581) (120.734,988.581)
Cubic curve (135.196,988.581) (148.839,986.616) (159.148,983.048)
Cubic curve (164.049,981.352) (167.650,979.492) (170.280,977.598)
Line Abs (343.5,230.499)
Cubic curve (170.280,991.705) (162.278,1000.013) (152.443,1000.013)
Line Abs (159.0,270.999)
Cubic curve (79.190,978.064) (71.189,969.756) (71.189,959.544)
Close path

Note that all horizontal and vertical lines are smashed by the parsing library to line abs and relative moves are smashed to move abs.
Note the first close path returns the turtle to 118.5,102.5 and then a relative move m 0,80 should move to 118.5,182.5 BUT the move abs received from the library is to 230.5. Whoops?

[PPAC37]

You're probably right, I spoke without really knowing and testing because the svg interpretation lib escapes me. And so I made a guess that was probably wrong. my excuses.

[github-actions]

This issue is growing stale and will be automatically closed in 60 days if nothing is done.