From 99066be627f45b4243a985883fa7c15fe5b999fd Mon Sep 17 00:00:00 2001 From: Simon Pepping Date: Sun, 20 Feb 2005 19:52:18 +0000 Subject: [PATCH] Test case markers5a now works correctly. Added four testcases. git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@198448 13f79535-47bb-0310-9956-ffa450edef68 --- test/layoutengine/disabled-testcases.txt | 1 - test/layoutengine/testcases/markers5c.xml | 96 +++++++ test/layoutengine/testcases/markers5d.xml | 140 ++++++++++ test/layoutengine/testcases/markers6a.xml | 256 ++++++++++++++++++ test/layoutengine/testcases/markers6b.xml | 299 ++++++++++++++++++++++ 5 files changed, 791 insertions(+), 1 deletion(-) create mode 100644 test/layoutengine/testcases/markers5c.xml create mode 100644 test/layoutengine/testcases/markers5d.xml create mode 100644 test/layoutengine/testcases/markers6a.xml create mode 100644 test/layoutengine/testcases/markers6b.xml diff --git a/test/layoutengine/disabled-testcases.txt b/test/layoutengine/disabled-testcases.txt index 2696ffdf3..9f19dad65 100644 --- a/test/layoutengine/disabled-testcases.txt +++ b/test/layoutengine/disabled-testcases.txt @@ -1,6 +1,5 @@ breaks1.xml breaks2.xml -markers5a.xml markers5b.xml normal-breaking4.xml table-cell3a.xml diff --git a/test/layoutengine/testcases/markers5c.xml b/test/layoutengine/testcases/markers5c.xml new file mode 100644 index 000000000..e3a11af28 --- /dev/null +++ b/test/layoutengine/testcases/markers5c.xml @@ -0,0 +1,96 @@ + + + + + +

+ This test checks markers, especially the behaviour of block being broken over pages. +

+ + + + + + + + + + + + + + page + + + + + + + + + + + + + 0.00 + 1.00 + 1: 1.00 + + + 1.00 + 2.00 + 2: 1.00 + + + 2.00 + 3.00 + 3: 1.00 + + + 3.00 + 4.00 + 4: This is a special case. It must take two lines. It must take two lines. 1.00 + + + 4.00 + 5.00 + 5: 1.00 + + + 5.00 + 6.00 + 6: 1.00 + + + + + + + + + + + + + + + + + + + + diff --git a/test/layoutengine/testcases/markers5d.xml b/test/layoutengine/testcases/markers5d.xml new file mode 100644 index 000000000..faf46d7df --- /dev/null +++ b/test/layoutengine/testcases/markers5d.xml @@ -0,0 +1,140 @@ + + + + + +

+ This test checks markers, especially the behaviour of block being broken over pages. This is almost the same + as markers5a except that tables are used instead of plain blocks. +

+ + + + + + + + + + + + + + page + + + + + + + + + + + + + + + + + + + 0.00 + 1.00 + 1 + + + 1.00 + + + + + + 1.00 + 2.00 + 2 + + + 1.00 + + + + + + 2.00 + 3.00 + 3 + + + 1.00 + + + + + + 3.00 + 4.00 + 4 + + + 1.00 + + + + + + 4.00 + 5.00 + 5 + + + 1.00 + + + + + + 5.00 + 6.00 + 6 + + + 1.00 + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/test/layoutengine/testcases/markers6a.xml b/test/layoutengine/testcases/markers6a.xml new file mode 100644 index 000000000..70d8e8c70 --- /dev/null +++ b/test/layoutengine/testcases/markers6a.xml @@ -0,0 +1,256 @@ + + + + + +

