22989 2013-08-17 00:04:21 +0000 [WebVTT] Clarify text position algo 2014-01-29 11:37:10 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC Linux RESOLVED FIXED v1 P2 normal --- 1 rpuri silviapfeiffer1 mike philipj public-texttracks rpuri dave.null oldest_to_newest 92210 0 rpuri 2013-08-17 00:04:21 +0000 I am having trouble following a portion of the spec outlined in the latest editor's draft obtainable from: https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html Please note the following: 1. At one place in the document, a statement is made regarding the position of 'cue box' within the video frame. Specifically, it is said that: "The position of the cue box within the video frame's dimensions depends on the value of the computed text position anchor point." It appears that the above statement specifies the position of the 'cue box' in relation to the 'value of the computed text position anchor point'. 2. At another place in the document, the following statement is made: "The value of the computed text position anchor point is set as follows:" ... ... ... "4. For left aligned cues with left-to-right paragraph direction [BIDI]: the first character of each line of text is positioned at the text track cue text position point within the video frame, otherwise the last character is positioned there." It appears that the above statement specified the 'value of the computed text position anchor point' in relation to 'text track cue text position' point within the video frame. 3. At another place in the document, 'text track cue text position' is defined as: "A number giving the position of the text within the cue box. If the cue is not within a region, the value is to be interpreted as a percentage of the box's size" From above, it appears that 'text track cue text position' is defined in relation to the 'cue box'. This appears like an infnite loop to me. Am i reading this incorrectly or is there a bug here? 92221 1 silviapfeiffer1 2013-08-17 12:09:46 +0000 Thanks for proof-reading the latest changes. The first part that you reference is a note and not a normative statement. Therefore, there is no infinite loop. That note summarizes what happens in the other statements. It should probably be extended to include the computed line position, too. 92235 2 rpuri 2013-08-18 15:23:25 +0000 (In reply to comment #1) > Thanks for proof-reading the latest changes. > > The first part that you reference is a note and not a normative statement. > Therefore, there is no infinite loop. > > That note summarizes what happens in the other statements. It should > probably be extended to include the computed line position, too. ========================================================== Thanks for the prompt clarification. i still have a related concern and will attempt to capture that in the following: As an example, let us consider the case of a left aligned cue for a left-to-right paragraph direction text (as in the English language). In this case: (1): the value of 'computed text position anchor point' is "first". (2): it appears that in this case the value of the 'text position' attribute manipulates the position of the first character of a line of text in the cue within the video frame. Informally speaking, say if 'text position' had a value '50%', then the first character would be positioned at the middle of the video frame. (3) if above is true, why is text position defined to be as follows? "A number giving the position of the text within the cue box. If the cue is not within a region, the value is to be interpreted as a percentage of the box's size, ....." (4) In other words, what would be incorrect about the following definition: "A number giving the position of the anchor point of the text within the video frame" (5) I guess i am not able to follow how 'text position' gives the position of text relative to the cue box. Any example that clarifies what i might be overlooking would help. 99410 3 philipj 2014-01-29 11:37:10 +0000 It seems to me that this issue has also been obsoleted by change Silvia made since the bug was filed. The "computed text position anchor point" concept is gone and so is the "percentage of the box's size" problem that https://www.w3.org/Bugs/Public/show_bug.cgi?id=23030 pointed out. If there are still problems in this area, please file a new bug.