Negative inline space.

[plehegar]

[The following is extracted from the liaison received from SMPTE at https://lists.w3.org/Archives/Member/w3c-archive/2012Sep/0214.html]

See Section 6.9 at ST 428-7.

It shall be possible to introduce inline space of arbitrary linear dimension in the current progression direction. The space shall be expressed in units of em and shall be no less than -1 em.

(raised by Pierre-Anthony Lemieux on 2013-05-30)
From tracker issue http://www.w3.org/AudioVideo/TT/tracker/issues/237

[nigelmegitt]

It appears that this can be done using tts:ipd - can this be closed?

[skynavga]

yes

…

On Fri, Dec 16, 2016 at 7:38 AM, Nigel Megitt ***@***.***> wrote: It appears that this can be done using tts:ipd <https://www.w3.org/TR/ttml2/#style-attribute-ipd> - can this be closed? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/w3c/ttml2/issues/53#issuecomment-267607425>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCbxs8c-D5rWUi9yHAaz_wFUy5mWagks5rIqJwgaJpZM4Gb_R9> .

[nigelmegitt]

[Meeting 2016-12-22] @skynavga notes that tts:ipd does not permit negative values. @palemieux would like at least an explanation if we are unable to use negative values. More thought needed, including checking how it is done (if it is done) in CSS.

[nigelmegitt]

[Meeting 2017-01-13] If we separate inline-block semantics from ipd and bpd then we could more easily do this. Negative values might better be implemented using margin semantics however they are currently absent.

[skynavga]

No clear requirement for negative space. If desired, this can be resurrect in ttml.next. I am marking for ttml.next and closing for ttml2.

[palemieux]

No clear requirement for negative space. If desired, this can be resurrected in ttml.next. I am marking for ttml.next and closing for ttml2.

There is in fact a clear request from SMPTE at https://github.com/w3c/ttml2/issues/53#issue-115120715.

As stated in https://github.com/w3c/ttml2/issues/53#issuecomment-268829319, can we explain why it is not possible/useful.

[skynavga]

The referenced "requirement" (for the use of negative space) is not sufficiently specified or motivated to permit taking any action.

[nigelmegitt]

The referenced "requirement" (for the use of negative space) is not sufficiently specified or motivated to permit taking any action.

That needs to be a group decision not an Editor decision alone.

[palemieux]

I asked D-Cinema experts whether negative values of inline spacing are found in practice in D-Cinema. Below is a typical response:

the original intent was to allow "micro-positioning". Negative values are used to reduce the defined advance width, thus pulling characters closer together. As noted in the spec, care must be used to avoid having characters overlap. I have seen this used, especially in Asian subtitles.

[skynavga]

This response is effectively arguing that "micro-positioning" of glyph areas is a requirement we should satisfy, and, effectively proposes a potential solution for doing so, i.e., arbitrarily insert positive or negative space to indirectly affect positioning. I assert that (1) this solution doesn't work, and (2) that this is the function of tools already available in font technology we support, namely, the GPOS mechanism of OpenType. At present, TTML does not provide a way in index, i.e., to reference individual glyph areas that are produced by the character to glyph mapping process. Furthermore, there is a complex interaction between the font based character to glyph mapping process, the font based glyph positioning process, line breaking semantics, letter spacing, and kerning, which, in combination, makes it effectively impossible (or at least impractical) to support direct authorial control over glyph placement. Finally, since TTML2 supports inline and block level images, an author that wishes to perform micro-positioning may do so at authoring time and generate inline images that effect the desired results. So my position is that micro-positioning is not an accepted requirement, that it is counter to the existing font based positioning adjustments, and that an author that wants to do micro positioning in TTML2 can generate their own image content containing the desired results.

…

On Tue, Mar 14, 2017 at 8:54 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: I asked D-Cinema experts whether negative values of inline spacing are found in practice in D-Cinema. Below is a typical response: the original intent was to allow "micro-positioning". Negative values are used to reduce the defined advance width, thus pulling characters closer together. As noted in the spec, care must be used to avoid having characters overlap. I have seen this used, especially in Asian subtitles. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/w3c/ttml2/issues/53#issuecomment-286626226>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb0Q0BF4EYUqYEQUM5nyYTC10mjpKks5rl1LlgaJpZM4Gb_R9> .

[palemieux]

This response is effectively arguing that "micro-positioning" of glyph
areas is a requirement we should satisfy, and, effectively proposes a
potential solution for doing so, i.e., arbitrarily insert positive or
negative space to indirectly affect positioning.

The response argues that micro-positioning is in use in D-Cinema, which has years of experience working on text-based Japanese subtitles.

[skynavga]

That may be so, but it is not used in current text based subtitling in Japan to my knowledge, e.g., Lambda CAP does not support it. Furthermore, it may only be a requirement for particular implementations in Japanese D-Cinema, such as implementations that identify and reference glyphs as opposed to characters. Moreover, since TTML2 supports author supplied fonts, wherein the author may implement the micro-positioning directly in the font, e.g., by using OpenType GPOS tables, such a requirement is already satisfied thrice: once by providing rendered glyphs in images, once by providing fonts that perform the desired positioning, and once by authoring content so that every renderable glyph is associated with a uniquely positioned region. As such, there is no need to provide a fourth solution to the same problem, and, in fact a solution that would greatly complicate the current text to glyph mapping and positioning model. Lastly, there is no mechanism in HTML or CSS that would allow the use of negative space for micro-positioning, that is, except for the pathological case of assigning a uniquely positioned div to every renderable glyph.

…

On Tue, Mar 14, 2017 at 9:27 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: This response is effectively arguing that "micro-positioning" of glyph areas is a requirement we should satisfy, and, effectively proposes a potential solution for doing so, i.e., arbitrarily insert positive or negative space to indirectly affect positioning. The response argues that micro-positioning is in use in D-Cinema, which has years of experience working on text-based Japanese subtitles. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/w3c/ttml2/issues/53#issuecomment-286630682>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb1ReKDWMoYiqtql9ZWnbabv_vuYCks5rl1qGgaJpZM4Gb_R9> .

[palemieux]

Lastly, there is no mechanism in HTML or CSS that would allow the use of negative space for micro-positioning

Aren't negative margins allowed?

[skynavga]

ok, scratch that, it does look like negative margins on non-replaced inline elements are supported by at chrome, safari, and firefox [1] [1] http://codepen.io/skynavga/pen/dvzwGd however, the actual values one would have to use for such negative margins is dependent on the font and the font rendering engine implementation; and, therefore, would not be interoperable without the author supplying the font, and if the author supplies the font, they can easily make sure the font has a GPOS table to perform the necessary micro-positioning

…

On Tue, Mar 14, 2017 at 9:42 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: Lastly, there is no mechanism in HTML or CSS that would allow the use of negative space for micro-positioning Aren't negative margins allowed? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/w3c/ttml2/issues/53#issuecomment-286632526>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb_TdM7U_ORtZf9xIBocRjmMrI_Baks5rl14SgaJpZM4Gb_R9> .

[palemieux]

Ok.

Lambda CAP does not support it.

Is the proposal to use this as a guide to determine the Japanese language features for TTML2?

[skynavga]

On Tue, Mar 14, 2017 at 10:01 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: Ok. Lambda CAP does not support it. Is the proposal to use this as a guide to determine the Japanese language features for TTML2?

I have not made such a proposal, but it does happen to be the case that the Japanese features in TTML2 were designed in part to satisfy the authoring capabilities of Lambda CAP, none of which require support for micro-positioning. That doesn't mean that we can introduce requirements from elsewhere. However, I have pointed out that support for author defined fonts effectively satisfies a requirement to perform micro-positioning of glyphs, and, further, that if we were to support explicit negative inline space, then it would (1) be font dependent, and (2) would be difficult to specify and use in the context of other explicit or implied features that affect glyph position (GSUB, letter spacing, kerning control, line breaking side effects).

…

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/w3c/ttml2/issues/53#issuecomment-286634824>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb0n5st-lb6cGwI5WWhkqz6vex5qQks5rl2KUgaJpZM4Gb_R9> .

[skynavga]

On Tue, Mar 14, 2017 at 10:18 PM, Glenn Adams ***@***.***> wrote: On Tue, Mar 14, 2017 at 10:01 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: > Ok. > > Lambda CAP does not support it. > > Is the proposal to use this as a guide to determine the Japanese language > features for TTML2? > I have not made such a proposal, but it does happen to be the case that the Japanese features in TTML2 were designed in part to satisfy the authoring capabilities of Lambda CAP, none of which require support for micro-positioning. That doesn't mean that we can introduce requirements from elsewhere. However, I have pointed out

s/we can/we can't/

…

that support for author defined fonts effectively satisfies a requirement to perform micro-positioning of glyphs, and, further, that if we were to support explicit negative inline space, then it would (1) be font dependent, and (2) would be difficult to specify and use in the context of other explicit or implied features that affect glyph position (GSUB, letter spacing, kerning control, line breaking side effects). > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <https://github.com/w3c/ttml2/issues/53#issuecomment-286634824>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAXCb0n5st-lb6cGwI5WWhkqz6vex5qQks5rl2KUgaJpZM4Gb_R9> > . >

[nigelmegitt]

[Meeting 2017-03-16] Group disposition agreed as: will not support negative inline space for glyph micro-positioning at this time. (possibly not ever) Other mechanisms exist that can be used for precise visual output including use of images.