none
Range Information Vertical Position Relative to Page - not always accurate RRS feed

  • Question

  • I am having a bit of an issue when returning the vertical position of a range relative to the page (using rng.Information(wdVerticalPositionRelativeToPage)). The horizontal version always seems to be correct, but the vertical position seems to be innacurate sometimes, especially when the paragraphs surrounding the range have differing before/after spacing.

    I am using the code below in vba to test this, it will draw a green line 100px wide at the top left and bottom left of the current selection:

    I noticed this particularly on a document where the TOC crosses 2 pages. TOC 1 has 6pt before and 0pt after, TOC 2 has 0pt before, 0pt after. Where the TOC cross the page boundary, the vertical position of the first link on the new page is incorrect.

    Sub SelCoordinates()
    
    Dim x, y, fSize, linkHeight
    
    'select the range to ensure that it is in view (to ensure correct calculation)
    Dim rng As Range: Set rng = Selection.Range
    rng.Select
    
    'Get the font size (the height of the box)
    fSize = rng.Characters.last.Font.Size
    'add on the height of hanging characters (g,y etc)
    linkHeight = fSize + (fSize / 6)
    
    'get the x and y positions
    y = rng.Information(wdVerticalPositionRelativeToPage)
    x = rng.Information(wdHorizontalPositionRelativeToPage)
    
    Dim shp As Shape
    'add the top line
    Set shp = ActiveDocument.Shapes.AddLine(x, y, x + 100, y)
    shp.Line.ForeColor.RGB = RGB(0, 255, 0) 'green
    
    'work out the vertical position of the bottom line
    y = y + linkHeight
    
    'add the bottom line
    Set shp = ActiveDocument.Shapes.AddLine(x, y, x + 100, y)
    shp.Line.ForeColor.RGB = RGB(255, 0, 0) 'red
    
    End Sub

    If anyone has experience getting fully accurate results from this function, some help here would be greatly appreciated.

    Thursday, June 4, 2015 1:15 PM

Answers

  • Hi Nick

    If this was a *.doc file, originally, then it's possible that the layout engine of the newer version is having difficulty interpreting the old information. Word's layout engine changes, and major modifications were made to it for 2013. If the results are "stable" when the document is saved to the native 2013 file format then that's what you'll have to do...


    Cindy Meister, VSTO/Word MVP, my blog

    Saturday, June 6, 2015 7:04 PM
    Moderator

All replies

  • Hi Nick,

    I am trying to reproduce this issue, however the code seems ok. Here is the figure for your reference:

    How did you select the words in Word for above test? And which version of Word are you using?

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, June 5, 2015 6:50 AM
    Moderator
  • HI Fei, Thanks for looking at this for me. I am using word 2013. It seems that if I 'save-as' using word 2013 into either .docx or .docm formats this problems goes away. The document is currently in .docm format, I think it was originally converted from a .doc format using word 2007.

    Quite frustrated with this as I keep getting inaccurate results and I cant figure out what is causing it!

    Friday, June 5, 2015 8:36 AM
  • Hi Nick

    If this was a *.doc file, originally, then it's possible that the layout engine of the newer version is having difficulty interpreting the old information. Word's layout engine changes, and major modifications were made to it for 2013. If the results are "stable" when the document is saved to the native 2013 file format then that's what you'll have to do...


    Cindy Meister, VSTO/Word MVP, my blog

    Saturday, June 6, 2015 7:04 PM
    Moderator
  • Thanks Cindy, do you have any idea how I can determine which layout engine is being used? Perhaps then I could alter the positioning algorithm based on the layout engine being used, or simply notify the user that they need to update the version before it gets converted.. I don't want to auto save-as word 2013 as I know this could change the layout of the document slightly and then I would get complaints that the converted PDF was not the same as the word document that was sent.

    Monday, June 15, 2015 12:38 PM
  • Hi Nick

    Querying the Word.Application.Version should be enough. I can't remember the layout engine being changed during the lifetime of a version, only between versions. One major change was 2003 to 2007 and then 2010 to 2013 (I doubt earlier changes are relevant...)


    Cindy Meister, VSTO/Word MVP, my blog

    Monday, June 15, 2015 5:58 PM
    Moderator
  • Hi Cindy,

    The Application.Version just seems to return the version of word that I have the document open in, not the version that was used to create the document.

    Also, when I checked the options the 'Lay out this document as if created in:' and it was set to Word 2010, I changed this to Word 2013 but changing this doesn't seem to have any effect unless I use 'Save-as'.

    Looking inside the XML package and using KDIFF3 to compare some of the xml files, quite a lot seems to have changed after the 'save-as'.

    Both docprops/app.xml files have the AppVersion as 15.000, but the character, line, word counts etc all seem to have changed.

    Also, inside the word folder, the number of header.xml and footer.xml files seems to have changed - e.g. there is now one per unique header and footer and not one per section that is not linked to previous.

    I cant find any underlying property that seems to indicate a difference between the document before I use 'save-as' and after. Even all of the namespace references in the document.xml are identical.

    Pretty stumped on this one, I might just have to warn the user that if their document was not created in Word 2013 then they may have issues with link positioning.

    Wednesday, June 17, 2015 10:44 AM
  • Well, the Application.Version does tell you which layout engine is being used, which is what you asked. You didn't ask me how to determine in which version of Word a document was created, which seems to be what you want to know...

    The only way to get this information is from the document's Word Open XML, as you've found - it's not available in either the UI or the object model. Closest you can get is the setting you discovered about what Layout to use, but that doesn't tell you for sure in which version of Word the document was created.

    Document.Content.WordOpenXML theoretically returns the entire document in the "flat file" form of Office Open XML, but I have noticed that this misses some things and have never checked whether AppVersion is included, although I expect it would be. I also don't know if it will return the original version while the document is open in 2013, but I expect it would.

    <<Even all of the namespace references in the document.xml are identical.>>

    They have to be, otherwise you wouldn't have backwards compatibility and it would become impossible to work with the Open XML file format...


    Cindy Meister, VSTO/Word MVP, my blog

    Wednesday, June 17, 2015 7:08 PM
    Moderator