none
Why is the row so high? RRS feed

  • Question

  • Hi again;

    Please take a look at ATE-291.docx. The first 3 rows are higher than expected. The last 2 are as expected. What is causing the rows to be higher? Yet ATE-291_good.docx does not have the taller rows.

    This issue comes from a case where we have a DOCX where all the rows are thinner as expected. But when we create a new DOCX from it, it makes these rows higher. I've reduced it down to just this small sample. But what's weird is I look at the one displaying as expected and this one - and I can't find a difference.

    ??? - thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Saturday, October 28, 2017 1:24 PM

Answers

  • Hi Dave,

    As it turns out I just completed some of the additional investigation I was working on. Generating the table in HTML and then importing, or copying and pasting, did not generate an incorrect table state. The same is true for programmatic generation of a table.  

    Back to the original document. The table definition as-is, is incorrect and will cause Word 2016 to render with that space, unless the table is manually cleaned up. 

    Let me know if you want to me continue to look into this. 

    Will Gregg | open specifications

    • Marked as answer by DavidThi808 Tuesday, November 14, 2017 6:26 PM
    Tuesday, November 14, 2017 6:20 PM
    Moderator

All replies

  • Hi Dave,

    Thank you for contacting the open specifications forums.  A member of the Microsoft team will review and will respond here to assist further.

    Thanks again,
    Nathan Manis
    Open Protocols Specifications

    Saturday, October 28, 2017 4:03 PM
    Moderator
  • Hi Dave,

    Thanks for raising your question regarding the table row rendering. I will investigate the rendering behavior you are seeing and try to determine why the two documents are rendering differently with respect to those table rows being rending higher. 

    Will Gregg | open specifications

    Sunday, October 29, 2017 3:31 PM
    Moderator
  • Hi Dave,

    By comparing the two document.xml parts from ATE-291_good.DOCX and ATE-291.DOCX, which you provided. The two document.xml parts have extensive differences. As near as I can tell, ATE0291.DOCX is rendering properly based on the values that are defined within the table definition in the associated document.xml part, albeit not as you are expecting or desiring it to render.

    I am happy to generate a comparison report of the differences between the two document.xml parts of ATE-291.DOCX and ATE-291_good.DOCX if that would be of assistance to you. 

    Is ATE-291_good.DOCX the source DOCX file from which ATE-291.DOCX was created? If so, is the process by which you created the new document a process that I can replicate? I have created a new document from ATE-291_good.DOCX using Word 2016 (Open then Save As, and using ATE-291.DOCX as a template) and the resulting new document does not exhibit the table definition differences see between ATE-291_good.DOCX and ATE-291.DOCX.

    Will Gregg | open specifications

    Wednesday, November 1, 2017 7:45 PM
    Moderator
  • Hi;

    ATE-291.docx is a file we got from one of our customers. ATE-291_good.docx is I copied that and then pasted to a new document to see what would happen. That's all. So weird it's so different.

    The question/problem I have is why is the text spaced down in some of the cells. You can probably look at just ATE-291.docx and figure out why rows 1 - 3 have the spacing while rows 4 - 5 do not. I don't see any difference in them.

    ??? - thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Thursday, November 2, 2017 5:50 PM
  • Hi Dave,

    Thanks for the additional information and clarification on ATE-291.DOCX. I will take a look at why rows 4 & 5 do not have the same row settings as rows 1 - 3. 

    Will Gregg | open specifications

    Thursday, November 2, 2017 7:23 PM
    Moderator
  • Hi Will;

    Any update?

    thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Tuesday, November 7, 2017 5:03 PM
  • Hi Will;

    Ok, I figured out what the difference is. But I'm now stuck on what this all means.

    The difference is that some of the cells that are vertically merged have empty but sized paragraphs in the child vertically merged cells. One case is:

    				<w:tc>
    					<w:tcPr>
    						<w:tcW w:w="4700" w:type="dxa"/>
    						<w:gridSpan w:val="4"/>
    						<w:vMerge/>
    						<w:vAlign w:val="bottom"/>
    					</w:tcPr>
    					<w:p>
    						<w:pPr>
    							<w:rPr>
    								<w:sz w:val="6"/>
    								<w:szCs w:val="6"/>
    							</w:rPr>
    						</w:pPr>
    					</w:p>
    				</w:tc>
    

    I looked at the spec and it says there must be some body, and usually that's <p/>. But it is silent on can there be a formatted paragraph, or even a paragraph with text.

    Is there anything specified about what is allowed in the child cells of a vertically merged cell? If so, what are the limitations?

    thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Saturday, November 11, 2017 10:55 PM
  • Hi Dave,

    The problem you are seeing isn't related to the sized, empty paragraph elements. You can manually edit out the paragraph properties and the spacing issue persists. Alternately you can add an empty Run and Text element combination and the spacing issue persists.

    The table definition and corresponding split and merged cells are the root of the issue. I'm looking into the table currently. I should have more information in a few hours. 

    To answer your question regarding split/merged cells. There is nothing special about them which would be generating the way the document is rendering. 

    Will Gregg | open specifications

    Monday, November 13, 2017 7:55 PM
    Moderator
  • Hi Dave,

    As I noted in my reply earlier today, the root cause of the problem was the table definition and the cell merging within the table. 

    There were a number of instances of <w:vMerge w:val="restart"/> where element was not required. The inclusion of the element lead to the extra spacing that you encountered; basically forcing a break in cell merging leaving unintended white-space. 

    I modified the original ATE-291.DOCX that you provided that exhibited the spacing problem to remove the extraneous <w:vMerge w:val="restart"/> elements, and in some instances I modified them to <w:vMerge/> where cell merging should continue, not reset. I used XML comment notation to remove the elements, and in the cases where I modified them; I commented out the original notation and added the new notation immediately below. 

    You can review the modified document here: ATE-291.DOCX

    Will Gregg | open specifications

    Monday, November 13, 2017 11:12 PM
    Moderator
  • Hi Will;

    Would it be accurate to say the DOCX file was incorrect? It's valid because it meets the spec and Word can load it, but fair to say incorrect in that what it specifies is something that is not expected by Word and therefore no guarantees as to how it's handled?

    Which brings up the question, how did Word ever get it in that state? Or is it possible that some other program created this file and/or edited it to this state?

    I ask because our system needs to create a PDF of the file as it exists, not as we want it to be. But if we can say Word didn't do that, then we can take a pass.

    ??? - thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Monday, November 13, 2017 11:19 PM
  • Hi Dave,

    Incorrect is a good description. As you noted the underlying document XML is valid so I am hesitant to use the word invalid.

    Unfortunately I cannot definitively determine how the table definition ended up in this state at this point. I can say that I have used Word 2016 to define a similar table from scratch several times and the results were not incorrect like the source table.

    At this point I am comfortable in saying that Word 2016 was not the source of the table. I want to try creating the table by importing an HTML table and also create the table programmatically. That will rule out some common scenarios for creating tables. I should have the results from those within a few hours. 

    Will Gregg | open specifications

    Tuesday, November 14, 2017 3:11 PM
    Moderator
  • Will - I'm good with saying the DOCX is incorrect. What's going on is probably random in Word as opposed to by design and that means not only will it be hard to figure out what's going on, but that it could easily change in the future.

    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Tuesday, November 14, 2017 6:03 PM
  • Hi Dave,

    As it turns out I just completed some of the additional investigation I was working on. Generating the table in HTML and then importing, or copying and pasting, did not generate an incorrect table state. The same is true for programmatic generation of a table.  

    Back to the original document. The table definition as-is, is incorrect and will cause Word 2016 to render with that space, unless the table is manually cleaned up. 

    Let me know if you want to me continue to look into this. 

    Will Gregg | open specifications

    • Marked as answer by DavidThi808 Tuesday, November 14, 2017 6:26 PM
    Tuesday, November 14, 2017 6:20 PM
    Moderator
  • Hi Will;

    Thanks for looking so deep and no need to do anything more. I'm telling our customer the DOCX is incorrect and we have a clean utility that removes stuff like this. We're telling them to use it.

    thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Tuesday, November 14, 2017 6:26 PM