W3C home > Mailing lists > Public > public-texttracks@w3.org > February 2012

[Bug 15859] New: Fixed Anchor Point within cue box and Anchor Point Position within viewport

From: <bugzilla@jessica.w3.org>
Date: Thu, 02 Feb 2012 22:10:32 +0000
To: public-texttracks@w3.org
Message-ID: <bug-15859-5018@http.www.w3.org/Bugs/Public/>

           Summary: Fixed Anchor Point within cue box and Anchor Point
                    Position within viewport
           Product: TextTracks CG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: WebVTT
        AssignedTo: ian@hixie.ch
        ReportedBy: victor.carbune@gmail.com
         QAContact: dave.null@w3.org
                CC: mike@w3.org, public-texttracks@w3.org

Here are some thoughts I have about the rendering algorithm from section 3.5
(10.13 - case snap-to-lines is false)

The algorithm seems to combine two different features (anchor point and
anchor point position), under the same numerical values (x%, y%).

It sets the to point (x%, y%) within the cue box at (x%, y%), which is a
very legit approach for cues that don't have changing content (as pop-on
captions), as it ensures that no content of the window will
be outside the viewport.

However, when it comes to cues that adjust their contents or size, things
might get complicated because of the fixed combination, (this means, but
is not limited to: font change, background change, content change - paint-on
or roll-up).

The effect is that (x%, y%) in the interior of the cue box will have different
absolute values within the video viewport, creating a not very pleasant display
effect, by moving the whole displayed cue (instead of keeping it fixed and
append text to it - when text is changed dynamically, for paint-on,

One solution I can think of is to keep these separate one from the other. The
anchor point within the cue box would actually specify the direction in which
the cue box expands, as content changes.

Another solution might consist in specifying explicitly how paint-on captions
are positioned when only a partial text from the full-text is visible, such
that there is no room for interpretation (e.g. if I'm seeing 'ab' from text
'abcd' x%, y% should refer to the final 'abcd')

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 2 February 2012 22:10:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:19 UTC