SVG arc rendering artifacts in Safari - ios

I have a very simple SVG to render: https://jsfiddle.net/091y7uyr/3/
There is a lot of math code there, but the point of it is just:
<svg style="position:fixed;top:0px;left:0px;width:100%;height:100%;
pointer-events:none;">
<path d="
M 65 51
A 434.180675278184 434.180675278184
0 0 0
275.01708984375 351.9502944946289
M 65 51
A 399.44622125592934 399.44622125592934
0 0 0
275.01708984375 351.9502944946289"
fill="black" fill-rule="evenodd">
</path>
</svg>
Here is the result:
But, in Safari, both on iOS (v9.3.4) and desktop (v9.1, build 11601.5.17.1) it looks a bit differently:
Does anybody know why that line between arc edges appears, and how to get rid of it?

Your SVG path is constructed a bit oddly.
<svg width="400px" height="400px">
<path d="M 59 110
A 167.87197502859138 167.87197502859138
0 0 0
200 301
M 59 110
A 159.4783762771618 159.4783762771618
0 0 0
200 301"
fill="black" fill-rule="evenodd"></path>
</svg>
You've constructed your shape by drawing two subpaths that start at the same place and curve in the same direction. So you actually have two circular segments overlaid on top of one another.
If we draw them separately and with a bit of opacity, you can see what is actually happening.
<svg width="400px" height="400px">
<path d="M 59 110
A 167.87197502859138 167.87197502859138
0 0 0
200 301" fill="red" opacity="0.4"/>
<path d="M 59 110
A 159.4783762771618 159.4783762771618
0 0 0
200 301" fill="green" opacity="0.4"/>
</svg>
The reason you are seeing only the difference between the two (the thin half-moon shape) is because you are using the even-odd fill rule. When you use the even-odd fill rule, overlapping subpaths generally create a hole.
The thin line you are seeing between the two endpoints is due to artifacts caused by slight differences in anti-aliasing between the two segment edges that are exactly on top of each other. Anti-aliasing is the use of shades of colour to make the edges of lines appear smoother. This is probably happening to some extent on all browsers. It's just more noticeable in Safari for some reason.
Fortunately in your case there is an easy fix. Instead of using two subpaths, just combine them into a single path. Have one arc going from rectangle A to B, and then an arc going back to the start point. If you do that, your extraneous extra line will disappear.
<svg width="400px" height="400px">
<path d="M 59 110
A 167.87197502859138 167.87197502859138
0 0 0
200 301
A 159.4783762771618 159.4783762771618
0 0 1
59 110"
fill="black"></path>
</svg>

Related

SVG sprite not showing on ios iphone ipad

