none
What does ST_RelFromH = character mean? RRS feed

  • Question

  • Hi all;

    Please take a look at www.windward.net/temp/CharOffset.docx. In document.xml it has:

    		<w:p w:rsidR="00214FFD" w:rsidRDefault="00623045">
    			<w:r>
    				<w:t>Before</w:t>
    			</w:r>
    		</w:p>
    		<w:p w:rsidR="00623045" w:rsidRDefault="00675A72">
    			<w:r>
    				<w:t>a</w:t>
    			</w:r>
    			<w:r w:rsidR="00623045">
    				<w:rPr>
    					<w:noProof/>
    				</w:rPr>
    				<w:drawing>
    					<wp:anchor distT="0" distB="0" distL="114300" distR="114300" simplePos="0" relativeHeight="251658240" behindDoc="0" locked="0" layoutInCell="1" allowOverlap="1">
    						<wp:simplePos x="0" y="0"/>
    						<wp:positionH relativeFrom="character">
    							<wp:posOffset>66675</wp:posOffset>
    						</wp:positionH>
    						<wp:positionV relativeFrom="paragraph">
    							<wp:posOffset>0</wp:posOffset>
    						</wp:positionV>
    						<wp:extent cx="1069848" cy="804672"/>
    

    But the document displays as:

    Shouldn't the image come after the a?

    thanks - dave


    Who will win The Windward International Collegiate Programming Championships?

    Wednesday, February 19, 2014 8:40 PM

Answers

  • Hi David,

    Yes, you are right, the image should go after “a”, i.e. “a” should go before the image, but in this case there are conflicting instructions in the xml. The picture has absolute position 0.0729” to the right of the character. In the sample documentation there is only one character anchoring the picture too close to the left margin no place to neatly display the text; Word solves the problem by putting “a” to the right of the picture, where there is enough space. There are two ways to solve the problem, when the text goes its designated place, left from the picture.

    1. Increase the anchor position, i.e. push the picture more right; when the anchor position reaches ¼” the text “a” goes to the left.
    2. Increase the length of the text, i.e. push the picture more right; when the text reaches “abcdefghi” it will appear to the left of the picture.

    This is the Word behavior, other products could solve the conflicting situation in some other way.

    Thanks, Vilmos

    • Proposed as answer by Vilmos Foltenyi Monday, March 17, 2014 1:37 AM
    • Marked as answer by DavidThi808 Monday, March 24, 2014 5:48 PM
    Monday, March 17, 2014 1:37 AM
  • Hi Kurt,

    You can't compare the original and your files regarding text wrapping because you changed at least two properties of the picture; in your case the wrapping has these values

    and the original has all zeroes.

    Thanks, Vilmos

    Tuesday, April 15, 2014 7:27 AM
  • Hi Kurt,

    The key elements in my March 17, 2014 posting are that the docx file contains conflicting instructions in the xml and what we see is the way how Word solves this situation, other products could solve the conflicting situation in some other way. The purpose of this forum is support the Open Specifications Documentation, in this case whether Word follows the documented behavior in ISO/IEC 29500, [MS-OI29500], and [MS-DOCX] or not; your question “how Word is determining which behavior to use in a given situation?” is not appropriate for this forum because it is a product behavior. You posted two documents and two pictures, the pictures show that we see the documents in the same way.

    In CharOffset-KN1.docx you just increased the size of the not breakable string without moving the position of the anchor, giving even “more” contradicting instructions to Word and Word solved the problem in the same way as for the original CharOffset.docx, putting the string to the right of the picture.

    In CharOffset-KN2.docx you increased the size of the not breakable string and moved the position of the anchor to the end of the string, giving “less” conflicting instructions to Word and Word solved the problem in the same way as for the original CharOffset.docx, putting the string to the right of the picture. The instructions are almost right, it can be seen that by little modification the Word can follow the instructions.

    • If the Text Wrapping from Left and Right is reduced from 0.13” to 0.01”, the string will be on the left side of the picture.
    • If the Absolute position is increased from 0.07” to 0.19”, the string will be on the left side of the picture.
    • If a breakable space is inserted into the string close to the anchor, e.g. after ‘x’, Word breaks the string at the space and the long part will be on the left side of the picture.

    Thanks, Vilmos

    Tuesday, May 6, 2014 2:19 AM
  • Hi Kurt,

    What we are getting into here are potentially many combinations of conflicting and/or inconsistent formatting commands in the WordprocessingML and DrawingML.  It is truly beyond the scope of this forum to describe rules that Word will use to resolve every conflict in a way that renders satisfactorily in all situations (and what “satisfaction” means).  We described to David the specific scenario as a way to demonstrate that this is a choice made by Microsoft for aesthetic attractiveness and layout.  David can now make choices in his own implementation that make sense for his business and target audience. If you still believe that Word is incorrectly following the standard, we would be happy to review your explanation of what you believe Word should be doing for a given example.

    If you would like to pursue the topic of Word's behavior further, there are better venues for this.  The Word product forums and some 3rd party OOXML blogs and forums have discussions that go deeper into this area.

    Thanks, Vilmos

    Wednesday, May 7, 2014 8:53 PM

