- From: Glenn Adams <glenn@skynav.com>
- Date: Tue, 23 May 2017 23:46:40 -0600
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- Cc: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <CACQ=j+eMzbbXQ9iw1qVDHthtJ7TEK1HAA-Owv2d1tUxfhoFbRA@mail.gmail.com>
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