2.7 More on Styles
| Having come this far in the chapter, you should already know a few key aspects of how styles work in Word and WordprocessingML:
You should also know the basic syntax of the w:style element, and four aspects in particular:
In this section, we'll look at a few more aspects of how styles are defined, how default styles work (or don't), how to derive styles, and how style conflicts are resolved. 2.7.1 A Document's StylesAll styles that are used within a document must also be defined in the document. This effectively means that you can't leverage Word's built-in styles outside of Word; i.e., you can't simply refer to them by name. When a document uses a built-in Word style, Word makes a copy of the built-in style, rather than merely a reference to it. From that point forward, the style is part of the document and begins to exist independently of the built-in style from whence it came. To see a definitive list of the styles that are contained in your document, through the Word UI, select Tools 2.7.2 Default StylesWordprocessingML's default style mechanism (using the w:default attribute) works well for paragraph and table styles. If you have w:p and w:tbl elements in your document that do not explicitly associate themselves with a style (with w:pStyle or w:tblStyle elements, respectively), then you can create sweeping formatting changes by simply changing the default style to a different paragraph or table style inside the w:styles element. You do this by setting the w:default attribute to on: <w:style w:type="paragraph" w:default="on" w:style> <w:name w:val="My Paragraph Style"/> ... </w:style>On the other hand, the default style mechanism does not work for character styles and lists. If you try to specify a custom default character style, for example, Word will ignore it and will simply set the "Default Paragraph Font" character style as the default. For example, the w:default attribute shown here has no effect on Word's behavior: <w:style w:type="character" w:default="on" w:style> <w:name w:val="My Character Style"/> ... </w:style> Effectively, this means that runs can only be associated with a character style explicitly through the w:rStyle element, like this: <w:r> <w:rPr> <w:rStyle w:val="MyCharacterStyle"/> </w:rPr> <w:t>This text is associated with a custom character style.</w:t> </w:r> Also, while you can freely customize the "Normal" paragraph style properties in your document, Word will discard any changes you attempt to make to the "Default Paragraph Font." Thus, there is no defaulting mechanism for associating runs with a particular character style (other than "Default Paragraph Font," which amounts to "no style"). In some respects, this is disconcerting, as it doesn't seem to match up with what WordprocessingML's syntax implicitly advertises. On the other hand, it reduces the possible combinations, thereby making the overall application of styles somewhat easier to think about. The w:default attribute is essentially "syntax sugar," making it easy to create WordprocessingML documents without having to explicitly associate all of a document's paragraphs with a particular style (using a bunch of w:pStyle elements). Since the w:default attribute is merely syntax sugar and not part of Word's internal data structures, Word does not preserve your default style choices when it opens your document. Instead, Word always sets w:default="on" to the "Normal" style definition when it outputs WordprocessingML, regardless of which paragraph style was the default in the WordprocessingML document it originally opened. This doesn't affect your document's formatting; it just means that the resulting WordprocessingML markup will be a little more verbose if most of your paragraphs don't use the "Normal" style. In that case, your paragraph style will be explicitly referenced via w:pStyle elements, rather than implicitly via the default style association: <w:p> <w:pPr> <w:pStyle w:val="MyParagraphStyle"/> </w:pPr> <w:r> <w:t>This paragraph is explicitly associated with a para style.</w:t> </w:r> </w:p> 2.7.3 Default Font Size for Paragraph StylesThere are two kinds of default font sizes in Word:
We have already seen how the first default font size comes about. If you do not explicitly define the "Normal" paragraph style in a document, then Word automatically inserts its built-in "Normal" style, whose font size is 12 points (24 half-points). This scenario is exactly what we saw in Examples Example 2-1 and Example 2-2. However, when you do define a paragraph style but do not explicitly specify the font size (using the w:sz element), then the font size of your paragraph style defaults to 10 points (20 half-points). For this reason, if you do define the "Normal" style in your document but without specifying a font size, then you will get a different result than if you didn't define the style at all. Specifically, the font size of your document's text will be 10 points, rather than 12 points. Example 2-12 shows a document that differs from Example 2-1 only in that it contains an empty definition for the "Normal" paragraph style (as identified by the w:name element). Example 2-12. Defining the "Normal" style without specifying a font size<?xml version="1.0"?> <?mso-application prog?> <w:wordDocument xmlns:w="http://schemas.microsoft.com/office/word/2003/wordml"> <w:styles> <w:style w:type="paragraph" w:default="on"> <w:name w:val="Normal"/> </w:style> </w:styles> <w:body> <w:p> <w:r> <w:t>Hello, World!</w:t> </w:r> </w:p> </w:body> </w:wordDocument> When Word opens this document, the text "Hello, World!" is displayed in 10-point, rather than 12-point, Times New Roman. This is because you defined the style in your document, but did not include a w:sz element (inside a w:rPr element): <w:style w:type="paragraph" w:default="on"> <w:name w:val="Normal"/> </w:style> Word interprets such a paragraph style definition (regardless of whether it's the "Normal" style or some other paragraph style) as having a font size of 10 points. The above definition is equivalent to this one, where the font size of 20 half-points is explicitly specified: <w:style w:type="paragraph" w:default="on"> <w:name w:val="Normal"/> <w:rPr> <w:sz w:val="20"/> </w:rPr> </w:style> The only case where a paragraph style's font size could be different than 10 points without explicitly specifying a font size is when the style is derived from another paragraph style that has a different font size. As long as both the w:basedOn and w:sz elements are absent, then you can be sure that the paragraph style's font size is 10 points. But if there is a w:basedOn element and no w:sz element, then you would have to look at the base style to determine what the font size is. So, what is the default font size for a WordprocessingML document? The answer is: it depends on what you mean by "default font size." If you're talking about the font size of Word's built-in "Normal" style, the answer is 12 points. If you're talking about the default font size of paragraph style definitions, the answer is 10 points. 2.7.4 Derived Styles
http://www.linuxjournal.com/article.php?sid=7120 One of the most powerful aspects of styles is the ability to base one style on another (in WordprocessingML, using the w:basedOn element), overriding individual properties as necessary. We'll see a couple examples of derived styles later in "A Pop Quiz," but the basic syntax looks like this: <w:style w:type="paragraph" w:style> <w:name w:val="My Derived Style"/> <w:basedOn w:val="MyBaseStyle"/> <!-- formatting information --> </w:style>Using style derivation, you can base all of your paragraph styles, for example, on a base "Normal" style. Then, if you want to make a global change to all of your styles, such as font size, you need only make the change in one place in the base style. This, of course, assumes that none of your derived styles override the base style's font size setting. Unfortunately, the Word UI doesn't give any visual clues as to when a particular property of a derived style is merely inherited from the base style or whether it is hard-wired to the style itself. This can make for some bewildering behavior. For example, say your document has a base style called "Normal," from which a number of different styles have been derived, all of which merely inherit the font size property from "Normal." Whenever you update the font size of the "Normal" style, all of the derived styles' font sizes will be updated accordingly. So far, so good. But suppose you now want to derive another style, called "Code," that you know upfront should always be set to a font size of 9 points, regardless of any changes to the base "Normal" style's font size. This is the tricky part. When you first create the "Code" style and select a font size of 9 points, whether that size will end up being hard-wired to the "Code" style (which is what you want) or whether the "Code" style will merely inherit the font size from "Normal" (not what you want) completely depends on what the font size of "Normal" happens to be at the time you create the style. That's because Word gives you no way of telling it to hard-wire the font size to this style. Instead, it makes an assumption based on the current state of the base style. It assumes, in this case, that if the "Normal" font size is 9 points and you select 9 points when creating the "Code" style, you must want "Code" to always be the same size as "Normal." The only way to get around this is to temporarily change the "Normal" style's font size to something other than 9 points, and then create the new style, changing it back after you're done. The introduction of WordprocessingML can largely alleviate this problem. By saving as XML, you get a readable (assuming you've pretty-printed), as well as editable, dump of all of your document's style definitions, removing once and for all any doubt about which of a style's properties are inherited and which are hard-wired to the style. 2.7.5 Resolving ConflictsA given piece of text's formatting information can come from several different places, which raises the question of how conflicts are handled. Even after resolving a document's derived-style inheritance tree, there are still plenty of potential ambiguities, since you still have direct formatting, paragraph styles, and character styles to consider. Understanding how these all interact is fundamental to an understanding of WordprocessingML. In this section, we'll look at how potential conflicts are resolved first for paragraph properties and then for font properties. 2.7.5.1 Paragraph property conflictsA given paragraph can have paragraph properties applied to it in two ways:
There is a simple rule for resolving conflicts between these two ways of applying paragraph properties: direct formatting always wins. For example, you can be sure that the following paragraph will be centered, without ever having to look at the MyParagraphStyle definition: <w:p> <w:pPr> <w:pStyle w:val="MyParagraphStyle"/> <w:jc w:val="center"/> </w:pPr> <w:r> <w:t>This text is centered, regardless of what the associated paragraph style says.</w:t> </w:r> </w:p>The w:jc element in the above snippet is an example of direct paragraph formatting. It is a paragraph property that is applied locally to this specific paragraph, as opposed to being part of a style definition. Any time you see a property setting applied within a local w:pPr element, you can be sure that it will take precedence over any conflicting settings in the associated paragraph style. 2.7.5.2 Font property conflictsWhile paragraph properties can only be applied in two ways, font properties can be applied to a given piece of text in three different ways:
For font properties, as with paragraph properties, direct formatting always wins. For example, you can be sure that the run of text in the snippet below is italic and not bold without even looking at the MyParagraphStyle or MyCharacterStyle definitions: <w:p> <w:pPr> <w:pStyle w:val="MyParagraphStyle"/> </w:pPr> <w:r> <w:rPr> <w:rStyle w:val="MyCharacterStyle"/> <w:i/> <w:b w:val="off"/> </w:rPr> <w:t>This text is italic and not bold, regardless of what the associated paragraph and character styles say.</w:t> </w:r> </w:p> The w:i and w:b elements in the above snippet are examples of direct font formatting. They are font properties applied locally to this specific run, as opposed to being part of a style definition. Any time you see a property setting applied within a local w:rPr element, you can be sure that it will take precedence over any conflicting settings in the associated paragraph or character styles. While the rule that "direct formatting always wins" is sufficient to resolve all potential paragraph property conflicts, it does not resolve all potential font property conflicts. Resolving font properties is a more complex problem, because unlike paragraph properties font properties can be defined in both the character style and the paragraph style. What happens when font property settings conflict between a run's associated paragraph and character styles? To help answer this question, let's consider the different kinds of font properties that can be applied. Word's font properties can be classified into two categories:
Examples of on/off properties are bold (w:b), italic (w:i), all caps (w:caps), and strikethrough (w:strike). Examples of the other, multi-valued properties include underline (w:u), font (w:rFonts), font size (w:sz), and font color (w:color). For multi-valued properties, the rule is simple: the character style takes precedence. For the on/off properties, the rule isn't about which style has precedence; the paragraph and character styles are considered equally. Instead, the rule is about how their settings are merged. Here's the rule: a given property is turned on only when it is turned on in one style but not the other. To help make this more explicit, Table 2-1 shows all four possible combinations for a particular on/off property and the effective result of each.
Table 2-1 is essentially a truth table. The first two columns contain the inputs and the third column contains the XOR ("exclusive or") result. If you imagine representing a style's on/off property settings as a binary number (a series of 0s and 1s), then to compute the final result, you would apply an XOR bitmask to the two binary numbers, i.e., to the paragraph and character styles. That is in fact what Word does. Let's bring this back down to earth with an example. At one time or another, you may have noticed Word's behavior when you applied an italicized character style to text within an italicized paragraph. Rather than keeping the text italic, this action had the opposite effect: the resulting text was not italicized. You may have thought that Word was just being clever about interpreting your intentions. After all, if you wanted to emphasize a particular word in a paragraph that is already emphasized as a whole, how else would Word do it? In reality, Word was just following the above rule. Since the italic property was turned on in both the paragraph and the character styles, they effectively cancelled each other out, and the result was not italicized. Example 2-13 illustrates exactly this scenario. Example 2-13. Turning italics off using a character style<?xml version="1.0"?> <?mso-application prog?> <w:wordDocument xmlns:w="http://schemas.microsoft.com/office/word/2003/wordml"> <w:styles> <w:style w:type="paragraph" w:style> <w:name w:val="Emphasized Paragraph"/> <w:rPr> <w:i/> <w:b/> </w:rPr> </w:style> <w:style w:type="character" w:style> <w:name w:val="Emphasis"/> <w:rPr> <w:i/> <w:b w:val="off"/> </w:rPr> </w:style> </w:styles> <w:body> <w:p> <w:pPr> <w:pStyle w:val="EmphasizedParagraph"/> </w:pPr> <w:r> <w:t>Most of this paragraph is italicized, but </w:t> </w:r> <w:r> <w:rPr> <w:rStyle w:val="Emphasis"/> </w:rPr> <w:t>this part is not.</w:t> </w:r> </w:p> </w:body> </w:wordDocument> Figure 2-25 shows what this document looks like when opened in Word. The last part of the paragraph is not italicized. The "Reveal Formatting" task pane shows that the "Emphasis" style contributes the "Not Italic" effect. In any other (non-italicized) paragraph, the "Emphasis" style would have exactly the opposite effect. Figure 2-25. How Word renders Example 2-13 The other thing to note about this example is that the entire paragraph is rendered bold, even though the "Emphasis" character style explicitly tries to turn bold off: <w:b w:val="off"/> This behavior is consistent with the rule that if either (but not both) of the paragraph and character styles turns a property on, then that property will effectively be turned on. The only times that explicitly turning a property off will have an overriding effect are either when you are inheriting from another style (using the w:basedOn element) or when you are applying direct formatting (using a local w:rPr element). In those cases, to turn a property off, you explicitly turn it off. In contrast, if you want to use a character style to turn a property off, you have to do the counter-intuitive thing: you turn the property on.
2.7.6 A Pop QuizNow it's time for a pop quiz. Considering what you now know about default styles, derived styles, direct formatting, and how paragraph and character styles interact, try to figure out what formatting the runs in Example 2-14 have. There are two runs of text, separated by a soft line break. For each run, ask yourself: Is it bold? Is it italic? Is it both? Example 2-14. What formatting do I have?<?xml version="1.0"?> <?mso-application prog?> <w:wordDocument xmlns:w="http://schemas.microsoft.com/office/word/2003/wordml" xml:space="preserve"> <w:styles> <w:style w:style w:type="paragraph"> <w:name w:val="Base Paragraph Style"/> <w:rPr> <w:b/> <w:i/> </w:rPr> </w:style> <w:style w:style w:type="paragraph" w:default="on"> <w:name w:val="Derived Paragraph Style"/> <w:basedOn w:val="BaseParagraphStyle"/> <w:rPr> <w:i w:val="off"/> </w:rPr> </w:style> <w:style w:style w:type="character"> <w:name w:val="Base Character Style"/> <w:rPr> <w:i/> </w:rPr> </w:style> <w:style w:style w:type="character"> <w:name w:val="Derived Character Style"/> <w:basedOn w:val="BaseCharacterStyle"/> <w:rPr> <w:b/> </w:rPr> </w:style> </w:styles> <w:body> <w:p> <w:r> <w:rPr> <w:rStyle w:val="DerivedCharacterStyle"/> <w:i w:val="off"/> </w:rPr> <w:t>What formatting do I have?</w:t> </w:r> <w:r> <w:rPr> <w:rStyle w:val="DerivedCharacterStyle"/> </w:rPr> <w:br/> <w:t>And what formatting do I have?</w:t> </w:r> </w:p> </w:body> </w:wordDocument> Okay, let's figure it out. The first thing we can do is determine what styles are used in the document. The document's one paragraph doesn't explicitly associate itself with a paragraph style; it has no w:pStyle element. Therefore, it adopts whatever the document's default paragraph style is. Looking at the document's style definitions, we see that the "Derived Paragraph Style" definition is the default one: <w:style w:style w:type="paragraph" w:default="on"> <w:name w:val="Derived Paragraph Style"/>Inside the document's paragraph are two runs, both of which are associated with the "Derived Character Style" definition, using the w:rStyle element: <w:rStyle w:val="DerivedCharacterStyle"/> The next thing we need to do is resolve the style derivations to determine exactly what formatting properties are applied by each derived style. The "Base Paragraph Style" turns bold and italic on: <w:b/> <w:i/> But the "Derived Paragraph Style" turns italic off: <w:i w:val="off"/> Therefore, our document's default paragraph style consists of one font property setting: bold. The "Base Character Style" turns italic on, and the "Derived Character Style" turns bold on. Nothing is overridden. Therefore, the character style associated with our document's two runs has two font property settings: bold and italic. Next, we look to the body of the document itself. The first run explicitly turns italic off, so we know that the first run will not be italicized, as direct formatting always has the final word: <w:r> <w:rPr> <w:rStyle w:val="DerivedCharacterStyle"/> <w:i w:val="off"/> </w:rPr> <w:t>What formatting do I have?</w:t> </w:r>The next question is whether this run is bold or not. Since, as we've seen, both the fully resolved paragraph style and the fully resolved character style turn bold on, that means bold will effectively be turned off. This is in keeping with the rule that a property is on only if one but not both styles turns it on. Thus, the first run is rendered in neither bold nor italic type. The second run is the same as the first, except that italic is not explicitly turned off via direct formatting. In fact, there is no direct formatting: <w:r> <w:rPr> <w:rStyle w:val="DerivedCharacterStyle"/> </w:rPr> <w:br/> <w:t>And what formatting do I have?</w:t> </w:r> We've already seen that the paragraph and character styles' bold settings cancel each other out, so the remaining question is whether this run is italicized or not. Since the character style turns italic on but the paragraph style does not, that means that italic will indeed be turned on, because it is turned on in one but not both of the paragraph and character styles. Figure 2-26 shows the result of opening this document in Word (with paragraph marks turned on). Figure 2-26. How Word renders Example 2-14 2.7.7 Dummy StylesA common advantage of using styles in Word is that they can help to enforce consistency of presentation throughout a document. However, for an XML-oriented user, styles may at first seem to provide yet an additional advantage, especially when they are defined in a template: a way to separate presentation from content in Word. In a limited way they do, because within a document, the style definitions and the content are in distinct places, and changes to a document's style are propagated to all instances of that style throughout the document. However, styles defined externally in a template, rather than remaining separate from a document, are copied into the document when the template is first attached. (This ensures that a document will display uniformly on different machines without requiring all users to have access to the originally attached template.) When a template is attached, all of its styles are copied into the document, and the template's role is essentially over. The document does retain a loose association with the template (as represented by the w:attachedTemplate element), but for all practical purposes the template is no longer needed unless you elect to set the document's "Automatically update document styles" option to true, as shown in Figure 2-27, in the "Templates and Add-ins" dialog box. Figure 2-27. The "Automatically update document styles" checkbox WordprocessingML represents this setting through the presence of an empty w:linkStyles element inside the w:docPr element (short for <w:linkStyles w:val="on"/> because on is the default attribute value for w:val). When w:linkStyles is present, the w:attachedTemplate reference gains new meaning. The next time Word opens the document, it immediately copies all the style definitions within that template into the document once again, replacing any style definition that has the same name as a style defined in the template. As long as this option is set, Word will continue to update the styles in the document, whenever the document is opened. There is a practical implication for the XML developer writing XSLT stylesheets to, say, generate Word document reports. Provided that the user who opens the target Word document has access to its attached template, then styles in the template can effectively be referenced without duplicating the entire style definition. As long as the w:linkStyles option is set, you can rely on Word to supply all the style definitions for you as soon as it opens the document. This greatly simplifies programs (such as XSLT stylesheets) that generate WordprocessingML documents that use styles already defined in a template. Remember that to use any style within a document, it always must be declared in the top-level w:styles element. You can't just refer to a style from inside the w:body element, even if it's a built-in style. If you try to use a style without declaring it, the style reference will be ignored and discarded. So you must declare the style, giving it an arbitrary internal ID (using the w:styleId attribute) for reference from within the document body. (The w:styleId attribute's value can be any string.) Then, to have Word replace a dummy style definition for you, you must additionally ensure all three of the following:
Example 2-15 shows a minimal WordprocessingML document created by hand that uses the Code,x style defined in the O'Reilly Word template. Rather than defining the entire style in all its verboseness, along with the ripe potential for error that would entail, this WordprocessingML document simply declares the style, using a dummy definition that includes nothing other than the w:name element, which identifies it as the Code,x style. The only paragraph of the document then is assigned that style using the w:pStyle element inside the w:pPr element. Thanks to the presence of the w:linkStyles element, the complete style definition for Code,x is inserted automatically (along with all of the template's other styles), as soon as Word opens the document. Example 2-15. Replacing dummy style definitions via w:linkStyles<?xml version="1.0"?> <?mso-application prog?> <w:wordDocument xmlns:w="http://schemas.microsoft.com/office/word/2003/wordml"> <w:styles> <w:style w:style> <w:name w:val="Code,x"/> </w:style> </w:styles> <w:docPr> <w:attachedTemplate w:val="C:\Documents and Settings\lenze.SEATTLEU\Application Data\ Microsoft\Templates\ora.dot"/> <w:linkStyles/> </w:docPr> <w:body> <w:p> <w:pPr> <w:pStyle w:val="Code"/> </w:pPr> <w:r> <w:t>This is a code example.</w:t> </w:r> </w:p> </w:body> </w:wordDocument> Word will always output complete style definitions in the WordprocessingML it creates. Accordingly, this technique shouldn't be thought of as enabling the separation of presentation and content, but rather as a one-time macro of sorts for getting Word to put all the styles in your document for you. Indeed, this describes the basic role that template attachment plays in the first place. 2.7.8 Linked StylesThe w:link element, when present in a paragraph style definition, represents a link to a character style. Conversely, when present in a character style definition, the w:link element represents a link to a paragraph style. Only paragraph and character styles can be linked to each other. The key characteristic of a paragraph-character style link is that the two styles are exposed in the primary Word UI as a single style, using the name of the paragraph style. Also, changes to the character properties of one style are automatically propagated to the other. Word automatically creates a linked character style when a user applies a paragraph style to only a portion of a paragraph, rather than to a paragraph as a whole. The alternative would be to throw an error, chastising the user for trying to use a paragraph style on anything but a complete paragraph. That being potentially bad business, Word instead gracefully falls back and automatically creates a new character style by copying all of the paragraph style's character properties into the newly created style. Thus a linked character style is born. Figure 2-28 shows the creation of a linked character style named "Heading 1 Char." Word automatically creates the style, because the user has tried to apply the "Heading 1" style to only a portion of a paragraph (the word "partial"). At the top of the screen, the style is still listed simply as "Heading 1," though the Reveal Formatting task pane and the Style dialog box both reveal the distinction between "Heading 1" and "Heading 1 Char." Figure 2-28. An automatically created linked character style, "Heading 1 Char" The style definitions in the resulting WordprocessingML are shown below, with the w:link elements highlighted: <w:style w:type="paragraph" w:style> <w:name w:val="heading 1"/> <wx:uiName wx:val="Heading 1"/> <w:basedOn w:val="Normal"/> <w:next w:val="Normal"/> <w:link w:val="Heading1Char"/> <w:rsid w:val="00B33163"/> <w:pPr> <w:pStyle w:val="Heading1"/> <w:keepNext/> <w:spacing w:before="240" w:after="60"/> <w:outlineLvl w:val="0"/> </w:pPr> <w:rPr> <w:rFonts w:ascii="Arial" w:h-ansi="Arial" w:cs="Arial"/> <wx:font wx:val="Arial"/> <w:b/> <w:b-cs/> <w:kern w:val="32"/> <w:sz w:val="32"/> <w:sz-cs w:val="32"/> </w:rPr> </w:style> <w:style w:type="character" w:style> <w:name w:val="Heading 1 Char"/> <w:basedOn w:val="DefaultParagraphFont"/> <w:link w:val="Heading1"/> <w:rsid w:val="00B33163"/> <w:rPr> <w:rFonts w:ascii="Arial" w:h-ansi="Arial" w:cs="Arial"/> <w:b/> <w:b-cs/> <w:kern w:val="32"/> <w:sz w:val="32"/> <w:sz-cs w:val="32"/> <w:lang w:val="EN-US" w:fareast="EN-US" w:bidi="AR-SA"/> </w:rPr> </w:style> As you can see, all of the run properties from the "Heading 1" style are copied into the new "Heading 1 Char" style. The w:link elements retain the association between the two styles by reference to the w:styleId attribute of the other style. Word maintains the link between the styles and honors it by propagating any character property changes in one style to the other. It's possible to create a "synthetic" WordprocessingML document outside of Word that links two styles that do not share the same character properties. However, as soon as you try to change one of the styles within Word, all of the character properties of each get merged together and are synchronized from that point forward. |
Templates and Add-Ins... and then click the Organizer... button. The styles listed on the left should correspond one-to-one with the w:style definitions in the WordprocessingML serialization of your document.
EAN: 2147483647
Pages: 135