Re: Unifying the rendering approach

Hi Philip,

On Sun, Feb 23, 2014 at 4:14 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Sun, Feb 23, 2014 at 11:05 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> Victor, Philip, all,
>>
>> Does this make sense to you? If so, I can start preparing a branch
>> with patches for this.
>
> I've read all the mails in this thread but don't see a concrete
> suggestion for unification. What concrete changes are we talking
> about, and what are they unifying?

I was referring in particular to the examples that I had sent with the
suggestions at the end.


> As for an implicit anonymous region, I think that is the wrong way to
> phrase this in the spec.

I'm surprised about this because I thought at FOMS we had all agreed
that this would be the right approach.


> Certainly currently it would be completely
> wrong since a region changes the rendering algorithm completely.

Not really. Most of the rendering between the region and non-region
paths is identical. This is why creating an anonymous region around
the normal rendering algorithm and making the rest of the non-region
rendering approaches available to regions should work.

> I'd
> like us to have an internal concept of constraining the size available
> for layout that is honored for snap-to-line cues and that a region
> simply establishes such a constraint. We don't need an anonymous
> region because lack of a region is simply a lack of such a
> constraint...

Are you suggesting to completely drop the region rendering path and
try to reconstruct it within the normal layout algorithm by
constraining the available size for layout for snap-to-line cues? That
would mean that this is the only difference between regions and
non-regions? However, what do you do with the other "constraints":
width, region anchor, viewport anchor, and the scrolling? You can't
replicate scrolling unless you have an explicit box for the cues and
for the regions. Just restricting the size for the background box
doesn't resolve this IMO.


> (Not honoring constraints for non-snap-to-line cues gets rid of the
> percentage-positioned-cue-in-region case which AFAIK there is no use
> case for.)

Are you referring to the case of giving a cue a position offset in a region?
I know that this is an explicit feature of CEA708. It allows rendering
of the following (i.e. indented lines in a region):

---------
| This line is left aligned in the region.
|      This line has an indent.
| This line is again left aligned.
----------

Each line is a separate cue in this example.
Ken (+CC) can clarify if this is a feature of CEA708 (PAC) is in
actual use - I just made sure we can replicate it in regions.

Cheers,
Silvia.

Received on Sunday, 23 February 2014 05:45:20 UTC