+ This test checks markers, especially the retrieval of markers +belonging to a preceding page. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + page + + + + + + page + + + + + + + + + + + + + + + + 5 Property Refinement / Resolution + 5 Property Refinement / Resolution5 Property Refinement / Resolution + + + During refinement the set of properties that apply to a +formatting object is transformed into a set of traits that define +constraints on the result of formatting. For many traits there is a +one-to-one correspondence with a property; for other traits the +transformation is more complex. Details on the transformation are +described below. + + + 5.1 Specified, Computed, and Actual Values, and Inheritance5.1 Specified, +Computed, and Actual Values, and Inheritance + + + For every property that is applicable to a given +formatting object, it is necessary to determine the value of the +property. Three variants of the property value are distinguished: the +specified value, the computed value, and the actual value. + + + 5.2 Specified Values5.2 Specified Values + + + The specified value of a property is determined using the +following mechanisms (in order of precedence) + + + If the tree-construction process placed the property on +the formatting object, use the value of that property as the specified +value. This is called "explicit specification". + + + Otherwise, if the property is inheritable, use the value +of that property from the parent formatting object, generally the +computed value (see below). + + + 6 Shorthand Expansion + 6 Shorthand Expansion6 Shorthand Expansion + + + In XSL there are two kinds of shorthand properties; those +originating from CSS, such as "border", and those that arise from +breaking apart and/or combining CSS properties, such as +"page-break-inside". In XSL both types of shorthands are handled in +the same way. + + + 6.1 Actual Values6.1 Actual Values + + + Specified values may be absolute (i.e., they are not +specified relative to another value, as in "red" or "2mm") or relative +(i.e., they are specified relative to another value, as in "auto", +"2em", and "12%"), or they may be expressions. For most absolute +values, no computation is needed to find the computed value. Relative +values, on the other hand, must be transformed into computed values: +percentages must be multiplied by a reference value (each property +defines which value that is), values with a relative unit (em) must be +made absolute by multiplying with the appropriate font size, "auto" +values must be computed by the formulas given with each property, +certain property values ("smaller", "bolder") must be replaced +according to their definitions. The computed value of any property +that controls a border width where the style of the border is "none" +is forced to be "0pt". + + + Some properties have more than one way in which the +property value can be specified. The simplest example of such +properties are those which can be specified either in terms of a +direction relative to the writing-mode (e.g., padding-before) or a +direction in terms of the absolute geometric orientation of the +viewport (e.g., padding-top). These two properties are called the +relative property and the absolute property, +respectively. Collectively, they are called "corresponding +properties". + + + Specifying a value for one property determines both a computed +value for the specified property and a computed value for the +corresponding property. Which relative property corresponds to which +absolute property depends on the writing-mode. For example, if the +"writing-mode" at the top level of a document is "lr-tb", then +"padding-start" corresponds to "padding-left", but if the +"writing-mode" is "rl-tb", then "padding-start" corresponds to +"padding-right". The exact specification of how to compute the values +of corresponding properties is given in [5.3 Computing the Values of +Corresponding Properties]. + + + In most cases, elements inherit computed values. However, +there are some properties whose specified value may be inherited +(e.g., some values for the "line-height" property). In the cases where +child elements do not inherit the computed value, this is described in +the property definition. + + + A computed value is in principle ready to be used, but a +user agent may not be able to make use of the value in a given +environment. For example, a user agent may only be able to render +borders with integer pixel widths and may, therefore, have to adjust +the computed width to an integral number of media pixels. The actual +value is the computed value after any such adjustments have been +applied. + + + Some of the properties applicable to formatting objects +are "inheritable." Such properties are so identified in the property +description. The inheritable properties can be placed on any +formatting object. The inheritable properties are propagated down the +formatting object tree from a parent to each child. (These properties +are given their initial value at the root of the result tree.) For a +given inheritable property, if that property is present on a child, +then that value of the property is used for that child (and its +descendants until explicitly re-set in a lower descendant); otherwise, +the specified value of that property on the child is the computed +value of that property on the parent formatting object. Hence there is +always a specified value defined for every inheritable property for +every formatting object. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/test/layoutengine/testcases/markers6b.xml b/test/layoutengine/testcases/markers6b.xml new file mode 100644 index 000000000..a303f121e --- /dev/null +++ b/test/layoutengine/testcases/markers6b.xml @@ -0,0 +1,299 @@ + + + + + +