SVG sprite not showing on ios iphone ipad.
In android, and on a PC, everything is ok.
But on iphone, ipad - just a white screen, how to fix it?
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
viewBox="0 0 1080 700" style="enable-background:new 0 0 1080 700;" xml:space="preserve">
<g>
<path class="st0 state" data-state="Some text 1" d="M323.3,243.1c8,5,22.6,10,30,12c7.2,1.3,6.9-0.8,14-2c6.6,6.6,18.8,8.9,24,17c2.9,4.3,3.9,7.1,5.6,12.1
c2.9,11.4,12.6,20.4,11.2,32.9c-2.7-0.1-5.4-0.2-8-0.2c-2.6-8.5-5.6-17-7.2-25.8c-3.5,0-9.1-0.1-12.6,0c-2,5-6.4,8.3-8,13
c1,2,4.1,3.9,6,5c1,8.5,8.8,19.2,1.5,26.5c-4.9,5.4-2.2,13.4,1.1,19c5.9,9.3-0.7,18.2-3.6,27.5c-9.9-0.7-18.6-3.6-24-11.8
c-6-0.2-10.9-1.3-17-1.2c1.9-8.2,3.1-12.6,4-21c4.7,4.6,9.6,9.2,17,9c-0.1-4.7,1.5-12-1-17c-3.1-2.7-11.6-9.7-14-10
c0.2-4.3,0.6-11.5,2-19c1.7-8.8,6.5-20.2,7-30c0.3-6.5-3.1-13.2-4-15c-1-0.5-5.7-0.8-9-1c-3.4-0.2-5.5-0.1-7,1c-3.2-4-6-5-12-7
c-1,3-2.8,9.2-2,12c0,2,2.2,3.4,3,6c0.6,1.9,0,3.3,0,5c-13.5-0.3-24.7,0.9-38.1-0.9c-6.4-1.7-10.9-7.1-16.4-10.3
c-3-1.5-4.3-2.7-7.4-3.8c0-3-0.1-4.1,0-7c2.2,0,16.5,6.2,33,4C304.7,260.2,318.4,249.8,323.3,243.1z"/>
</g>
<g>
<path class="st1 state" data-state="Some text 2" d="M560.8,149.4c2.5-2.3,5.8-0.3,8.3,0.8c4.8,2.6,10.2,4.3,14.6,7.5c4.1,3.8,7.9,8.7,13.7,9.9
c9.8,1.4,20.1,0.2,29.5,4c4.4,2.9,7.9,6.9,11.5,10.7c5.3,5.7,6.8,13.6,10.4,20.3c1.7,3.5,6,3.9,9.1,5.4
c7.7,2.7,14.5,7.7,22.3,10.1c7.9,2.6,14.6,7.5,22.3,10.6c14.5,4.7,28.3,11.5,40.5,20.6c5.8,4.2,12.9,6.8,17.7,12.3
c1.8,2.1-0.6,4.6-1.2,6.6l-0.3,0.7c-4,7.6-5,16.7-10.4,23.5c-5,5.5-12.9,6.4-19.6,8.6c-0.9,5.4-1.7,10.9-2.3,16.3l-0.2,0.9
c4.7,1,9.4,1.9,14.1,2.8c-1.8,2.8-3.5,6.1-6.8,7.3c-3.9,1.3-8,1.6-11.8,2.7c-0.4,2.2-1.2,6.5-1.6,8.7c8.6,0.1,17.3,0.3,25.9,0.5
c0.1,4.6,0.2,9.2-0.9,13.7c-5.8,3.5-4.9,11.1-6,16.9c-8.8,0.4-13.9-7.6-21.8-9.6c-3.3,6.2-5,13-5.7,20c-4.9-2.8-9.9-5.1-15-7.3
c-1.3-0.7-2.7-1.1-4.1-0.9c-10.5,0.6-21.1,1-31.6,1.1c0-0.8,0-2.5,0-3.3c3.1-1.8,6.3-3.4,9.5-5.1c-0.9-3.9-0.8-9.2-4.7-11.4
c-5.3-1.1-5.9,6-8,9.5c-5.8-2.1-11.8-3.2-17.9-3.3c-1.2,0-2.4,0-3.5,0c-4.7,0.1-9.8,0.2-14,2.6c-2,3.2-2,7.4-4.5,10.3
c-6.2,0-12.3-0.9-18.5-0.7c-3.2,0.4-5.9,2.5-9.2,2.7c-1.8-0.6-3.3-1.9-5-3l-0.1-1c-0.1-1.5-0.1-3.1-0.1-4.6
c-7,0.1-14.5-1.5-20.9,1.9c-4.1,1.7-7.8,4.3-10.8,7.5c-2.6,0.5-5.2,0.9-7.9,1.2c-2.1-4.5-2.6-9.5-5.2-13.8
c-5.6-6.1-17.8-7.5-18.2-17.5c5.1-6,12.5-10.2,20.3-11.6c-0.7-4.3-2.1-8.8-5.3-11.9c-6.3-3.8-7.1,6.6-13.2,5
c-11.8,0.7-23.6-4.6-32.9-11.5c-0.1-0.5-0.3-1.5-0.3-2c-0.1-0.4-0.3-1.1-0.3-1.5c-6.4-0.6-14.1,2.5-19.3-2.5
c-4.7-3.5-7.5-8.9-12.3-12.4c-1-0.8-2-1.6-3.1-2.3c4.1-1.9,8.6-3.8,11-7.8c3.7-6.2,5.3-13.5,5.5-20.6c0-1.1-0.4-2-1.1-2.9
c-4.3-1.4-9.3-0.3-13.4-2.5c-5-7.2-6.1-16.3-10.9-23.5c-6.8-0.3-13.5,0.7-20.1,1.9c-1.3-7.6,1-17.9-6.4-23.1
c-0.3-0.8-0.7-1.6-1.1-2.4c-3.8-6.3-5.6-13.3-5.5-20.7c4,0.2,8.1,0.6,12.2,0.9c2.4,0.2,4.8,0.5,7.3,0.7c0.4,0,1.2,0.1,1.6,0.2
c2.4-3,5.5-5.4,7.8-8.5c1-2,2.2-6.4,0.7-9.3c-1.5-2.8-3.7-3.8-5-4c-1-2-1-2-1-4c12.6-0.7,24.7-1.5,37.2-2.9c4.6,0,9,1.4,13.6,1.8
c3.4,0.4,6.8,0.7,10.2,1.1l0.9,0.1c2.8,0.7,5.6,1.3,8.4,1.8c1.2-6,2.6-12,3.9-18c1.3,0.1,2.5,0.3,3.8,0.5c1.4,4.2,0.4,9.6,3.5,13
c4.7,2.6,10.3,0.6,15.3,0.3c6.2-0.7,10.3-5.9,15.5-8.8C554,156.6,557.1,152.7,560.8,149.4z M560.5,180.6"/>
</g>
</svg>
Try removing from the SVG header style =" enable-background: new 0 0 1080 700; " xml: space = "preserve"
Modern browsers don't handle this right now.
Specify the fill color explicitly - <path fill="dodgerblue"
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 1080 700">
<g>
<path fill="dodgerblue" class="st0 state" data-state="Some text 1" d="M323.3,243.1c8,5,22.6,10,30,12c7.2,1.3,6.9-0.8,14-2c6.6,6.6,18.8,8.9,24,17c2.9,4.3,3.9,7.1,5.6,12.1
c2.9,11.4,12.6,20.4,11.2,32.9c-2.7-0.1-5.4-0.2-8-0.2c-2.6-8.5-5.6-17-7.2-25.8c-3.5,0-9.1-0.1-12.6,0c-2,5-6.4,8.3-8,13
c1,2,4.1,3.9,6,5c1,8.5,8.8,19.2,1.5,26.5c-4.9,5.4-2.2,13.4,1.1,19c5.9,9.3-0.7,18.2-3.6,27.5c-9.9-0.7-18.6-3.6-24-11.8
c-6-0.2-10.9-1.3-17-1.2c1.9-8.2,3.1-12.6,4-21c4.7,4.6,9.6,9.2,17,9c-0.1-4.7,1.5-12-1-17c-3.1-2.7-11.6-9.7-14-10
c0.2-4.3,0.6-11.5,2-19c1.7-8.8,6.5-20.2,7-30c0.3-6.5-3.1-13.2-4-15c-1-0.5-5.7-0.8-9-1c-3.4-0.2-5.5-0.1-7,1c-3.2-4-6-5-12-7
c-1,3-2.8,9.2-2,12c0,2,2.2,3.4,3,6c0.6,1.9,0,3.3,0,5c-13.5-0.3-24.7,0.9-38.1-0.9c-6.4-1.7-10.9-7.1-16.4-10.3
c-3-1.5-4.3-2.7-7.4-3.8c0-3-0.1-4.1,0-7c2.2,0,16.5,6.2,33,4C304.7,260.2,318.4,249.8,323.3,243.1z"/>
</g>
<g>
<path fill="dodgerblue" class="st1 state" data-state="Some text 2" d="M560.8,149.4c2.5-2.3,5.8-0.3,8.3,0.8c4.8,2.6,10.2,4.3,14.6,7.5c4.1,3.8,7.9,8.7,13.7,9.9
c9.8,1.4,20.1,0.2,29.5,4c4.4,2.9,7.9,6.9,11.5,10.7c5.3,5.7,6.8,13.6,10.4,20.3c1.7,3.5,6,3.9,9.1,5.4
c7.7,2.7,14.5,7.7,22.3,10.1c7.9,2.6,14.6,7.5,22.3,10.6c14.5,4.7,28.3,11.5,40.5,20.6c5.8,4.2,12.9,6.8,17.7,12.3
c1.8,2.1-0.6,4.6-1.2,6.6l-0.3,0.7c-4,7.6-5,16.7-10.4,23.5c-5,5.5-12.9,6.4-19.6,8.6c-0.9,5.4-1.7,10.9-2.3,16.3l-0.2,0.9
c4.7,1,9.4,1.9,14.1,2.8c-1.8,2.8-3.5,6.1-6.8,7.3c-3.9,1.3-8,1.6-11.8,2.7c-0.4,2.2-1.2,6.5-1.6,8.7c8.6,0.1,17.3,0.3,25.9,0.5
c0.1,4.6,0.2,9.2-0.9,13.7c-5.8,3.5-4.9,11.1-6,16.9c-8.8,0.4-13.9-7.6-21.8-9.6c-3.3,6.2-5,13-5.7,20c-4.9-2.8-9.9-5.1-15-7.3
c-1.3-0.7-2.7-1.1-4.1-0.9c-10.5,0.6-21.1,1-31.6,1.1c0-0.8,0-2.5,0-3.3c3.1-1.8,6.3-3.4,9.5-5.1c-0.9-3.9-0.8-9.2-4.7-11.4
c-5.3-1.1-5.9,6-8,9.5c-5.8-2.1-11.8-3.2-17.9-3.3c-1.2,0-2.4,0-3.5,0c-4.7,0.1-9.8,0.2-14,2.6c-2,3.2-2,7.4-4.5,10.3
c-6.2,0-12.3-0.9-18.5-0.7c-3.2,0.4-5.9,2.5-9.2,2.7c-1.8-0.6-3.3-1.9-5-3l-0.1-1c-0.1-1.5-0.1-3.1-0.1-4.6
c-7,0.1-14.5-1.5-20.9,1.9c-4.1,1.7-7.8,4.3-10.8,7.5c-2.6,0.5-5.2,0.9-7.9,1.2c-2.1-4.5-2.6-9.5-5.2-13.8
c-5.6-6.1-17.8-7.5-18.2-17.5c5.1-6,12.5-10.2,20.3-11.6c-0.7-4.3-2.1-8.8-5.3-11.9c-6.3-3.8-7.1,6.6-13.2,5
c-11.8,0.7-23.6-4.6-32.9-11.5c-0.1-0.5-0.3-1.5-0.3-2c-0.1-0.4-0.3-1.1-0.3-1.5c-6.4-0.6-14.1,2.5-19.3-2.5
c-4.7-3.5-7.5-8.9-12.3-12.4c-1-0.8-2-1.6-3.1-2.3c4.1-1.9,8.6-3.8,11-7.8c3.7-6.2,5.3-13.5,5.5-20.6c0-1.1-0.4-2-1.1-2.9
c-4.3-1.4-9.3-0.3-13.4-2.5c-5-7.2-6.1-16.3-10.9-23.5c-6.8-0.3-13.5,0.7-20.1,1.9c-1.3-7.6,1-17.9-6.4-23.1
c-0.3-0.8-0.7-1.6-1.1-2.4c-3.8-6.3-5.6-13.3-5.5-20.7c4,0.2,8.1,0.6,12.2,0.9c2.4,0.2,4.8,0.5,7.3,0.7c0.4,0,1.2,0.1,1.6,0.2
c2.4-3,5.5-5.4,7.8-8.5c1-2,2.2-6.4,0.7-9.3c-1.5-2.8-3.7-3.8-5-4c-1-2-1-2-1-4c12.6-0.7,24.7-1.5,37.2-2.9c4.6,0,9,1.4,13.6,1.8
c3.4,0.4,6.8,0.7,10.2,1.1l0.9,0.1c2.8,0.7,5.6,1.3,8.4,1.8c1.2-6,2.6-12,3.9-18c1.3,0.1,2.5,0.3,3.8,0.5c1.4,4.2,0.4,9.6,3.5,13
c4.7,2.6,10.3,0.6,15.3,0.3c6.2-0.7,10.3-5.9,15.5-8.8C554,156.6,557.1,152.7,560.8,149.4z M560.5,180.6"/>
</g>
</svg>
You cannot show .svg images in iOS OS below 13.
From Apple's Xcode 12 release notes:
Asset Catalogs New Features Added support for Scalable Vector Graphic
(SVG) image assets. These preserve their vector representation with
deployment targets of macOS 10.15 or later, iOS 13 or later, and
iPadOS 13 or later. (18389814)
However you can use libraries eg: https://github.com/mchoe/SwiftSVG. But this doesn't not gurantee loading all types of svg images.

