Detaching reading orders from hierarchies?

[GoogleCodeExporter]

http://www.idpf.org/epub/renditions/region-nav/epub-region-nav.html#cmnt_ref4

Original issue reported on code.google.com by eb2m...@gmail.com on 15 Jan 2014 at 7:25

[GoogleCodeExporter]

The reason we introduced hierarchies was to add a richer way of describing a 
page. AHL is a descriptive extension to ePub that gives the ability to tag 
certain areas. The reading part of AHL is about connecting those regions 
together to create a path through the page. By having a sequence such as

A _____A1
    |__A2
    |__A3
    |__A4
B _____B1
    |__B2
    |__B3
    |__B4
we are simply saying that A1...A4 are subregions of region A, with the 
navigation sequence A1 > A2 > A3 > A4 and we leave it to the Reading System to 
optimize the viewpoints for that sequence.

We are deliberately not saying that the RS should display A1 then A2.... 
because as you said, this would lead to some overslicing of the page.

To solve the issue you raised
What if we would add some additional field to describe whether A is a region 
that should also be included in the sequence of viewpoints
We could have 
A (is-a-viewpoint = false) _____A1 (is-a-viewpoint  = true)
                                |__A2 (is-a-viewpoint  = true)
                                |__A3 (is-a-viewpoint  = true)
                                |__A4 (is-a-viewpoint  = true)
                                |__A5 (is-a-viewpoint  = true)

where the is-a-viewpoint  flag would drive whether the region is also a 
viewpoint to consider in the navigation. We would add A5 that is a full 
rectangle (=A) in order to see the full panel after moving from A1->A4.

Would that make the whole notion of hierachy + navigation more usable ?

matthieu

Original comment by matthieu...@gmail.com on 15 Jan 2014 at 2:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

To many edits in my previous comments were hindering readability, and since 
this issue is followed by only 2 people (my excuses to them), I baked the edits 
into the original comment below, and will then try to delete my previous 
comments (if you see none, I succeeded)

TL;DR: Get rid of parents and just group siblings.

    <nav epub:type="guided" hidden="">
        <ol>
            <li><a href="page22.jpg#xywh=percent:5,5,95,95"></a></li>
            <li>
                <ol>
                    <li epub:type=”balloon”><a href="page23.jpg#xywh=percent:30,30,30,35"></a></li>
                    <li epub:type=”balloon”><a href="page23.jpg#xywh=percent:30,30,30,35"></a></li>
                </ol>
            </li>
        </ol>
    </nav>

Adding the need for a special attribute and duplication of the parent’s 
declaration (once for hierarchical purposes, another for reading order purposes 
when the parent should be displayed after one or more of its children) adds 
unnecessary complexity and redundancy, IMHO.

That redundancy and complexity is unnecessary because it can be avoided by 
switching to a model of only grouping regions to provide 
ancestor/sibling/descendant relations without explicitly declaring parent-child 
relations. Only grouping also provides a simpler model (IMHO) for potential 
GUI-based authoring tools and more flexibility to RS for properly respecting 
the intended narrative at different screen sizes than the currently proposed 
model.

In my opinion, a “parent” of a number of children is but a region that 
encloses the latter in a space which constitutes a narrative unit. The way I 
see it, hierarchy relations in comics is pretty much always a matter of size 
and overlap. If you agree with that[^1], only groups as the means to assign 
hierarchy relations reduces redundancy because:

*    The inherent geometry of a parent is the bounding box of all siblings at a 
certain level in the hierarchy (thus, of the group they constitute), which can 
be calculated by the RS. The current model declares the geometry of a parent 
twice, 3 times with the proposed fix: once, explicitly; another, and 
potentially disconnected from the former, indirectly, by the inherent bounding 
box that contains the explicitly declared geometry of its children[^1]; a 3rd 
time, with the proposed fix, whenever the parent’s declaration needs to be 
duplicated in order to provide it with a reading order position that comes 
after one or more of its children.

*    While groups make declaring a parent unnecessary, a region that overlaps 
several of its siblings can still nevertheless be declared at any order 
position inside its group without the need of the proposed additional attribute 
and duplicate declaration, if the narrative does call for a “zoom out” 
inside a panel (just do not call it “parent”). I.e. with groups, even when 
the whole panel comes after a subpanel region, all regions need only be 
declared once.

In my concern, the purpose of hierarchy is providing the RS with information of 
when it may be appropriate to “merge” several adjacent siblings (regions or 
groups of regions) into one. In other words, when the RS had rather display 
several regions or groups of regions all at once as a single region, instead of 
sequentially one after another, by fitting the bounding box that contains that 
group to the bounds of the screen, in order to prevent overslicing in bigger 
screens, as the comic may (should) have been authored having the smallest 
potential screen size in mind. Does the WG think of any other potential use for 
hierarchies (i.e. what is the intended goal of spec’ing it?)

