none
Preset shapes for .ppt RRS feed

  • Question

  • Hi,

    we have a working implementation on how to render preset shapes in .pptx in Apache POI, but I don't understand how to apply and calculate preset shapes in .ppt.

    So lets have a look at the hexagon files in the Apache POI bug report - the .pptx snipplet is in [1] below and the .ppt records in [2]

    As I couldn't find any other reference for preset shapes, I've used the same definition for .pptx and .ppt.

    a) is there any other public reference material for preset shapes for the BIFF formats?

    If you look at the definition of hexagon in the preset shapes, the "adj" and "vf" adjust values can be specified, which is used by [1] and rendered as [3]. But in [2] only the "adj" is set, which results in the image rendered as [4].

    b) if a) is correct, how is adj value of 8635 (.ppt) differently handled opposed the adj value of 39977 (.pptx)?

    For your calculation/explanation please simply propose similar anchor settings and simplification where necessary.

    Thank you for taking the time.

    Best wishes,
    Andi

    [1] Hexagon reference in .pptx:

    <p:nvSpPr>
        <p:cNvPr id="4" name="Hexagon 3"/>
        <p:cNvSpPr/>
        <p:nvPr/>
    </p:nvSpPr>
    <p:spPr>
        <a:xfrm>
            <a:off x="4015818" y="2290713"/>
            <a:ext cx="923827" cy="1338608"/>
        </a:xfrm>
        <a:prstGeom prst="hexagon">
            <a:avLst>
                <a:gd fmla="val 39977" name="adj"/>
                <a:gd fmla="val 115470" name="vf"/>
            </a:avLst>
        </a:prstGeom>
    </p:spPr>
    

    [2] Hexagon reference in .ppt

    The OfficeArtFSP record in POIs class structure:

    {
        "Class": "class org.apache.poi.ddf.EscherSpRecord",
        "Instance": 9, /*0x9*/
        "Version": 2, /*0x2*/
        "ContainerRecord": false,
        "RecordSize": 16, /*0x10*/
        "RecordId": -4086, /*0xff6*/
        "Options": 146, /*0x92*/
        "RecordName": "Sp",
        "Flags": 2560, /*0xa00*/
        "ShapeId": 2050, /*0x802*/
        "ShapeType": 9 /*0x9*/
    }
    

    The OfficeArtFOPT record in POIs class structure:

    {
        "Class": "class org.apache.poi.ddf.EscherOptRecord",
        "Instance": 12, /*0xc*/
        "Version": 3, /*0x3*/
        "ContainerRecord": false,
        "RecordSize": 100, /*0x64*/
        "RecordId": -4085, /*0xff5*/
        "Options": 195, /*0xc3*/
        "RecordName": "Opt",
        "EscherProperties": [
            "propNum: 127, RAW: 0x007F, propName: protection.lockagainstgrouping, complex: false, blipId: false, value: 262144 (0x00040000)",
            "propNum: 128, RAW: 0x0080, propName: text.textid, complex: false, blipId: false, value: 279067280 (0x10A23A90)",
            "propNum: 135, RAW: 0x0087, propName: text.anchortext, complex: false, blipId: false, value: 1 (0x00000001)",
            "propNum: 191, RAW: 0x00BF, propName: text.sizetexttofitshape, complex: false, blipId: false, value: 393216 (0x00060000)",
            "propNum: 327, RAW: 0x0147, propName: geometry.adjustvalue, complex: false, blipId: false, value: 8635 (0x000021BB)",
            "propNum: 385, RAW: 0x0181, propName: fill.fillcolor, complex: false, blipId: false, value: 134217732 (0x08000004)",
            "propNum: 447, RAW: 0x01BF, propName: fill.nofillhittest, complex: false, blipId: false, value: 1048592 (0x00100010)",
            "propNum: 448, RAW: 0x01C0, propName: linestyle.color, complex: false, blipId: false, value: 10252609 (0x009C7141)",
            "propNum: 459, RAW: 0x01CB, propName: linestyle.linewidth, complex: false, blipId: false, value: 12700 (0x0000319C)",
            "propNum: 511, RAW: 0x01FF, propName: linestyle.nolinedrawdash, complex: false, blipId: false, value: 524296 (0x00080008)",
            "propNum: 896, propName: groupshape.shapename, complex: true, blipId: true, name: 'Hexagon 3', data: \n00: 48, 00, 65, 00, 78, 00, 61, 00, 67, 00, 6F, 00, 6E, 00, 20, 00, 33, 00, 00, 00",
            "propNum: 959, RAW: 0x03BF, propName: groupshape.print, complex: false, blipId: false, value: 131072 (0x00020000)"
        ],
        "PropertiesSize": 92 /*0x5c*/
    }
    

    The OfficeArtClientAnchor

    {
        "Class": "class org.apache.poi.ddf.EscherClientAnchorRecord",
        "Instance": 0, /*0x0*/
        "Version": 0, /*0x0*/
        "ContainerRecord": false,
        "RecordSize": 16, /*0x10*/
        "RecordId": -4080, /*0xff0*/
        "Options": 0, /*0x0*/
        "RecordName": "ClientAnchor",
        "Dx2": 0, /*0x0*/
        "Row2": 0, /*0x0*/
        "Dy2": 0, /*0x0*/
        "Col1": 2530, /*0x9e2*/
        "Dx1": 3112, /*0xc28*/
        "Row1": 2286, /*0x8ee*/
        "Dy1": 0, /*0x0*/
        "Col2": 0, /*0x0*/
        "Flag": 1443 /*0x5a3*/
    }
    

    [3] .pptx image rendered


    [4] .ppt image rendered


    Saturday, May 4, 2019 12:05 PM

