W3C home > Mailing lists > Public > public-tt@w3.org > May 2017

Re: Document Coordinate System intepretation

From: Glenn Adams <glenn@skynav.com>
Date: Tue, 23 May 2017 23:46:40 -0600
Message-ID: <CACQ=j+eMzbbXQ9iw1qVDHthtJ7TEK1HAA-Owv2d1tUxfhoFbRA@mail.gmail.com>
To: Pierre-Anthony Lemieux <pal@sandflow.com>
Cc: "public-tt@w3.org" <public-tt@w3.org>
On Tue, May 23, 2017 at 11:19 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Glenn,
>
> > hmm, it is the aspect ratio of the physical pixels that PAR applies to
>
> What do you mean by "physical pixels"? If the DAR and SAR are those of
> the root container, then the PAR is also that of the root container,
> not the physical display. In other words, both SAR and PAR apply to
> the logical pixels of the coordinate system, completely independently
> of the physical pixels.
>

I mean quasi-physical pixels, i.e., PAR pixels in the DAR space.

Consider that all SAR pixels (pixels in the sample space) are square, then
PAR scales such square (logical) pixel to a possibly non-square DAR pixel
(pixels in the output space). Since we use "physical" in PAR, then when I
refer to physical pixels here I am referring to whatever output pixels are
produced by TTML rendering. These are quasi-physical in the sense that the
still need to be mapped (possibly multiple times) to an eventual dot
pattern on a physical display.


>
> > what I mean is that width divided by height selected by the document
> processing
> > context must equal SAR, and that SAR * PAR must still equal DAR;
>
> The only thing the document processing context can control by setting
> the extent in pixel is the SAR. The DAR and the PAR are computed
> according to the algorithm specified in Annex H, so no need to repeat
> it.
>

Agreed. It is redundant to include "and PAR" in that cited text.


>
> Best,
>
> -- Pierre
>
> On Tue, May 23, 2017 at 10:09 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> > On Tue, May 23, 2017 at 10:50 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Hi Glenn et al.,
> >>
> >> Before I continue filing issues on PR #321, I thought I would confirm
> >> (or not) my summary understanding of the document coordinate system as
> >> currently proposed.
> >>
> >> - the coordinate system is in logical pixels
> >
> >
> > yes, effectively in the storage (sample) coordinate space (as governed by
> > SAR)
> >
> >>
> >> - the aspect ratio of each of the logical pixels is set by the value
> >> of Pixel Aspect Ratio (PAR) of the root container
> >
> >
> > hmm, it is the aspect ratio of the physical pixels that PAR applies to,
> or,
> > to be more precise, pixels in the display coordinate space (as governed
> by
> > DAR); logical pixels in the storage coordinate space (as governed by SAR)
> > have no aspect ratio per se;
> >
> >>
> >> - the origin of the coordinate system is the top left corner of the
> >> root container
> >
> >
> > yes
> >
> >>
> >> - the positive x-axis points to the right edge of the root container,
> >
> >
> > yes
> >
> >>
> >> while the positive y-axis points to the bottom edge of the root
> >
> >
> > yes
> >
> >>
> >> contain
> >> - the extent of the root container in this coordinate system is set
> >> either by (a) tts:extent if specified in "px" or (b) arbitrarily by
> >> the document processing context such that the ratio of the width
> >> divided by the height is equal to the computed Storage Aspect Ratio
> >> (SAR) of the root container
> >
> >
> > yes for (a), for (b), this is not exactly what I wrote, which is
> >
> > otherwise, the resolution of the root container region is determined
> > (arbitrarily) by the document processing context in a manner that
> respects
> > the resolved values of SAR and PAR as determined by H.1 Aspect Ratios
> above
> >
> > in saying that the resolved value of SAR be respected, what I mean is
> that
> > width divided by height selected by the document processing context must
> > equal SAR, and that SAR * PAR must still equal DAR;
> >
> >>
> >>
> >> Thanks,
> >>
> >> -- Pierre
> >>
> >
>
Received on Wednesday, 24 May 2017 05:47:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:40 UTC