Assuming that you agree that a RS should only merge regions or groups of 
regions at sibling level, in order to respect the intended narrative (i.e. two 
regions in different groups may end up in a supraregion dynamically created at 
render time, only if it is appropriate that the 2 groups they belong to can be 
merged together in whole; imagine the last subpanel region of a panel and the 
first subpanel region of the next panel), only groups as the means to assign 
hierarchy relations provides more flexibility because, with them, the book 
producer may provide different “merge priority” to different sets of 
regions (i.e. panels, or even subregions inside a panel) simply by grouping 
them, so that potential merging does not hinder the narrative. As an example, 
picture a 3-panel horizontal strip, with panels named 1, 2 and 3: grouping 
panels 2+3 would prevent the RS from displaying, at certain screen sizes, 1+2 
together, and then 3. This same means can apply to intra-panel sets of regions. 
This merge priority can thus be assigned with a ridiculously simple markup (no 
explicit bounding box necessary, which would be in the current model) and it 
carries no more semantic meaning than that hint for the RS. The Comics 
Structural Vocabulary provides the term “panel-group”, and while spicing 
the group with it is not harmful, it is by no means necessary for the RS to be 
intelligent about how to isolate groups of regions, as the hierarchy alone 
makes it explicit (I wonder, then, about when the term would be useful BTW).

May I finally add that my proposal is simply mimicking the SVG model of 
hierarchy, where geometric elements cannot have children, and one relies on 
`<g>` elements, which lack geometry attributes, to provide hierarchy relations. 
At Esdecómic we use GUI-based tools to add regions and their hierarchy in the 
comics we convert to digital, and using stack order and groups (which all 
programs usually have a keyboard shortcut for) is an extremely simple, fast and 
effective way of providing reading order and appropriate region merging hints 
for different target screens sizes.

[^1]: The current draft allows for children whose bounding box fall outside 
that of the parent. I consider that a bug, not a feature, as I can hardly think 
of any case when that may be appropriate (margin notes? Even that is a pretty 
“marginal” case).

Original comment by elmi...@gmail.com on 29 Jan 2014 at 11:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the very insightful comments.

If I understand you well, you propose the following:
#1 use a better notion of group where there are no parents, but only groups of 
siblings (cf the SVG <g> analogy)
#2 use the hierarchy to provide information to the RS on when to optimize the 
merging of content i.e use hierarchy to convey the notion of navigation, but 
not the notion of structure. Rule: merging should only happen between siblings.

The proposal is interesting because it solves a number of potential problems :
- there is clearly a focus on describing navigation and not structure. The aim 
of the spec was to support region-based navigation and not to describe the 
topology of a page
- no need to create an additional keyword to tag regions that should also serve 
as viewpoints. 
- no need to declare a region more than once
- there are no more children regions that extend beyond the bounding box of 
their parent
- better control over the merging strategy of the RS: everything that is in the 
same group (i.e siblings) can be merged > better control over the narrative. No 
outsmarting of the publisher by the RS
- intelligence can be given to the RS without the need of the comics 
vocabulary...only the hierarchy

The proposal raises some questions about the usage of the vocabulary, both for 
comics and magazines.
Let's assume that we replace what would have been our navigation sequence 
through 2 panels on page 23
Thanks for the very insightful comments.

If I understand you well, you propose the following:
#1 use a better notion of group where there are no parents, but only groups of 
siblings (cf the SVG <g> analogy)
#2 use the hierarchy to provide information to the RS on when to optimize the 
merging of content i.e use hierarchy to convey the notion of navigation, but 
not the notion of structure. Rule: merging should only happen between siblings.

The proposal is interesting because it solves a number of potential problems :
- there is clearly a focus on describing navigation and not structure. The aim 
of the spec was to support region-based navigation and not to describe the 
topology of a page
- no need to create an additional keyword to tag regions that should also serve 
as viewpoints. 
- no need to declare a region more than once
- there are no more children regions that extend beyond the bounding box of 
their parent
- better control over the merging strategy of the RS: everything that is in the 
same group (i.e siblings) can be merged > better control over the narrative. No 
outsmarting of the publisher by the RS
- intelligence can be given to the RS without the need of the comics 
vocabulary...only the hierarchy

The proposal raises some questions about the usage of the vocabulary, both for 
comics and magazines.
Let's assume that we replace what would have been our navigation sequence 
through 2 panels on page 23
    <nav epub:type="guided" hidden="">
        <ol>
            <li epub:type=”panel”><a href="page23.jpg#xywh=percent:5,5,95,45"></a></li>
            <li epub:type=”panel”><a href="page23.jpg#xywh=percent:5,55,95,45"></a>
                <ol>
                    <li epub:type=”balloon”><a href="page23.jpg#xywh=percent:..."></a></li>
                    <li epub:type=”balloon”><a href="page23.jpg#xywh=percent:...."></a></li>
                </ol>
            </li>
        </ol>
    </nav>

