src/deprecated


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id$ -->
<!--
<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd">
-->

<document>
  <header>
    <title>Keeps and breaks</title>
    <authors>
      <person name="Peter B. West" email="pbwest@powerup.com.au"/>
    </authors>
  </header>
  <body>
    <!-- one of (anchor s1) -->
    <s1 title="Keeps and breaks in layout galleys">
      <p>
	The <link href= "galleys.html" >layout galleys</link> and the
	<link href= "galleys.html#layout-tree" >layout tree</link>
	which is their context have been discussed elsewhere.  Here we
	discuss a possible method of implementing keeps and breaks
	within the context of layout galleys and the layout tree.
      </p>
      <s2 title="Breaks">
	<p>
	  Breaks may be handled by inserting a column- or page-break
	  pseudo-object into the galley stream.  For break-before, the
	  object would be inserted before the area in which the flow
	  object, to which the property is attached, is leading.  If
	  the flow object is leading in no ancestor context, the
	  pseudo-object is inserted before the object itself.
	  Corresponding considerations apply for break-after.
	  Selection of the position for these objects will be further
	  examined in the discussion on keeps. 
	</p>
      </s2>
      <s2 title="Keeps">
	<p>
	  Conceptually, all keeps can be represented by a
	  keep-together pseudo-area.  The keep-together property
	  itself is expressed during layout by wrapping all of the
	  generated areas in a keep-together area.  Keep-with-previous
	  on formatting object A becomes a keep-together area spanning
	  the first non-blank normal area leaf node, L, generated by A
	  or its offspring, and the last non-blank normal area leaf
	  node preceding L in the area tree.  Likewise, keep-with-next
	  on formatting object A becomes a keep-together area spanning
	  the last non-blank normal area leaf node, L, generated by A
	  or its offspring, and the first non-blank normal area leaf
	  node following L in the area tree.
	  <br/>TODO REWORK THIS for block vs inline
	</p>
	<p>
	  The obvious problem with this arrangement is that the
	  keep-together area violate the hierarachical arrangement of
	  the layout tree.  They form a concurrent structure focussed
	  on the leaf nodes.  This seems to be the essential problem
	  of handling keep-with-(previous/next); that it cuts across
	  the otherwise tree-structured flow of processing.  Such
	  problems are endemic in page layout.
	</p>
	<p>
	  In any case, it seems that the relationships between areas
	  that are of interest in keep processing need some form of
	  direct expression, parallel to the layout tree itself.
	  Restricting ourselves too block-level elements, and looking
	  only at the simple block stacking cases, we get a diagram
	  like the attached PNG.  In order to track the relationships
	  through the tree, we need four sets of links.
	</p>
	<p>
	  <strong>Figure 1</strong>
	</p>
	<anchor id="Figure1"/>
	<figure src="block-stacking.png" alt="Simple block-stacking
		diagram"/>
	<p>
	  The three basic links are:
	</p>
	<ul>
	  <!-- one of (dl sl ul ol li) -->
	  <li>Leading edge to leading edge of first normal child.</li>
	  <li>Trailing edge to leading edge of next normal
	    sibling.</li>
	  <li>Trailing edge to trailing edge of parent.</li>
	</ul>
	<p>
	  Superimposed on the basic links are bridging links which
	  span adjacent sets of links.  These spanning links are the
	  tree violators, and give direct access to the areas which
	  are of interest in keep processing. They could be
	  implemented as double-linked lists, either within the layout
	  tree nodes or as separate structures.  Gaps in the spanning
	  links are joined by simply reproducing the single links, as
	  in the diagram. The whole layout tree for a page is
	  effectively threaded in order of interest, as far as keeps
	  are concerned.
	</p>
	<p>
	  The bonus of this structure is that it looks like a superset
	  of the stacking constraints.  It gives direct access to all
	  sets of adjacent edges and sets of edges whose space
	  specifiers need to be resolved. Fences can be easily enough
	  detected during the process of space resolution.
	</p>
      </s2>
    </s1>
  </body>
</document>
	Commit message (Expand)	Author	Age	Files	Lines
*	Core: Use named exports in `src/`	Michał Gołębiowski-Owczarek	2023-09-12	2	-2/+2
*	Deprecated: Define `.hover()` using non-deprecated methods	Michał Gołębiowski-Owczarek	2023-05-22	1	-1/+3
*	Build: Correct code indentations based on jQuery Style Guide	Wonseop Kim	2020-05-05	1	-2/+4
*	Ajax: Deprecate AJAX event aliases, inline event/alias into deprecated	Michał Gołębiowski-Owczarek	2020-01-21	2	-0/+59