none
Preset Smile becomes a Custom Smirk with when arrows applied RRS feed

  • Question

  • I'm looking to see if the PresetShapeDefinition of the smileyFace shape is different from how it is actually implemented.

    For example, if I insert a preset smileyFace and apply two arrows, both sides of the mouth have arrows. But when I use the very same definition for a custGeom, only one side of the mouth gets an arrow. Here's an image of this:

    Sorry, that image is huge. Anyway, here's a link to the PPTX that demonstrates issue.

    I guess what I'm looking for is one or more of the following answers:

    • Is the smileyFace definition incorrect and if so, what is the correct definition?
    • Is custGeom somehow rendered differently than preset and if so, how?
    • Are there any rules on arrows that apply differently between preset and custom shapes?

    While we're on the topic of arrows, notice in the second slide in that deck linked above that the preset shape of actionButtonSound (and a custGeom version of the same) both have arrows applied to them, but they don't appear. There are open paths to which arrows should be applied, but they're not, which leads me to believe there are certain rules that govern how arrows are applied, but I can't figure out what those rules should be - I thought it was whatever didn't have a closed/joined path, but that is obviously not it. Can you also provide this information on the valid conditions for arrows to appear/not appear?

    Todd


    Wednesday, February 6, 2019 6:45 AM

Answers

  • I'm almost 100% sure that this is not the way it's done in Office in the sense that we don't use drawingML XML for this shape and then just process it. We use direct drawing in code (I think I alluded to this earlier). 

    So you mentioned stroke. I thought I'd try converting the path to a stroke and this allowed me to remove the a:lnTo. I'm not aware of the GDI issue you mention but this seems a better workaround. Is there some reason this won't be acceptable:

                  <a:path stroke="1" extrusionOk="0">
                    <a:moveTo>
                      <a:pt x="x1" y="y2"/>
                    </a:moveTo>
                    <a:quadBezTo>
                      <a:pt x="hc" y="y5"/>
                      <a:pt x="x4" y="y2"/>
                    </a:quadBezTo>
                  </a:path>

    Tom

    Wednesday, February 27, 2019 3:27 AM
    Moderator

All replies

  • Hi Todd,

    Thank you for your question.  An engineer from the protocols team will contact you soon.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Wednesday, February 6, 2019 3:34 PM
    Moderator
  • Hey Todd, 

    Thanks for the question about the smileyFace preset shape. We have definitely had some issues with the preset shapes in the electronic inserts for ISO 29500 being out of sync with Office and have identified some of these in recent posts here. I will check out the smileyFace and see if that is also out of sync. If so, I'll provide you with the correct markup.

    Let me check that out first and then if the arrow issue is still observed, I'll check it out.

    Best regards,
    Tom Jebo 
    Sr Escalation Engineer
    Microsoft Open Specifications Support
    Wednesday, February 6, 2019 7:14 PM
    Moderator
  • Hi Tom,

    Just wanted to check in with you on this to see if you've made any progress in the shape definition and/or arrow application questions.

    Cheers,

    Todd

    Monday, February 11, 2019 6:16 PM
  • Hi Todd, 

    thanks for checking in. I found that this one isn't as straight forward as some of the previous shapes you found. I'm sure the actual difference in xml will be simple but we draw this one in code and it's kind of buried. I'll follow up soon. 

    Tom

    Monday, February 11, 2019 6:26 PM
    Moderator
  • Ok, so I think this one maybe a problem with the <a:quadBezTo> Bezier curve drawing command in conjunction with the headEnd/tailEnd commands. 

    I think the arc would work with these but for some reason the quadBezTo isn't. 

    Tuesday, February 26, 2019 10:42 PM
    Moderator
  • Thanks Tom. Is this something you're further confirming? I wouldn't know how to translate a quadBezTo into an arc. Even if we did that, I think the adjustments and guides would need to be re-written for the smile portion.
    Wednesday, February 27, 2019 12:33 AM
  • One approach would be to change to a:arcTo but that could be a lot more tricky since there's an adjust handle on the curve. I'm trying to determine if there's some problem with our quadBezTo processing or what the behavior is here. I added another quadBezTo and it picked up the headEnd terminator while the second quadBezTo got the tailEnd terminator. 


    Wednesday, February 27, 2019 12:46 AM
    Moderator
  • I was able to get the headEnd and tailEnd properly placed on the quadBezTo by adding a lnTo (no movement at all) after the moveTo.


                  <a:path fill="none" extrusionOk="0">
                    <a:moveTo>
                      <a:pt x="x1" y="y2"/>
                    </a:moveTo>
    			 <a:lnTo>
    				<a:pt x="x1" y="y2"/>
    			 </a:lnTo>
                    <a:quadBezTo>
                      <a:pt x="hc" y="y5"/>
                      <a:pt x="x4" y="y2"/>
                    </a:quadBezTo>
                  </a:path>

    I think what was happening is for some reason the quadBezTo is not opening a path (or closing one depending on where the quadBezTo is placed). 

    I don't see a difference between the preset shape and this one now. Do you want to test this and see if you agree? Then I can submit this as replacement for this shape in a defect report. 

    Tom

    Wednesday, February 27, 2019 1:44 AM
    Moderator
  • Hi Tom,

    I'm concerned that this workaround isn't the actual way things are done in the original. This looks like it is intentionally introduces that OutOfMemoryException bug in GDI+ for GraphicsPath.Widen with two points be in the same. The reason I bring up GDI+ and the Widen method is because arrowheads appear to be based off of CustomLineCap in GDI+. When converting to another format, the stroke, which would include the arrowhead, will often become a stroke path. XPS does this. Having these two points be the same would cause that exception. Another reason I bring it up, although I can't be 100% certain is I'm thinking the original format uses GDI or GDI+ to draw these definitions, and if that is the case, it definitely wouldn't work. Not sure why this font became small.

    Wednesday, February 27, 2019 2:32 AM
  • I'm almost 100% sure that this is not the way it's done in Office in the sense that we don't use drawingML XML for this shape and then just process it. We use direct drawing in code (I think I alluded to this earlier). 

    So you mentioned stroke. I thought I'd try converting the path to a stroke and this allowed me to remove the a:lnTo. I'm not aware of the GDI issue you mention but this seems a better workaround. Is there some reason this won't be acceptable:

                  <a:path stroke="1" extrusionOk="0">
                    <a:moveTo>
                      <a:pt x="x1" y="y2"/>
                    </a:moveTo>
                    <a:quadBezTo>
                      <a:pt x="hc" y="y5"/>
                      <a:pt x="x4" y="y2"/>
                    </a:quadBezTo>
                  </a:path>

    Tom

    Wednesday, February 27, 2019 3:27 AM
    Moderator
  • Thanks Tom. I'll have to test this find out. With a computer crash last night and only phone access, I might not get to this for three days to a week. If it's okay to leave this open until I have a chance to test that would be great. At that time, I'll also test other quadBezes to see if it is this command or something else.
    Wednesday, February 27, 2019 4:13 AM
  • Of course, Todd, take your time. We don't close these forum issues just try to mark them as answered once you confirm. We can always field your questions.

    Tom

    Wednesday, February 27, 2019 5:12 AM
    Moderator