none
'moon' preset shape cannot be reproduced based on definition/calculation RRS feed

  • Question

  • The 'moon' preset shape cannot be reproduced based on the definition.

    First of all, before describing that, there is an error in one of the guides. The stAng1 formula is written as:

    <gd name="stAng1" fmla="at2 dx  2 dy2" />

    I believe it should be written as ("dx 2" should be "dx2"):

    <gd name="stAng1" fmla="at2 dx2 dy2" />

    But given that the result doesn't produce a moon, I can't be 100% sure. But as I have no other value available, this is the value I'm using in the example.

    Using extents of 2540000h / 1270000 w (= value/12700 = 200x100 pixels h & w), the result is that the second arcTo of 'moon' produces the wrong end point of "100,-200" instead of the correct "100,200".

    It is the second arcTo (which I believe is the inner arc) that cannot be reproduced to have the corrected end point. The value ends up either the opposite (if w:h = 1:2) or something else entirely under different dimensions.

    The result looks like this (XAML), which is incorrect:

     

     <Path Canvas.Left="100" Canvas.Top="100" Stroke="#385D8A" StrokeThickness="2" StrokeLineJoin="Round" Fill="#4F81BD">
    
      <Path.Data>
    
      <GeometryGroup>
    
       <PathGeometry>
    
       <PathGeometry.Figures>
    
        <PathFigure IsClosed="True" StartPoint="100,200">
    
        <PathFigure.Segments>
    
         <ArcSegment IsLargeArc="False" SweepDirection="Clockwise" Size="100,100" Point="100,0"/>
    
         <ArcSegment IsLargeArc="False" SweepDirection="Counterclockwise" Size="125,125" Point="100,-200"/>
    
        </PathFigure.Segments>
    
        </PathFigure>
    
       </PathGeometry.Figures>
    
       </PathGeometry>
    
      </GeometryGroup>
    
      </Path.Data>
    
     </Path>
    
    

    Where as the correct one is:

     <Path Canvas.Left="100" Canvas.Top="100" Stroke="#385D8A" StrokeThickness="2" StrokeLineJoin="Round" Fill="#4F81BD">
    
      <Path.Data>
    
      <GeometryGroup>
    
       <PathGeometry>
    
       <PathGeometry.Figures>
    
        <PathFigure IsClosed="True" StartPoint="100,200">
    
        <PathFigure.Segments>
    
         <ArcSegment IsLargeArc="False" SweepDirection="Clockwise" Size="100,100" Point="100,0"/>
    
         <ArcSegment IsLargeArc="False" SweepDirection="Counterclockwise" Size="125,125" Point="100,200"/>
    
        </PathFigure.Segments>
    
        </PathFigure>
    
       </PathGeometry.Figures>
    
       </PathGeometry>
    
      </GeometryGroup>
    
      </Path.Data>
    
     </Path>

    This is just the difference of changing the Point="100,-200" in the second arc to Point="100,200".

    The calculation I'm using is relatively simple to get the end point. It's like this:

    • LastX = (last moveTo or arcTo x value)
    • LastY = (last moveTo or arcTo y value)
    • startAngle = (radian value from guide List)
    • sweepAngle = (radian value from guide List)
    • endAngle = (radian value of startAngle + sweepAngle)
    • startX = cos(startAngle) * wR
    • endX = cos(endAngle) * wR
    • startY = sin(startAngle) * hR
    • endX = sin(endAngle) * hR
    • X = ((LastX -startX) + endX)
    • Y = ((LastY -startY) + endY)

    On a value table of:

      

    var value cmd x y z   1st ArcTo  
    100           startAng 1.57
    h 200           sweepAng 3.14
    hd2 100           endAng 4.71
    ss 100           startX 0.00
    vc 100           startY 100.00
    adj 50000 val 50000       endX 0.00
    cd4 1.570796327           endY -100.00
    cd2 3.141592654           X 100.00
    r 100           Y 0.00
    b 200              
    a 50000 pin 0 adj 87500      
    g0 50 */ ss a 100000      
    g0w 50 */ g0 w ss      
    g1 50 +- ss 0 g0      
    g2 50 */ g0 g0 g1   2nd ArcTo  
    g3 200 */ ss ss g1   startAng 0.93
    g4 400 */ g3 2 1   sweepAng -8.14
    g5 350 +- g4 0 g2   endAng -7.21
    g6 300 +- g5 0 g0   startX 75.00
    g6w 300 */ g6 w ss   startY 100.00
    g7 175 */ g5 1 2   endX 75.00
    g8 125 +- g7 0 g0   endY -100.00
    dy1 125 */ g8 hd2 ss   X 100.00
    g10h -25 +- vc 0 dy1   Y -200.00
    g11h 225 +- vc dy1 0      
    g12 14.64538574 */ g0 9598 32768      
    g12w 14.64538574 */ g12 w ss      
    g13 85.35461426 +- ss 0 g12      
    q1 10000 */ ss ss 1      
    q2 7285.410175 */ g13 g13 1      
    q3 2714.589825 +- q1 0 q2      
    q4 52.10172574 sqrt q3          
    dy4 52.10172574 */ q4 hd2 ss      
    g15h 47.89827426 +- vc 0 dy4      
    g16h 152.1017257 +- vc dy4 0      
    g17w 250 +- g6w 0 g0w      
    g18w 125 */ g17w 1 2      
    dx2p 75 +- g0w g18w w      
    dx2 -75 */ dx2p -1 1      
    dy2 -100 */ hd2 -1 1      
    stAng1 0.927295218 at2 dx2 dy2        
    enAngp1 -0.927295218 at2 dx2 hd2        
    enAng1 -7.210480525 +- enAngp1 0 21600000      
    swAng1 -8.137775743 +- enAng1 0 stAng1      

    (sorry for the crummy table, but editing in this box is extremely hard). The value of the last end-point is impossible to be correct.

    Would this be something wrong with the any given guide, more than one of the guides, my calculation or...? This particular calculation for getting the end-point works fine on all shapes (except 'moon', 'cloud', 'cloudCallout' and possibly the circularArrow ones - still need to test the last ones)

    Appreciate anyone's time with this who may be able to provide insight/a solution.

    Sunday, February 27, 2011 1:57 AM