Answers

  • Hi kiwiwings,the values in binary format are relative to the viewBox, in most cases 0 0 21600 21600. The default 5400 is 1/4 of 21600. That corresponds to the default of 25000 with 25000/100000 from pptx. And 8635/21600=0.3997685 corresponds to 39977/100000.
    • Marked as answer by Kiwi-Wings Friday, May 10, 2019 9:46 AM
    Tuesday, May 7, 2019 8:49 PM
  • I think I found something :)

    https://blogs.technet.microsoft.com/seanearp/2008/02/16/microsoft-office-binary-file-format-specifications-released/

    The document for "Office Drawing 97-2007 Binary Format Specification" has formulas different to ECMAs formulas, e.g. see page 73 for hexagon. Those weren't covered in [MS-ODRAW]

    • Marked as answer by Kiwi-Wings Sunday, May 5, 2019 7:06 AM
    Saturday, May 4, 2019 12:55 PM

All replies

  • I think I found something :)

    https://blogs.technet.microsoft.com/seanearp/2008/02/16/microsoft-office-binary-file-format-specifications-released/

    The document for "Office Drawing 97-2007 Binary Format Specification" has formulas different to ECMAs formulas, e.g. see page 73 for hexagon. Those weren't covered in [MS-ODRAW]

    • Marked as answer by Kiwi-Wings Sunday, May 5, 2019 7:06 AM
    Saturday, May 4, 2019 12:55 PM
  • Kiwiwings,

    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

    Sunday, May 5, 2019 2:04 AM
    Moderator
  • Hi Andi, 

    I'm assuming you are now drawing custom shapes (custGeom) with fidelity to the Office preset shapes based on your marked answer in the last post. If so then great. 

    I wanted to follow up to confirm this and then also provide some feedback on a couple of things in your original post. 

    >>As I couldn't find any other reference for preset shapes, I've used the same definition for .pptx and .ppt.

    The most up to date reference should be the 2016 editions of the standard from either ECMA or ISO. Corrections should be coming to other shapes (not hexagon specifically) in future editions of ISO 29500 which will then be relayed to the ECMA 376.

    >>a) is there any other public reference material for preset shapes for the BIFF formats?

    [MS-ODRAW] and [MS-PPT] as you found are the binary format specifications. The older document you found is not officially part of the specification set we support in the Open Specifications forum or dochelp. Since we don't have these guides and adjust values included in the current Open Specifications, it's fair to refer to these. However, my concern is that the OOXML drawing inserts may need updating, if you're not seeing matching preset rendering.

    >>b) if a) is correct, how is adj value of 8635 (.ppt) differently handled opposed the adj value of 39977 (.pptx)?

    If you are not seeing the same preset rendering, I can look into the handling of the adjust values but I believe they are handled the same after conversion from XML to binary internally.

    Best regards,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications


    Monday, May 6, 2019 8:49 PM
    Moderator
  • Hi Tom,

    thank you for taking the time. I've just validated that the current [MS-PPT] and [MS-ODRAW] don't mention anything about the old autoshapes formulas.

    > I'm assuming you are now drawing custom shapes (custGeom) with fidelity to the Office preset shapes based on your marked answer in the last post.

    I'm not sure if we are talking about the same. Although we have .pptx files with custGeom elements in our test corpus, my concern was about preset shapes in .ppt. If you look for "hexagon" in [MS-PPT] or [MS-ODRAW], you'll find a few references, but not a formula describing on how to render it. Hence I originally thought, there's only the ECMA presetShapeDefinitions.xml file.

    > However, my concern is that the OOXML drawing inserts may need updating, if you're not seeing matching preset rendering.

    see above, it's not about OOXML - our OOXML renderer for .pptx is rendering more or less correct. <More or less> means, there are always issues with font metrics, but the generally logic on how the ECMA standard is to be implemented is there.

    > ... but I believe they are handled the same after conversion from XML to binary internally.

    I currently strongly doubt it, and therefore develop an alternative rendering part for the old .ppt files, to see if I'm right. But I would be more than happy, if you could explain me - based on the hexagon example - how to translate the .ppt adjust value (8635) to the .pptx ones (39977 / 115470), so I only need one shape engine.

    If you look at the old hexagon path, you see only references to @0 and @1, although there are a few other guides defined as well. The new hexagon path makes use of much more intermediate calculations. I probably haven't understood well enough, on how the old formulas work, but they look intriguingly different to me. ;)

    > The older document ... is not officially part of the specification set we support

    I'm ok with using current documents, if they would contain everything :)
    If my assumption would be right, then I would recommend to provide a reworked version of the autoshape appendix in MS-ODRAW.

    Best wishes,
    Andi

    Tuesday, May 7, 2019 12:22 AM
  • Andi, 

    (I was replying when you posted :) )

    Coming back to this after reviewing your Apache POI bug in more detail, I see that perhaps the POI HSLF value used was not the value that would match the initial rendering of the XSLF or OOXML presetShapeDefinition.xml provided example. 

    from your bug: "In the attached example, the adj value for HSLF is 8635 and for XSLF it's 39977."

    I think I have a better understanding of your problem now.

    Did you actually try the 5400 adj value you found in the historical document in your HSLF engine? If so was the result better?

    What I will do now is review the binary implementation in Office art code to see if the values we use correspond to the old document, I suspect they are at least ball park. When I said the same internally (in Office) I was thinking more in terms of our internalizing from XML to binary structs but I think in the end you're right that we would apply some conversion. I'll have to confirm that but the important thing for expedience would be to verify what values we are using that you can apply with HSLF.

    Is that correct?

    Tom

    Tuesday, May 7, 2019 12:39 AM
    Moderator
  • > Did you actually try the 5400 adj value you found in the historical document in your HSLF engine? If so was the result better?

    So 5400 is the default value and even farther away from 39977 - I haven't tried it, but I'm quite sure that the result will be worse. Currently Apache POI ignores adjust values for .ppt (not for .pptx), because the default ECMA value gives usually better results, but I have an urge to get it right :)

    > ... but the important thing for expedience would be to verify what values we are using that you can apply with HSLF. 
    > Is that correct?

    I guess yes ... I'm not sure how you'll check the office art code. I would probably start with the save/export code to .ppt and look for transformation stuff.

    Tuesday, May 7, 2019 8:06 PM
  • Hi kiwiwings,the values in binary format are relative to the viewBox, in most cases 0 0 21600 21600. The default 5400 is 1/4 of 21600. That corresponds to the default of 25000 with 25000/100000 from pptx. And 8635/21600=0.3997685 corresponds to 39977/100000.
    • Marked as answer by Kiwi-Wings Friday, May 10, 2019 9:46 AM
    Tuesday, May 7, 2019 8:49 PM
  • Thank you Regina, this sounds promising. Although I've already stired up the codebase (locally) a lot, I'll check if I can use the rule of three for length units. I guess degree adjust values will then have a similar correlation. So basically I have to go through the ECMA preset definitions and check which adjust value belongs to which unit type and map them accordingly.
    Wednesday, May 8, 2019 10:17 PM
  • OOXML angles are in 1/60000 degree. Binary format angles are in degree. But they are stored as fixed point numbers, which makes effectively a conversion with factor 65536.
    Wednesday, May 8, 2019 11:21 PM
  • Thank you Regina again ... after some tests I think the shapes are rendered correctly for .pptx and .ppt. I'm happy that I finally can close this POI issue.

    Friday, May 10, 2019 9:49 AM
  • Andi, 

    It sounds like you have what you need and Regina thanks for your input here. If you think that we should include the information you found in the binary file format Open Specifications [MS-ODRAW] I can make the suggestion. 

    Tom

    Friday, May 10, 2019 5:38 PM
    Moderator