See here for the syntax of the <path> tag from a <svg> one:Question: Does anybody have an idea how I can read such svg path information via regex and display it in a skin, similar to the official app? See screenshot, this is exactly what the below "battery-graph-series" html is displaying ... Only the green charge% trend is what I would like to display in my skin. I already have some experience with Shape=Path Graph meters and I'm sure the svg path can somehow be converted to such a shape meter. Has anybody already done this? Any ideas are are welcome.
https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths
The first thing you notice after reading the relevant parts there is that in this case, they replicate almost identically the syntax of the Path custom option from the Shape meter (e.g. M is basically the first Path point in the Shape, the following L-s are the LineTo-s in the Shape, and Z is more or less the ClosePath part in the Shape). In other words, once you extract the contents of the <path> tag, three or four simple Substitute parts on that contents measure will easily "convert" it into what you'll use in the custom "Graph" path option (e.g. Substitute="L":" | LineTo " to which you add whatever M or Z parts as desired):
https://docs.rainmeter.net/manual/meters/shape/#Path
As for extracting the contents of the <path> tag, you only need to follow its syntax, e.g. assuming you get the above HTML part in a WebParser, something like RegExp=(?sU)<div class="battery-graph-series">.*<svg .*>.*<path d="(.*)".*>.*<\/path>.*<\/svg>.*<\/div> and then referencing the contents capture through StringIndex / StringIndex2 depending on your WebParser parent-child structure you're using should do (notice that I omitted the ?i aka case insensitive from (?siU) since some of the <path> syntax is actually case sensitive).
I have no idea if this <path> contents is the desired green part that's marked in your screenshot, you'll have to figure that (or if further Substitute refinements are needed) out yourself.
Obviously, as I said, the way your WebParser options are written will depend on their parent-child structure and what exactly you're already getting / capturing in the existing code.
Statistics: Posted by Yincognito — Yesterday, 3:04 pm