All replies

  • Hi Dave,

    A member of the Protocols Team will investigate this and follow up on the forum.

    Regards,

    Mark Miller | Escalation Engineer | Microsoft Open Protocols Team

    Wednesday, February 19, 2014 8:53 PM
  • Hi David,

    I am the engineer who will be working with you on this issue. I’ve downloaded the “CharOffset.docx” file, I am going to analyze it and will provide you with an update soon.

    Regards,
    Vilmos Foltenyi - MSFT

    Thursday, February 20, 2014 6:49 PM
  • Hi David,

    After studying the CharOffset.docx I also don’t understand how the instructions in the xml yield the rendering seen in Word 2013. I have asked the product group for clarification on this issue.

    Thanks, Vilmos
    Wednesday, March 5, 2014 4:54 PM
  • Hi David,

    Yes, you are right, the image should go after “a”, i.e. “a” should go before the image, but in this case there are conflicting instructions in the xml. The picture has absolute position 0.0729” to the right of the character. In the sample documentation there is only one character anchoring the picture too close to the left margin no place to neatly display the text; Word solves the problem by putting “a” to the right of the picture, where there is enough space. There are two ways to solve the problem, when the text goes its designated place, left from the picture.

    1. Increase the anchor position, i.e. push the picture more right; when the anchor position reaches ¼” the text “a” goes to the left.
    2. Increase the length of the text, i.e. push the picture more right; when the text reaches “abcdefghi” it will appear to the left of the picture.

    This is the Word behavior, other products could solve the conflicting situation in some other way.

    Thanks, Vilmos

    • Proposed as answer by Vilmos Foltenyi Monday, March 17, 2014 1:37 AM
    • Marked as answer by DavidThi808 Monday, March 24, 2014 5:48 PM
    Monday, March 17, 2014 1:37 AM
  • Hi David,

    Because there is no response to this issue since my last posting on Monday, March 17, I assume my explanation was adequate, your problem is solved, you no longer require my assistance and I’ll mark my previous post as answer.

    Thanks, Vilmos

    Monday, March 24, 2014 5:47 PM
  • Sorry, yes that solved it.

    thanks - dave


    Who will win The Windward International Collegiate Programming Championships?

    Monday, March 24, 2014 5:48 PM
  • I'm afraid I find this answer incomplete.  It's not clear to me that the number of characters preceding the image matters.  In Word 2013 I don't find the same behavior as you describe in (2); rather, I find that the "abcdefghi" also appears to the right of the picture, and in fact if the run containing the image immediately follows the run with the "a" in the XML document, then the text will follow the image, no matter how many characters there are.  This is true even if the left and right "distance from text" are set to 0.

    So it appears to me that Word places the anchor for character-relative positioning slightly to the left of the right-hand side of the preceding character, meaning that the graphical object always interferes with the character, forcing it to another location.  Do you agree?

    Thanks.

    Kurt

    Wednesday, March 26, 2014 6:49 PM
  • Hi Kurt,

    Below is the picture showing what I wrote in my March 17 posting.

    If you think Word doesn't render something properly, please provide the concrete case and we'll investigate it.

    Thanks, Vilmos

    Thursday, March 27, 2014 5:23 PM
  • Vilmos,

    Thanks for your response.  I'm interested in this discussion because I've grappled with the same situation.  I'm finding it problematic to use character-relative positioning in created files, because it's not clear how Word will handle it.

    I posted two files, CharOffset-KN1.docx and CharOffset-KN2.docx, on

    https://sites.google.com/site/ooxmltests/

    I also posted screenshots of how they render in my version of Word 2013, which "About Word" shows as 15.0.4569.1504, as CharOffset-KN1.PNG and CharOffset-KN2.PNG.

    Both are modifications of the file posted by the OP, with additional characters after the "a".  I generated CharOffset-KN1.docx simply by typing text in Word after the "a".  Word left put this additional text in a run following the image; therefore, the "anchor character" for the image remains the "a".  I created CharOffset-KN2.docx by putting all the added characters in the same run as the "a", preceding the image.  Therefore the "anchor character" is "z". 

    So along with the rendering you're showing, I'm seeing three different behaviors:

    1. The image is aligned left in the column, and the "word" containing the anchor character follows the image (as in CharOffset.docx and CharOffset-KN1.docx).

    2. The image is positioned as if it were following the "word" containing the anchor character, but the actual text appears after the image (as in CharOffset-KN2.docx).

    3. The text is aligned left in the column, and the image immediately follows it (as in the rendering you show).

    Can you help me understand how Word is determining which behavior to use in a given situation?

    Thanks.

    Kurt

    Friday, March 28, 2014 12:32 AM
  • Hi Kurt,

    You can't compare the original and your files regarding text wrapping because you changed at least two properties of the picture; in your case the wrapping has these values

    and the original has all zeroes.

    Thanks, Vilmos

    Tuesday, April 15, 2014 7:27 AM
  • Hi Kurt,

    Because there is no response to this issue since my last posting on Tuesday, April 15, I assume my explanation was adequate, your problem is solved, you no longer require my assistance and I’ll mark my previous post as answer.

    Thanks, Vilmos

    Monday, April 21, 2014 5:38 PM
  • Vilmos,

    Thanks for your response, which I just now saw.  My version of Word shows the same values for "Distance from text" for all three files: the OP's file (CharOffset.docx) and my two versions.  All three show as in your screenshot above.  Note also that in the OP's screenshot of Word's rendering, there is space between the image and the text to its right.  This space would (presumably) not appear if the original had left and right "Distance from text" zero.

    In any case, this skirts the question of what is considered the proper positioning of a character-relative graphic when text-wrapping rules cause it to conflict with the word containing the anchor.  So I consider this still an unresolved question.

    Thanks.

    -- Kurt

    Thursday, April 24, 2014 1:24 AM
  • Hi Kurt,

    The key elements in my March 17, 2014 posting are that the docx file contains conflicting instructions in the xml and what we see is the way how Word solves this situation, other products could solve the conflicting situation in some other way. The purpose of this forum is support the Open Specifications Documentation, in this case whether Word follows the documented behavior in ISO/IEC 29500, [MS-OI29500], and [MS-DOCX] or not; your question “how Word is determining which behavior to use in a given situation?” is not appropriate for this forum because it is a product behavior. You posted two documents and two pictures, the pictures show that we see the documents in the same way.

    In CharOffset-KN1.docx you just increased the size of the not breakable string without moving the position of the anchor, giving even “more” contradicting instructions to Word and Word solved the problem in the same way as for the original CharOffset.docx, putting the string to the right of the picture.

    In CharOffset-KN2.docx you increased the size of the not breakable string and moved the position of the anchor to the end of the string, giving “less” conflicting instructions to Word and Word solved the problem in the same way as for the original CharOffset.docx, putting the string to the right of the picture. The instructions are almost right, it can be seen that by little modification the Word can follow the instructions.

    • If the Text Wrapping from Left and Right is reduced from 0.13” to 0.01”, the string will be on the left side of the picture.
    • If the Absolute position is increased from 0.07” to 0.19”, the string will be on the left side of the picture.
    • If a breakable space is inserted into the string close to the anchor, e.g. after ‘x’, Word breaks the string at the space and the long part will be on the left side of the picture.

    Thanks, Vilmos

    Tuesday, May 6, 2014 2:19 AM
  • Vilmos, thanks for your response. 

    I realize that this question is largely about Word's behavior, but other similar questions have been answered on this forum, so I was hoping the same might be true here.  Strictly speaking, it's also a question of abiding by the spec.  The spec says ST_RelFromH="character" means "Specifies that the horizontal positioning shall be relative to the position of the anchor within its run content."  In these examples Word is not, in fact, positioning objects relative to the anchor with the given offset.

    Without getting all legalistic, I also realize that it's up to Microsoft's discretion whether to document specific behavior.  But I think the company is aware that it benefits if other products can interoperate well with Office.  In this case our interoperability is limited because we can't predict how Office will render this sort of construction.  (And while it's arguably correct that the commands in the OOXML are "conflicting", the examples are both valid OOXML and the output of Word itself.)

    -- Kurt

    Wednesday, May 7, 2014 1:00 AM
  • Hi Kurt,

    What we are getting into here are potentially many combinations of conflicting and/or inconsistent formatting commands in the WordprocessingML and DrawingML.  It is truly beyond the scope of this forum to describe rules that Word will use to resolve every conflict in a way that renders satisfactorily in all situations (and what “satisfaction” means).  We described to David the specific scenario as a way to demonstrate that this is a choice made by Microsoft for aesthetic attractiveness and layout.  David can now make choices in his own implementation that make sense for his business and target audience. If you still believe that Word is incorrectly following the standard, we would be happy to review your explanation of what you believe Word should be doing for a given example.

    If you would like to pursue the topic of Word's behavior further, there are better venues for this.  The Word product forums and some 3rd party OOXML blogs and forums have discussions that go deeper into this area.

    Thanks, Vilmos

    Wednesday, May 7, 2014 8:53 PM
  • Vilmos,

    Thanks for your follow-up.  I realize that this forum is nominally about spec-level compliance.  But I suspect I speak for many others attempting to interoperate with Office in saying that an end-user doesn't care about spec compliance (particularly since the spec is often extremely vague); the end user only cares about whether their content looks "right", whatever that may mean.  So that often comes down to understanding Office's behavior.  The forum has sometimes veered into that territory, which I've found helpful, but as I said above, I realize that that's at your discretion.

    The argument that since the commands in the OOXML are conflicting, the solution is to change the OOXML is, however, not compelling.  That's particularly true when the OOXML is the output of Word itself.

    In any case, I'm happy to let this drop, and thanks again for the dialogue.

    -- Kurt

    Thursday, May 8, 2014 6:04 PM