Answers

All replies

  • Terlo,

    Someone from our team will follow-up with you shortly in regards to your inquiry.

    Sunday, February 27, 2011 10:41 PM
  • Terlo,

    I am the engineer who has taken ownership of your inquiry. I am currentlying looking into this and will update you as things progress.

     

    Monday, February 28, 2011 8:43 PM
  • Terlo,

    I am still researching this for you, and I have nothing new to report at this time.

    Friday, March 11, 2011 3:05 PM
  • Thanks for the notification, looking forward to hearing from you.
    Friday, March 11, 2011 6:47 PM
  • Terlo,

    I am still looking into this one and have nothing new at this time.

    Monday, March 14, 2011 6:09 PM
  • Terlo,

    I am still investigating this one.

    Tuesday, March 22, 2011 2:29 PM
  • Terlo,

    Please review the following diagram: http://i.imgur.com/z77RN.png

    The second arc should be drawn from the last known pen postion. Since the first arc is drawn from the bottom right, the next arc needs to be drawn from the top down, thus the negative y.

    The shape definition works fine. You should revisit your calculations.

    I hope this helps.

    • Marked as answer by King Salemno Tuesday, March 22, 2011 7:45 PM
    • Unmarked as answer by Todd P Main Wednesday, March 23, 2011 2:10 AM
    Tuesday, March 22, 2011 7:43 PM
  • Thanks, I'll revisit my calculations to see if they are indeed the issue.

     

    You haven't yet confirmed if:

    <gd name="stAng1" fmla="at2 dx  2 dy2" />

    should be written as

    <gd name="stAng1" fmla="at2 dx2 dy2" />
     

    Wednesday, March 23, 2011 2:10 AM
  • Terlo,

    Yes, it should be written as in the second form.

    • Marked as answer by Todd P Main Wednesday, March 23, 2011 7:09 PM
    • Unmarked as answer by Todd P Main Tuesday, August 30, 2011 7:21 PM
    Wednesday, March 23, 2011 5:43 PM
  • Hi King, sorry to mark your last one as unanswer, but I have revisited all my calculations and I believe there may be an error in the moon definition. In particular, I believe that the value of dx2 should be dxp2 1 1 instead of dxp2 -1 1. Can you confirm this? No amount of looking for correct calculations works with the one with -1.
    Wednesday, August 31, 2011 12:04 AM
  • Hi Terlo, what version of the presetShapeDefinitions.xml file are you using? I just tested this in PowerPoint 2010 using the latest version of the presetShapeDefinitions.xml file from the 3rd edition (June 2011) of ECMA-376 and the moon shape renders exactly the same as the one that can be inserted from the Shapes menu. If I make the change that you suggested the shape renders twice as wide and is drawn outside of the bounding box, which I don't believe is correct.

     


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Thursday, September 8, 2011 6:07 PM
    Moderator
  • Thanks Josh for testing this. Not sure where their wrong, but I guess it may be my calculation then. Possibly it's that the shape deals with negative space.

     

    Also, thanks much on the tip of 3rd Edition - I didn't even know it was released. I'll be using that moving forward.

    Monday, September 12, 2011 4:10 PM