Image slicing with SVG images not working on Xcode12

Xcode 12 just introduced SVG image support and I've been using them without major problems, however when I tried image slicing the chat bubbles so they stretch correctly depending on the number of characters in the text message, it doesn't seem to work, can't find anything on stackoverflow or apple forum yet so just wondering if anyone knows if it is a known issue or Xcode 12 bug?
This is the chat bubble SVG:
<svg width="206" height="80" viewBox="0 0 206 80" fill="none" xmlns="http://www.w3.org/2000/svg">
<rect x="20.4998" y="16" width="161.484" height="40" rx="20" fill="lightseagreen"/>
<path d="M186 56C175.984 56 169.984 55 169.984 46H177.984C177.984 50.0156 176.984 52 186 56Z" fill="lightseagreen"/>
</svg>
How it looks in Xcode assets:
When I click 'Show slicing' here's how it looks:
Compare to the usual 'Show slicing' of PNG images which are working fine:
Thanks

More compressed version of ppm or bmp?

I am adding a layer over my video stream with custom drawn graphics, but when I save the drawn layer for my current frame I have a pretty big file (~10MB). When analyzing the data, it's mostly 0's (representing the actual pixels of the video and not the drawn layer). I understand that PPM and BMP files will inherently be pretty sizable files, but is there a way to handle the repetitiveness of 0's? Is there a different file format I should be checking out?
Here's a "blocky", computer graphics type of overlay with 1182x862 pixels.
Here are the sizes it come out as in the other formats you might like to try:
-rw-r--r--# 1 mark staff 3056668 24 Nov 08:49 overlay.ppm
-rw-r--r--# 1 mark staff 23699 24 Nov 08:49 overlay.gif
-rw-r--r-- 1 mark staff 134723 24 Nov 08:49 overlay.pcx
-rw-r--r--# 1 mark staff 22585 24 Nov 08:48 overlay.png
Be aware that they all have some tradeoffs. Whilst PNG is smallest, it is likely to take longer to write. GIF acquits itself pretty well, but will do poorly if you have too many colours. PCX is a bit archaic, but usable. PPM is large and directly proportional in size to your overlay size.
Note that if your overlays really are very blocky, you could consider reducing them to 1/4 their height and width and make them 16x smaller in volume if you can handle a couple of pixels inaccuracy when scaling back up.
You could also consider generating the overlay in a vector format which should be many, many times smaller in size.
Lifted straight form the documentation from DrawSvg, here is an SVG vector example:
#!/usr/bin/env python3
import drawSvg as draw
d = draw.Drawing(200, 100, origin='center', displayInline=False)
# Draw an irregular polygon
d.append(draw.Lines(-80, -45,
70, -49,
95, 49,
-90, 40,
close=False,
fill='#eeee00',
stroke='black'))
# Draw a rectangle
r = draw.Rectangle(0,0,40,50, fill='#1248ff')
r.appendTitle("Our first rectangle") # Add a tooltip
d.append(r)
# Draw a circle
d.append(draw.Circle(-40, -10, 30,
fill='red', stroke_width=2, stroke='black'))
# Draw an arbitrary path (a triangle in this case)
p = draw.Path(stroke_width=2, stroke='green',
fill='black', fill_opacity=0.5)
p.M(-30,5) # Start path at point (-30, 5)
p.l(60,30) # Draw line to (60, 30)
p.h(-70) # Draw horizontal line to x=-70
p.Z() # Draw line to start
d.append(p)
# Draw multiple circular arcs
d.append(draw.ArcLine(60,-20,20,60,270,
stroke='red', stroke_width=5, fill='red', fill_opacity=0.2))
d.append(draw.Arc(60,-20,20,60,270,cw=False,
stroke='green', stroke_width=3, fill='none'))
d.append(draw.Arc(60,-20,20,270,60,cw=True,
stroke='blue', stroke_width=1, fill='black', fill_opacity=0.3))
# Draw arrows
arrow = draw.Marker(-0.1, -0.5, 0.9, 0.5, scale=4, orient='auto')
arrow.append(draw.Lines(-0.1, -0.5, -0.1, 0.5, 0.9, 0, fill='red', close=True))
p = draw.Path(stroke='red', stroke_width=2, fill='none',
marker_end=arrow) # Add an arrow to the end of a path
p.M(20, -40).L(20, -27).L(0, -20) # Chain multiple path operations
d.append(p)
d.append(draw.Line(30, -20, 0, -10,
stroke='red', stroke_width=2, fill='none',
marker_end=arrow)) # Add an arrow to the end of a line
d.setPixelScale(2) # Set number of pixels per geometry unit
#d.setRenderSize(400,200) # Alternative to setPixelScale
d.saveSvg('example.svg')
d.savePng('example.png')
That comes up as 14,202 bytes of PNG or 1,348 bytes of SVG - so the vector graphics are a massive 10x smaller!
-rw-r--r-- 1 mark staff 1348 24 Nov 10:01 example.svg
-rw-r--r-- 1 mark staff 14202 24 Nov 10:01 example.png
Here is the SVG:
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
width="400" height="200" viewBox="-100.0 -50.0 200 100">
<defs>
<marker markerWidth="4.0" markerHeight="4.0" viewBox="-0.1 -0.5 1.0 1.0" orient="auto" id="d0">
<path d="M-0.1,0.5 L-0.1,-0.5 L0.9,0 Z" fill="red" />
</marker>
</defs>
<path d="M-80,45 L70,49 L95,-49 L-90,-40" fill="#eeee00" stroke="black" />
<rect x="0" y="-50" width="40" height="50" fill="#1248ff">
<title>Our first rectangle</title>
</rect>
<circle cx="-40" cy="10" r="30" fill="red" stroke-width="2" stroke="black" />
<path d="M-30,-5 l60,-30 h-70 Z" stroke-width="2" stroke="green" fill="black" fill-opacity="0.5" />
<circle cx="60" cy="20" r="20" stroke-dasharray="73.30382858376184 52.35987755982988" stroke-dashoffset="-31.41592653589793" stroke="red" stroke-width="5" fill="red" fill-opacity="0.2" />
<path d="M70.0,2.679491924311229 A20,20,0,1,0,59.99999999999999,40.0" stroke="green" stroke-width="3" fill="none" />
<path d="M59.99999999999999,40.0 A20,20,0,1,1,70.0,2.679491924311229" stroke="blue" stroke-width="1" fill="black" fill-opacity="0.3" />
<path d="M20,40 L20,27 L0,20" stroke="red" stroke-width="2" fill="none" marker-end="url(#d0)" />
<path d="M30,20 L0,10" stroke="red" stroke-width="2" fill="none" marker-end="url(#d0)" />
</svg>
If you want to experiment yourself with your actual data, try ImageMagick in the Terminal. You can convert from PPM to PNG like this:
magick input.ppm output.png
or from PPM to quarter-height and quarter-width GIF like this:
magick input.ppm -scale 25% result.gif
Note that ImageMagick will not convert to SVG - as it is a raster graphics program, and rasterises everything before it even starts. It will convert from SVG to raster though.

