Index: experimental/PdfViewer/SkPdfStandardStructureDictionary_autogen.h |
=================================================================== |
--- experimental/PdfViewer/SkPdfStandardStructureDictionary_autogen.h (revision 9684) |
+++ experimental/PdfViewer/SkPdfStandardStructureDictionary_autogen.h (working copy) |
@@ -5,6 +5,7 @@ |
#include "SkPdfArray_autogen.h" |
#include "SkPdfDictionary_autogen.h" |
+// Standard layout attributes common to all standard structure types |
class SkPdfStandardStructureDictionary : public SkPdfDictionary { |
public: |
virtual SkPdfObjectType getType() const { return kStandardStructureDictionary_SkPdfObjectType;} |
@@ -521,6 +522,50 @@ |
SkPdfStandardStructureDictionary& operator=(const SkPdfStandardStructureDictionary& from) {this->fPodofoDoc = from.fPodofoDoc; this->fPodofoObj = from.fPodofoObj; return *this;} |
+/** (Optional) The positioning of the element with respect to the enclosing refer- |
+ * ence area and other content: |
+ * Block Stacked in the block-progression direction within an enclos- |
+ * ing reference area or parent BLSE. |
+ * Inline Packed in the inline-progression direction within an enclos- |
+ * ing BLSE. |
+ * Before Placed so that the before edge of the element's allocation rec- |
+ * tangle (see "Content and Allocation Rectangles" on page |
+ * 648) coincides with that of the nearest enclosing reference |
+ * area. The element may float, if necessary, to achieve the speci- |
+ * fied placement (see note below). The element is treated as a |
+ * block occupying the full extent of the enclosing reference |
+ * area in the inline direction; other content is stacked so as to |
+ * begin at the after edge of the element's allocation rectangle. |
+ * Start Placed so that the start edge of the element's allocation rec- |
+ * tangle (see "Content and Allocation Rectangles" on page |
+ * 648) coincides with that of the nearest enclosing reference |
+ * area. The element may float, if necessary, to achieve the speci- |
+ * fied placement (see note below). Other content that would |
+ * intrude into the element's allocation rectangle is laid out as a |
+ * runaround. |
+ * End Placed so that the end edge of the element's allocation rec- |
+ * tangle (see "Content and Allocation Rectangles" on page |
+ * 648) coincides with that of the nearest enclosing reference |
+ * area. The element may float, if necessary, to achieve the speci- |
+ * fied placement (see note below). Other content that would |
+ * intrude into the element's allocation rectangle is laid out as a |
+ * runaround. |
+ * When applied to an ILSE, any value except Inline causes the element to be |
+ * treated as a BLSE instead. Default value: Inline. |
+ * Note: Elements with Placement values of Before, Start, or End are removed from |
+ * the normal stacking or packing process and allowed to "float" to the specified |
+ * edge of the enclosing reference area or parent BLSE. Multiple such floating ele- |
+ * ments may be positioned adjacent to one another against the specified edge of the |
+ * reference area, or placed serially against the edge, in the order encountered. |
+ * Complex cases such as floating elements that interfere with each other or do not |
+ * fit on the same page may be handled differently by different layout applications; |
+ * Tagged PDF merely identifies the elements as floating and indicates their desired |
+ * placement. |
+**/ |
+ bool has_Placement() const { |
+ return (ObjectFromDictionary(fPodofoDoc, fPodofoObj->GetDictionary(), "Placement", "", NULL)); |
+ } |
+ |
std::string Placement() const { |
std::string ret; |
if (NameFromDictionary(fPodofoDoc, fPodofoObj->GetDictionary(), "Placement", "", &ret)) return ret; |
@@ -528,6 +573,35 @@ |
return ""; |
} |
+/** (Optional) The directions of layout progression for packing of ILSEs (inline |
+ * progression) and stacking of BLSEs (block progression): |
+ * LrTb Inline progression from left to right; block progression from |
+ * top to bottom. This is the typical writing mode for Western |
+ * writing systems. |
+ * RlTb Inline progression from right to left; block progression from |
+ * top to bottom. This is the typical writing mode for Arabic |
+ * and Hebrew writing systems. |
+ * TbRl Inline progression from top to bottom; block progression |
+ * from right to left. This is the typical writing mode for Chi- |
+ * nese and Japanese writing systems. |
+ * The specified layout directions apply to the given structure element and all of |
+ * its descendants to any level of nesting. Default value: LrTb. |
+ * For elements that produce multiple columns, the writing mode defines the |
+ * direction of column progression within the reference area: the inline direc- |
+ * tion determines the stacking direction for columns and the default flow |
+ * order of text from column to column. For tables, the writing mode controls |
+ * the layout of rows and columns: table rows (structure type TR) are stacked |
+ * in the block direction, cells within a row (structure type TD) in the inline |
+ * direction. |
+ * Note: The inline-progression direction specified by the writing mode is subject to |
+ * local override within the text being laid out, as described in Unicode Standard |
+ * Annex #9, The Bidirectional Algorithm, available from the Unicode Consor- |
+ * tium (see the Bibliography). |
+**/ |
+ bool has_WritingMode() const { |
+ return (ObjectFromDictionary(fPodofoDoc, fPodofoObj->GetDictionary(), "WritingMode", "", NULL)); |
+ } |
+ |
std::string WritingMode() const { |
std::string ret; |
if (NameFromDictionary(fPodofoDoc, fPodofoObj->GetDictionary(), "WritingMode", "", &ret)) return ret; |