with the new proposal
    <nav epub:type="guided" hidden="">
        <ol>
            <li epub:type=”panel”><a href="page23.jpg#xywh=percent:5,5,95,45"></a></li>
            <li epub:type=”panel”>
                <ol>
                    <li epub:type=”balloon”><a href="page23.jpg#xywh=percent:..."></a></li>
                    <li epub:type=”balloon”><a href="page23.jpg#xywh=percent:...."></a></li>
                </ol>
            </li>
        </ol>
    </nav>

The parent has been removed.  
The group of siblings lives inside an anonymous group (<li>). This group is not 
a 'panel' anymore as it has the bounding size enclosing the 2 speech bubbles. 
Should we keep the epub:type=”panel” attribute ?
Are we going to use the "panel" epub:type at all ?
Don't we end up with a hierarchy that has half the information.

The same would apply to magazines of course.

I really see the benefit of merge-priority conveyed by the merge-only-siblings 
rules. It would prove very useful in magazines where you could decide to merge 
the caption and the image but never merge the image with a neighbouring text 
box.
But if some regions are becoming implicit, because they are only the enclosing 
boundary of their children, then they cannot be tagged, and they become 
useless. 
You mention the panel-region tag. The same could be said from the 
article-region.

Should we drop the idea of tagging regions inside a navigation sequence all 
together, if we end up with hierarchies that have only half the structural 
information?
Or should we stick with it even if the tagging is incomplete as it gives a hint 
to the RS about the nature of the region?

matthieu 

Original comment by mk...@aquafadas.com on 5 Feb 2014 at 12:31

[GoogleCodeExporter]

elmimmo,

I am trying to understand your comment again.

What does "TL;DR:" mean? 

There appears to be only one difference between your code and 
the code in the draft.  Your code does not have an anchor element 
as the firしt child of the second li element.  Is this correct?

I do not understand the difference between "ancestor/sibling/descendant 
relations"
and "parent-child relations".  Parents are simply nearest ancestor to me.  Are 
you saying that non-leaf nodes in the hierarchy must not explicitly specify 
regions?

Original comment by eb2m...@gmail.com on 9 Mar 2014 at 1:35

[GoogleCodeExporter]

Here I try to list the design space (all possible options about 
data and RS behaviors) and make clear which proposal uses 
which option.

1. Design space

A) Navigation data

X. Sequence of regions
Y. Hierarchy
   Y-1 Non-leaf nodes must not explicitly specify regions
   Y-2 Non-leaf nodes must explicitly specify regions

Note: We might want to further introduce some attributes for 
controlling RSs.

B) RS behaviors

X. Conforming RSs are not required to do anything but may use navigation data
Y. Conforming RSs must use, for navigation,  all nodes that explicitly specify 
regions.
  Y-1 RSs must display each region in turn
  Y-2 RSs may display more than one region at a time
Z. Conforming RSs must use, for navigation, top-level nodes (which must 
   explicitly specify regions), but may ignore lower nodes.
  Z-1 RSs must display each region in turn
  Z-2 RSs may display more than one region at a time

2. Status quo, minimalism, and elmimmo's proposal

Status quo: A-Y-2 and B-Z-2
Minimalism: A-X and B-X
elmimmo: A-Y-1 and B-Y-1(?)

Original comment by eb2m...@gmail.com on 9 Mar 2014 at 2:33

[GoogleCodeExporter]

I think that the elmimmo proposal adds a rule different from B-Y-1 whereby the 
sibling nodes below a parent node can be merged if geometry permits.

Original comment by mk...@aquafadas.com on 10 Mar 2014 at 8:46

[GoogleCodeExporter]

Just so others potentially interested can follow: as my comment above lacks 
graphic examples, and the markup I included can actually lead to 
misunderstanding, I created a document where I elaborate on it. It is available 
at 
https://docs.google.com/document/d/1_RpavOAUu-8n8D498LF4qI4Z5oNHheM49VwtQCNFIHQ/
edit?usp=sharing

Original comment by elmi...@gmail.com on 26 Mar 2014 at 2:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

These comments lead to the final draft of the specification where we 
implemented the following changes
- in the presence of hierarchy, we recommend to ignore the parent node in the 
reading order
- merging of regions can only happen between regions

We checked with elmimmo that he was happy with those changes; so we consider 
this bug as fixed.

Original comment by matthieu...@gmail.com on 28 Jul 2014 at 1:14

• Changed state: Fixed