Why is SVG path occasionally drawn incorrectly in this piechart?

I'm trying to create SVG piecharts in a Rails app. I've written a method that works most of the time, but occasionally produces an odd result.
This chart is being built correctly, except for 1 segment!
The SVG code that produces that segment is
<path d='M0,0 L99.99949084376563,0.3191096796332688 A100,100 0 **0,0** 99.99893303088741,0.46194445996738664 Z' fill='#136F7F' />
And I think the cause of the problem may be the values I've wrapped with ** (The stars are not present in the actual code!).
I'm building the chart with the following method, where supplies data as a hash of key-value pairs.
svg = "<svg viewBox='-100 -100 200 200'>"
data.each do |d|
svg += "<path d='M0,0 L#{previous_x},#{previous_y} A100,100 0 #{x <= 0 ? 1 : 0},#{y <= 0 ? 1 : 0} #{x},#{y} Z' fill='#{col[i]}' fill-opacity='1' />"
end
svg += "</svg>"
x and y are the cosine and sine of the segment's angle in radians, multiplied by 100.
Am I setting the correct large-arc-flag and sweep-flag values, and are these what is causing the occasional segment to fail?
There are 4 possible solution for arcs connecting two points.
In the image below
the blue arcs are drawn counter clockwise, the green arcs clockwise (sweep flag)
the small blue arch is drawn counter clockwise around the center of the green circle
the large blue arch is drawn counter clockwise around the center of the bleu circle.
the small green arch is drawn clockwise around the center of the blue circle
the large green arch is drawn cclockwise around the center of the green circle
the darker arcs are small arcs, the lighter arcs are large arcs (large-arc flag)
to tell the render which arc you want, you use a combination of large-arc and sweep flag. The sweep flag determines the direction (clockwise, counter clockwise) the large arc flag deteremines the size (large arch, small arc)
<svg width="200" height="200" viewBox="-150 -250 400 400">
<g fill="none" stroke="black" stroke-width="5">
<path d="M25.88 -96.59 A100 100 0 0 0 96.59 -25.88" stroke="darkblue" />
<path d="M25.88 -96.59 A100 100 0 1 0 96.59 -25.88" stroke="lightblue" />
<path d="M25.88 -96.59 A100 100 0 0 1 96.59 -25.88" stroke="darkgreen" />
<path d="M25.88 -96.59 A100 100 0 1 1 96.59 -25.88" stroke="lime" />
</g>
<g fill="red" stroke="red">
<circle cx="25.88" cy="-96.59" r="5" />
<circle cx="96.59" cy="-25.88" r="5" />
</g>
</svg>
<br/>
<ul>
<li>
the blue arcs are drawn counter clockwise, the green arcs clockwise (sweep flag)
</li>
<li>
the small blue arch is drawn counter clockwise around the center of the green circle
</li>
<li>
the large blue arch is drawn counter clockwise around the center of the bleu circle.
</li>
<li>
the small green arch is drawn clockwise around the center of the blue circle
</li>
<li>
the large green arch is drawn cclockwise around the center of the green circle
</li>
<li>the darker arcs are small arcs, the lighter arcs are large arcs (large-arc flag)</li>
</ul>