+ This test checks markers, especially the retrieval of markers +belonging to a preceding page -- nested areas. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + page + + + + + + + + + page + + + + + + + + + + + + + + + + + + + + + + + + + 5 Property Refinement / Resolution + 5 Property Refinement / Resolution + +5 Property Refinement / Resolution + + + During refinement the set of properties that apply to a +formatting object is transformed into a set of traits that define +constraints on the result of formatting. For many traits there is a +one-to-one correspondence with a property; for other traits the +transformation is more complex. Details on the transformation are +described below. + + + 5.1 Specified, Computed, and Actual Values, and Inheritance + +5.1 Specified, Computed, and Actual Values, and Inheritance + + + For every property that is applicable to a given +formatting object, it is necessary to determine the value of the +property. Three variants of the property value are distinguished: the +specified value, the computed value, and the actual value. + + + + 5.2 Specified Values + +5.2 Specified Values + + + The specified value of a property is determined using the +following mechanisms (in order of precedence) + + + If the tree-construction process placed the property on +the formatting object, use the value of that property as the specified +value. This is called "explicit specification". + + + Otherwise, if the property is inheritable, use the value +of that property from the parent formatting object, generally the +computed value (see below). + + + + + 6 Shorthand Expansion + 6 Shorthand Expansion + +6 Shorthand Expansion + + + In XSL there are two kinds of shorthand properties; those +originating from CSS, such as "border", and those that arise from +breaking apart and/or combining CSS properties, such as +"page-break-inside". In XSL both types of shorthands are handled in +the same way. + + + 6.1 Actual Values + +6.1 Actual Values + + + Specified values may be absolute (i.e., they are not +specified relative to another value, as in "red" or "2mm") or relative +(i.e., they are specified relative to another value, as in "auto", +"2em", and "12%"), or they may be expressions. For most absolute +values, no computation is needed to find the computed value. Relative +values, on the other hand, must be transformed into computed values: +percentages must be multiplied by a reference value (each property +defines which value that is), values with a relative unit (em) must be +made absolute by multiplying with the appropriate font size, "auto" +values must be computed by the formulas given with each property, +certain property values ("smaller", "bolder") must be replaced +according to their definitions. The computed value of any property +that controls a border width where the style of the border is "none" +is forced to be "0pt". + + + + + + + Some properties have more than one way in which the +property value can be specified. The simplest example of such +properties are those which can be specified either in terms of a +direction relative to the writing-mode (e.g., padding-before) or a +direction in terms of the absolute geometric orientation of the +viewport (e.g., padding-top). These two properties are called the +relative property and the absolute property, +respectively. Collectively, they are called "corresponding +properties". + + + Specifying a value for one property determines both a +computed value for the specified property and a computed value for the +corresponding property. Which relative property corresponds to which +absolute property depends on the writing-mode. For example, if the +"writing-mode" at the top level of a document is "lr-tb", then +"padding-start" corresponds to "padding-left", but if the +"writing-mode" is "rl-tb", then "padding-start" corresponds to +"padding-right". The exact specification of how to compute the values +of corresponding properties is given in [5.3 Computing the Values of +Corresponding Properties]. + + + In most cases, elements inherit computed values. However, +there are some properties whose specified value may be inherited +(e.g., some values for the "line-height" property). In the cases where +child elements do not inherit the computed value, this is described in +the property definition. + + + A computed value is in principle ready to be used, but a +user agent may not be able to make use of the value in a +given environment. For example, a user agent may only be +able to render borders with integer pixel widths and may, +therefore, have to adjust the computed width to an +integral number of media pixels. The actual value is the +computed value after any such adjustments have been +applied. + + + Some of the properties applicable to formatting objects +are "inheritable." Such properties are so identified in the property +description. The inheritable properties can be placed on any +formatting object. The inheritable properties are propagated down the +formatting object tree from a parent to each child. (These properties +are given their initial value at the root of the result tree.) For a +given inheritable property, if that property is present on a child, +then that value of the property is used for that child (and its +descendants until explicitly re-set in a lower descendant); otherwise, +the specified value of that property on the child is the computed +value of that property on the parent formatting object. Hence there is +always a specified value defined for every inheritable property for +every formatting object. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.39.5