Re: [TTML2] tts:{width,height} rename

On Tue, Jan 27, 2015 at 10:51 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> > SMPTE needs to present a viable use case for such a feature
>
> The fact that this is a specification in use today should be
> sufficient, a priori. In other words, ST 428-7 could be wrong, but I
> would not assume that without clear evidence.
>
> > add a new issue specifically requesting negative space along with use
> case documentation
>
> Hmmmm. the tts:{ipd,bpd} feature was proposed with the SMPTE liaison
> as the sole documented requirement, but fails to meet it... so I do
> not think closing the issue can be a reasonable course of action.
>

I don't agree. The proposed feature handles insertion of fixed width space.
That is the only requirement that I see as being viable here. I assume the
opposite as you regarding negative space, i.e., that absent of proof of use
it is a non-requirement.


>
> If TTWG has concerns/questions about this and other ST 428-7 features,
> TTWG should simply collect them and ask for SMPTE's input. ITTWG can
> incorporate SMPTE's feedback (if any) in its final disposition.
>
> Best,
>
> -- Pierre
>
> On Tue, Jan 27, 2015 at 9:38 AM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> > On Tue, Jan 27, 2015 at 10:33 AM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> > correct; that use case (dubious at best) is not supported by this
> >> > feature;
> >>
> >> Well... this feature is presumably in use (ST 428-7 being in use
> >> worldwide), so I do not think TTWG can reasonably call it dubious. If
> >> TTWG has concerns/questions, TTWG should simply ask SMPTE. In the
> >> meantime, I have reopened ticket #237.
> >
> >
> > SMPTE needs to present a viable use case for such a feature before I'll
> > consider it; it would be better to leave 237 closed, and add a new issue
> > specifically requesting negative space along with use case documentation
> >
> >>
> >>
> >>
> >>
> >> >it specifies a fixed dimension in inline or block progression;
> >>
> >> What does "inline dimensions" do for a <div>, which is in block
> >> progression?
> >
> >
> > every area generated by content elements has both inline and block
> > progression dimensions; constraining the ipd of a div would constrain it
> in
> > the horizontal axis in a horizontal writing mode
> >
> >>
> >>
> >> Thanks,
> >>
> >> -- Pierre
> >>
> >> On Tue, Jan 27, 2015 at 9:28 AM, Glenn Adams <glenn@skynav.com> wrote:
> >> >
> >> >
> >> > On Tue, Jan 27, 2015 at 10:17 AM, Pierre-Anthony Lemieux
> >> > <pal@sandflow.com>
> >> > wrote:
> >> >>
> >> >> > that is a special case of the specified feature
> >> >>
> >> >> The mechanism specified in the SMPTE liaison allows for negative
> >> >> dimensions and notes "Negative values shall be allowed but should be
> >> >> used with care as characters could overlap."
> >> >>
> >> >> The proposed tts:inlineLength/ipd does not allow negative dimensions.
> >> >
> >> >
> >> > correct; that use case (dubious at best) is not supported by this
> >> > feature;
> >> > you could use negative letter spacing between glyphs as an alternative
> >> >
> >> >>
> >> >>
> >> >> Also, if tts:inlineLength/ipd is intended to add/substract space in
> >> >> the inline progression, how would it work on <div>, which is in block
> >> >> progression?
> >> >
> >> >
> >> > it doesn't add/subtract space; it specifies a fixed dimension in
> inline
> >> > or
> >> > block progression; it applies to all content elements;
> >> >
> >> >>
> >> >>
> >> >> Thanks,
> >> >>
> >> >> -- Pierre
> >> >>
> >> >> On Tue, Jan 27, 2015 at 9:06 AM, Glenn Adams <glenn@skynav.com>
> wrote:
> >> >> >
> >> >> > On Tue, Jan 27, 2015 at 10:02 AM, Pierre-Anthony Lemieux
> >> >> > <pal@sandflow.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi Glenn,
> >> >> >>
> >> >> >> Thanks for the pointer.
> >> >> >>
> >> >> >> The SMPTE liaison referenced in the ticker described "a mechanism
> to
> >> >> >> insert a variable amount of space in the middle of a rendered text
> >> >> >> string".
> >> >> >
> >> >> >
> >> >> > that is a special case of the specified feature
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> Is the idea to use an empty <span> with tts:inlineLength/ipd equal
> >> >> >> to
> >> >> >> the desired amount of space?
> >> >> >
> >> >> >
> >> >> > yes
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> Why is the block progression attribute needed?
> >> >> >
> >> >> >
> >> >> > symmetry
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> Thanks,
> >> >> >>
> >> >> >> -- Pierre
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Jan 27, 2015 at 8:46 AM, Glenn Adams <glenn@skynav.com>
> >> >> >> wrote:
> >> >> >> >
> >> >> >> > On Tue, Jan 27, 2015 at 9:38 AM, Pierre-Anthony Lemieux
> >> >> >> > <pal@sandflow.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> > tts:{ipd,bpd} are used to specify constraints on the
> dimensions
> >> >> >> >> > of
> >> >> >> >> > areas
> >> >> >> >> > generated by content elements
> >> >> >> >>
> >> >> >> >> This is in addition to region height/width, or instead, or
> >> >> >> >> something
> >> >> >> >> else?
> >> >> >> >>
> >> >> >> >> Is there a ticket related to this feature?
> >> >> >> >
> >> >> >> >
> >> >> >> > not a new feature: just a name change from what was introduced
> as
> >> >> >> > the
> >> >> >> > solution for ISSUE-237 [1]
> >> >> >> >
> >> >> >> > [1] http://www.w3.org/AudioVideo/TT/tracker/issues/237
> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Best,
> >> >> >> >>
> >> >> >> >> -- Pierre
> >> >> >> >>
> >> >> >> >> On Tue, Jan 27, 2015 at 8:12 AM, Glenn Adams <glenn@skynav.com
> >
> >> >> >> >> wrote:
> >> >> >> >> > ipd = inline progression dimension
> >> >> >> >> > bpd = block progression dimension
> >> >> >> >> >
> >> >> >> >> > they are the writing mode relative counterparts to width and
> >> >> >> >> > height;
> >> >> >> >> > the
> >> >> >> >> > problem with the latter is that they are strongly associated
> >> >> >> >> > with
> >> >> >> >> > absolute
> >> >> >> >> > axes (horizontal and vertical), while the former {ipd,bpd}
> >> >> >> >> > don't
> >> >> >> >> > suffer
> >> >> >> >> > from
> >> >> >> >> > that association
> >> >> >> >> >
> >> >> >> >> > it also requires less spec text and results in less confusion
> >> >> >> >> > in
> >> >> >> >> > the
> >> >> >> >> > spec,
> >> >> >> >> > since in all places at present (except for line height),
> width
> >> >> >> >> > and
> >> >> >> >> > height
> >> >> >> >> > are interpreted in an absolute sense independent of writing
> >> >> >> >> > mode
> >> >> >> >> >
> >> >> >> >> > tts:{ipd,bpd} are used to specify constraints on the
> dimensions
> >> >> >> >> > of
> >> >> >> >> > areas
> >> >> >> >> > generated by content elements
> >> >> >> >> >
> >> >> >> >> > On Tue, Jan 27, 2015 at 7:37 AM, David Singer
> >> >> >> >> > <singer@apple.com>
> >> >> >> >> > wrote:
> >> >> >> >> >>
> >> >> >> >> >> yikes
> >> >> >> >> >>
> >> >> >> >> >> it’s nice if the terms are readable.  Linewidth and
> Lineheight
> >> >> >> >> >> have
> >> >> >> >> >> some …
> >> >> >> >> >> recognition, albeit mostly in writing systems that use
> >> >> >> >> >> horizontal
> >> >> >> >> >> lines
> >> >> >> >> >> assembled into vertical blocks.
> >> >> >> >> >>
> >> >> >> >> >> ipd and bpd are directions, not measurements, aren’t they?
> and
> >> >> >> >> >> they
> >> >> >> >> >> don’t
> >> >> >> >> >> exactly roll off the tongue or leap to mind in terms of
> >> >> >> >> >> recognizability
> >> >> >> >> >>
> >> >> >> >> >> > On Jan 26, 2015, at 1:01 , Glenn Adams <glenn@skynav.com>
> >> >> >> >> >> > wrote:
> >> >> >> >> >> >
> >> >> >> >> >> > The use of width and height as writing mode relative
> >> >> >> >> >> > properties
> >> >> >> >> >> > is
> >> >> >> >> >> > confusing. Change their names to ipd and bpd,
> abbreviations
> >> >> >> >> >> > for
> >> >> >> >> >> > inline
> >> >> >> >> >> > progression dimension and block progression dimension,
> >> >> >> >> >> > respectively,
> >> >> >> >> >> > and
> >> >> >> >> >> > document convention that width and height (as well as
> >> >> >> >> >> > horizontal
> >> >> >> >> >> > and
> >> >> >> >> >> > vertical) are always absolute and not writing mode
> relative.
> >> >> >> >> >> > The
> >> >> >> >> >> > only
> >> >> >> >> >> > exception being that 'height' in lineHeight remains
> writing
> >> >> >> >> >> > mode
> >> >> >> >> >> > relative,
> >> >> >> >> >> > i.e., specifies the nominal bpd of a line area.
> >> >> >> >> >> >
> >> >> >> >> >> > Change image to use tts:extent instead of the former
> >> >> >> >> >> > tts:{width,height}
> >> >> >> >> >> > in order to use absolute axes in expressing explicit image
> >> >> >> >> >> > dimensions.
> >> >> >> >> >> >
> >> >> >> >> >> > Addressed above comments in [1].
> >> >> >> >> >> >
> >> >> >> >> >> > [1] https://dvcs.w3.org/hg/ttml/rev/69877acd9380
> >> >> >> >> >>
> >> >> >> >> >> David Singer
> >> >> >> >> >> Manager, Software Standards, Apple Inc.
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>