How to get the accurate font size(height) in pdf

I have a sample pdf (attached), and it includes a text object and a rectangle object that have almost the same height. Then I checked the content of the pdf by using itextrup as below:
1 1 1 RG
1 1 1 rg
0.12 0 0 0.12 16 50 cm
q
0 0 m
2926 0 l
2926 5759 l
0 5759 l
0 0 l
W
n
Q
1 1 1 RG
1 1 1 rg
q
0 0 m
2926 0 l
2926 5759 l
0 5759 l
0 0 l
W
n
/F1 205.252 Tf
BT
0 0 0 RG
0 0 0 rg
/DeviceGray CS
/OC /oc1 BDC
0 -1 1 0 1648 5330 Tm
0 Tc
100 Tz
(Hello World) Tj
ET
Q
q
0 0 m
2926 0 l
2926 5759 l
0 5759 l
0 0 l
W
n
0 0 0 RG
0 0 0 rg
/DeviceGray CS
6 w
1 j
1 J
1649 5324 m
1649 4277 l
1800 4277 l
1800 5324 l
1649 5324 l
S
EMC
Q
Obviously the user space matrix is determined by [0.12 0 0 0.12 16 50], and the height for the rectangle is (1800-1649)*0.12*1=18.12, and for the font size I use 205.252*0.12=24.63024. Since the two values are not close, my problem is how to get the height/size of the font?
sample.pdf
OK - I took a look at your file and you're basically hosed. That's the scientific answer, now let me clarify :)
Bad PDF!
The PDF you have up there as a sample contains a font that is not embedded. That "/F1 Tf" command you have there points to the font "ArialMT" in the resources dict for that page. Because the font has not been embedded, you only have two options:
Try to find the actual font on the system and extract the necessary information from there.
Live with the information in the PDF. Let's start with that.
Font Descriptor
Here is an image from pdfToolbox examining the font in the PDF file (caution: I'm associated with this tool):
I've cut off some of the "Widths" table, but other than that this is all of the information you have in the PDF document for this font. And this means you can access the widths for each glyph, but you don't have access to the heights of each glyph. The only information you have regarding heights is the font bounding box which is the union of all glyph bounding boxes. In other words, the font bounding box is guaranteed to be big enough to contain any glyph from the font (both horizontally and vertically).
System Information
You don't say why you need this information so it becomes a little harder to advise further. But if you can't get the information from the PDF, you're only option is to live with the inaccurate information from the PDF or to turn to the system your code is running on to get you more.
If you have the ArialMT font installed, you could basically try to find the font file and then parse the TrueType font file to find the bounding boxes for each glyph. I've done that, it's not funny.
Or you can see if your system can't provide you with the information in a better way. Many operating systems / languages have text calls that can get accurate measurements for you. If not, you can brute force it by rendering the text you want in black on a white image and then examining the pixels to see where you hit and thus how big the largest glyph in your text string was.
Wasteful though that last option sounds, it's probably the quickest and easiest to implement and it - depending on your needs - may actually be the best option all around.
I have a sample pdf (attached), and it includes a text object and a rectangle object that have almost the same height.
Indeed, your PDF is displayed like this:
But looking at this one quickly realizes that the glyphs in your text "Hello World" do not extend beneath the base line like a 'g', 'j' or some other glyphs would:
(The base line is the line through the glyph origins)
Since the two values are not close, my problem is how to get the height/size of the font
Obviously the space required for such descenders beneath the base line must also be part of the font size.
Thus, it is completely correct and not a problem that the height of the box (18.12) is considerably smaller than the font size (24.63024).
BTW, this corresponds with the specification which describes a font size of 1 to be arranged so that the nominal height of tightly spaced lines of text is 1 unit, cf. section 9.2.2 "Basics of Showing Text" of ISO 32000-1. Tightly spaced lines obviously need to include not only glyph parts above the base line but also those below. Additionally it furthermore includes a small gap between such lines as even tightly spaced lines are not expected to touch each other.

Resources