On Tue, Sep 3, 2013 at 9:41 AM, Jer Noble <jer.noble@apple.com> wrote:
>
> On Sep 2, 2013, at 8:20 AM, Glenn Adams <glenn@skynav.com> wrote:
>
> On Mon, Sep 2, 2013 at 2:20 AM, Philip Jägenstedt <philipj@opera.com>
> wrote:
>
>>
>>
> In the blink-dev thread Silvia made reference to TextTrackCueGeneric,
>>
>> [1] so it would be nice to hear from Apple (CC:ed) about whether or
>> not GenericCue would be a suitable replacement. AFAICT they don't seem
>> very similar, as TextTrackCueGeneric has rendering information
>> attached (e.g. setFontSize) and presumably can be rendered.
>>
>
> I would also like to hear from Eric/Jer on this point, but from my
> evaluation of TextTrackCueGeneric, the implementation of certain style
> properties seemed to be more of a side effect of (1) having this type
> inherit from the existing VTTCue laden rendering semantics of TextTrackCue
> (i.e., as currently implemented in WK), and (2) possible desire to support
> the ingestion of a renderable text cue based on an attributed string, e.g.,
> see
>
>
> https://developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Reference/Foundation/Classes/NSAttributedString_Class/Reference/Reference.html
>
> which allows one to associate font and other style data with substrings in
> a string.
>
>
> Indeed. Our media engine delivers styled NSAttributedStrings strings
> representing cues from in-band caption and subtitle tracks. As such,
> GenericCue would not be a suitable replacement as all the style embedded in
> those cue strings would be lost, or at least would be inaccessable to
> script.
>
In other words, your implementation of TextTrackCueGeneric assumes these
are (1) renderable cues, and (2) to be rendered by UA, not script. Yes? How
are these being used at present? In other words, what format are you
parsing to create attributed strings from which these renderable
TextTrackCueGeneric cues are created and rendered (by UA)? Could (should)
such format(s) have a distinct public interface type exposed in IDL (to
script)?