OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Errata part 1


Greetings!

Apologies for not having gone through the draft with this level of 
attention earlier.

A couple of general comments followed by specific notes up to the 
beginning of chapter 10.

Decided to not break them up into separate posts since that would just 
fill everyone's inboxes up.

Can't promise anything but hope that I can finish the remaining 300 
pages at this level of detail by the end of March. Depends upon how a 
number of other projects come along in the meantime.

Hope everyone is at the start of a great day!

Patrick

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!
Erratta for version 12

General comments:

1. We seem to shift between "This element represents" and "This
element contains" without any meaningful distinction that I can detect
in the text.

Suggest that "This element contains" is the better wording. Too
prevalent to note every occurrence.

Same comment applies to "This element displays..."

2. Interesting that at 6.6.3 Conditional Text Fields, we shift from
   "See the following (section name) to simply listing the attributes,
   which are then followed by sections that explain each one. Look at
   page 104 for example.

Not a major point but inconsistent styles don't inspire confidence.


Page: 1

Extra line between Tom Magliery and Phil Boutros in Contributors list

Email address of Mark Heller indents due to length of prior line?
(this may have been intentional)

Page: 26

in namespace prefix table, Config is the only prefix listed in the
left hand column that start with a capital letter

Suggest: config

Page: 27

in namespace prefix table, draw (incorrect) in left hand column,
namespace is correct: drawing

Suggest: drawing (left hand column)

Page: 27

the namespace prefix table list number, but the xmlns:prefix has
"data style" with a space. Note that the schema has:

xmlns:number="urn:oasis:names:tc:openoffice:xmlns:datastyle:1.0"

If that is correct, it is at variance with all the other declared
namespaces. 

Suggest removing the space between "data" and "space" in the far right
hand corner. 

Do note that while:

xmlns:number="urn:oasis:names:tc:openoffice:xmlns:datastyle:1.0"

appears in the schema,

it does not appear on page 28 with the other namespace declarations.

A quick search for it did not find any occurrences in the
specification.

If it is supposed to be present, add to the example prefix on page 28,
if not, strike from the schema itself.

Page: 29

1.6 White-Space Processing...

last item in list, note extra ")" following SPACE (0x0020))

Suggest: SPACE (0x0020)

Page: 30

1.7 MIME Types

First sentence reads:

"The following MIME types should be used for office documents that
conform to this specification, provided that they are contained in a
package (see also section 2.1)."

I think I understand the package requirement but am puzzled by the
reference to section 2.1.

Was it meant to be a reference to 2.3, Body Element and Document
Types?

Page: 30

First sentence following the list of MIME types:

Now reads:

There are no specific MIME types for office documents that conform to
this specification but are not contained in a package. It is
recommended to use text/xml for such documents.

Suggest:

There are no MIME types for office documents that conform to this
specification but are not contained in a package. It is recommended to
use text/xml for such documents.

specific MIME -> MIME

If no MIME type exists, what more can you say?

Page: 30

last sentence on the page, note errant markup "<subtype>."

Suggest strike "<subtype>."

Page: 31

Second sentence in paragraph following the list under 2 Document Structure

Now reads:

The structure of XML documents applies to all Open Office document types.

Suggest:

The structure of an Open Office XML document applies to all Open
Office document types.

Page: 35

Second paragraph following the list in 2.3 Body Element reads:

All document types share the same content elements, but different
document types place different restrictions on which elements may
occur, and in which numbers.

"...in which numbers?"

Suggest:

"....place different restrictions on which elements may occur and in
what combinations."

Here I am assuming the intent was to make a reference to content
models without say so explicitly.

Next sentence reads:

"The document content is typically framed by a prelude and epilogue,
which contains content elements which may only occur once inside a
document of the specific type."

It was probably the veiled reference to content models in the prior
sentence but I had to read this a couple of times to realize it was
talking about content models at the document type level. 

Suggest:

"The document content model, typically framed by a prelude and
epilogue, contains content elements which may only occur once inside a
document of the specific type."

Page: 45

2.6 Font Face Declarations

Second sentence reads:

"A font face declaration provides information about the fonts used by
the author of a document, so that these fonts or fonts that are very
close to these fonts can be located on other systems."

Minor quibble on wording: "can be located on other systems."

Would prefer:

"may be located on other systems."

Try: http://www.electricearl.com/fonttest.html for an example of where
your browser will fail to find some of the font faces specified on
this page.

Page: 45

2.7 Styles

Under Common Styles, the last sentence reads:

"The term common indicates that this is the type of style that an
office application user, who is not interested in the Open Office XML
file format, considers to be a style."

I can't imagine an office application user not being interested in the
Open Office XML file format but even if such exists, I don't see that
this adds to the explanation. ;-)

Suggest:

"The term common indicates that this is the type of style that an
office application user considers to be a style."

Page: 45

2.7 Styles

Under Automatic styles

"The term automatic indicates that the style is generated
automatically at export time. In other words, formatting properties
that are immediately assigned to a specific object are represented by
an automatic style within an Open Office XML document."

Poor use of the term "export time." Leads to similar statement on page
121 (see below)

Most users think of "export" as outputting the document to another format.

Suggest: ""The term automatic indicates that the style is generated
automatically."


Page: 46

paragraph continued from previous page, first full sentence reads:

"The assumption is that the author of the document wants this
formatting and layout information to be preserved when the document is
reloaded or displayed on a certain device, because this is common
practice for documents created by word processors."

Puzzled by the language: "on a certain device..."

Suggest:

"The assumption is that the author of the document wants this
formatting and layout information to be preserved when the document is
reloaded or displayed, because this is common practice for documents
created by word processors."

Page: 46

First full paragraph reads:

"This type of style information differs from [CSS2] or [XSLT] style
sheets that are used to display a document. An additional style sheet
for CSS, XSLT, and so on, is required to display an Open Office XML
document on a certain device. This style sheet must take into account
the styles in the document as well as the requirements and
capabilities of the output device. The ideal case is that this style
sheet depends on the output device only."

Maybe I am just missing the point of the paragraph but it does not
seem to have a relationship to the styles as described prior to this
point. 

As I say, I may be missing the point but at this point:

Suggest: strike

Page: 50

3.1.7 Creator

Reads:

"The <dc:creator> element specifies the name of the person who last
modified the document. The name of this element was chosen for
compatibility with the Dublin Core."

I think I understand the argument that the last person to modify the
document should be considered the "creator" of the document but,
consider the definition used by Dublin Core:

"An entity primarily responsible for making the content of the
resource." 

That strikes me as being at variance with our usage of "creator."

Seems to me we can continue with our usage, but should note the
difference from Dublin Core, thus:

Suggest: "This definition of "creator" differs from Dublin Core, which
defines creator as "An entity primarily responsible for making the content 
of the resource." In Open Office terminology, the last person to
modify the document is primarily responsible for making the content
of the document." 

That may be overly pendantic and I will agree with the majority on
whichever way is chosen.

Page: 58

4.1.1 Headings

First paragraph: (sub-)chapter -> subchapter

Page: 61

4.3 Lists

Second paragraph: (re-)started -> restarted

Page: 65

4.3.4 Numbered Paragraphs

Second paragraph:

continuos -> continuous

equivalent, alternate way -> equivalent, alternative way

Page: 75

5.1 Basic Text Content

Second paragraph, list, first item:

(foot- and end-)notes -> foot- and endnotes

Page: 78

5.1.4 Hyperlinks

Second paragraph, last sentence:

Now reads:

See Chapter  for more information on the event table element.

Suggest:

See 12.4, Event Listener Tables, for more information.


Page: 78

Name, second sentence reads:

"The text:name attribute specifies the name of the hyperlink if one exists." 

But the schema snippet reads:

<attribute name="office:name">

And the draft schema reports the same.

Text and schema are inconsistent, suspect schema should be:

<attribute name="text:name"> but would need greater familiarity with the schema to say for sure.


Page: 87

6.2.1 Date Fields

Third paragraph, list, third item

Fixed (see section 6.7.2)) -> Fixed (see section 6.7.2)

Remove extra paren at end


Page: 95

6.2.6 Author Fields

First paragraph reads:

"There are two Open Office XML elements available to represent the
author of a document. One element displays the full name of the author
and the other element displays the initials of the author."

Suggest: represent -> display

I was momentarily confused since author information is also contained
in initial creator and creator metadata. (This may be academic
quibbling so feel free to ignore.)


Page: 98

6.3 Variable Fields

Last paragraph on page, last sentence:

Now reads:

"The Open Office XML code for declaring variables is described in the following table."

Suggest:

The Open Office XML code for declaring variables is described in the following section.

Page: 99

6.3.1 Declaring Simple Variables

Second paragraph

At first blush, the attributes given appear inconsistent with the
schema snippet, i.e., text:name versus field-name, for example.

However, when those refs are resolved, they do give the attributes
mentioned in the text. Mention this because up to this point, the text
has coincided with the schema snippets.

Same problem happens on page 100 (and no doubt others as well)

Not sure I have a solution to offer that is not uglier than the
present situation. Do suggest a note of some sort in the introduction
about the relationship of the prose to the schema and noting this sort
of apparent inconsistency.

Page: 101

6.3.4 Simple Variable Input Fields

First paragraph, first sentence reads:

"As an alternative to setting simple variables using formulas in variable setter fields,"

Note that in 6.3.2 Setting Simple Variables we say:

"You can set simple variables using variable setter elements."

Suggest that the usage should be consistent, hence:

Suggest: "As an alternative to setting simple variables using formulas
in variable setter elements," for the text in 6.3.4

Page: 104

2nd and 3rd items in list at top of page:

2nd item reads: "See the section Outline Level for information about
this attribute."

3rd item reads: "See the section Separation Character for information
about this attribute."  

Note that both are inconsistent with last sentence on page 105:

"See the following section Reference Name for more information about
this attribute."

The use of "following" alerts the reader as to where the additional
information can be found. Same function as a specific section number.

Suggest 2nd item: "See the following section Outline Level for
information about this attribute."

Suggest 3rd item: "See the following section Separation Character for
information about this attribute."

Page: 104

Bottom of the page, table with only two entries splits over a page
break. May not be worth fixing but bad typography none the less.

Page: 107

6.3.11 Text Input Fields

Last sentence before first schema snippet reads:

"See section 3.7.43 for information on using this attribute."

Non-existent section.

Suggest:

See section 6.7.4 for information on using this attribute.


Page: 113

6.5.1 Displaying Database Content

Sentence under second item on list reads:

"See the section Column Name for information about this attribute."

Same issue with "See section...." as page 104.

Suggest: "See the following section Column Name for information about
this attribute."

Page: 114 Same issue with "See section..." as page 104.

Suggest: "See the following section Condition for information about
this attribute."

Page: 115

6.5.3 Selecting a Row Number

Last sentence before schema snippet reads:

"See the following section about this attribute."

Inconsistent with prior usage.

Suggest: "See the following section Selecting the Row Number about this attribute."

with the appropriate italic style.


Page: 121

6.6.5 Reference Fields

Second paragraph, last setence reads: "Footnotes, endnotes, and
sequences are identified by a name that is usually generated
automatically when a document is exported."

"...when a document is exported?" Not unless you are using "exported"
in a completely unexpected sense.

Had forgotten the language in 2.7 Styles that reads:

"The term automatic indicates that the style is generated
automatically at export time. In other words, formatting properties
that are immediately assigned to a specific object are represented by
an automatic style within an Open Office XML document."

That and the use noted here are the only occurrences of "export time." 

Suggest for 6.6.5:

Second paragraph, last setence reads: "Footnotes, endnotes, and
sequences are identified by a name that is usually generated
automatically."


Page: 122

Reference Name

First paragraph, last sentence reads:

"Footnotes, endnotes, and sequences are assigned names by the
application used to create the Open Office XML file format when the
document is exported."

See comments on page 45 and 121.

Suggest:

"Footnotes, endnotes, and sequences are assigned names by the application used to create the Open Office XML file format automatically."


Page: 126

6.6.10 Measure Fields

Text reads: "Information to be supplied."

Suggest supplying the information.


Page: 136

Phonetic Keys

Last sentence reads:

"The original value and key attributes should they should be used for
display, but if phonetic variants are present, they should be used for
sorting the index."

Note extraneous "should they"

Suggest:

"The original value and key attributes are used for display, but if
phonetic variants are present, they should be used for sorting the
index."

Note that I took out the "should" on use of the value and key
attributes.

Page: 142

7.3.2 Table of Content Entry Templates

Second paragraph, first sentence reads: "A table of content entry
template supports seven kinds of text elements, namely:"

The following list has only 5 bullet points.

Yes, all seven are listed but counter intuiative to have two of them listed with others (Chapter + Page, and Hyperlink start and end).

Suggest listing each text element separately.


Page: 152

Main Entry Stype Name

First paragraph, second sentence,

Sub-entries -> Subentries

Merriam-Webster (http://www.m-w.com) reports that sub-entry is not in
the dictionary.


Page: 153

Combining Entries, second item in list reads:

"If the combined entry contains a sequence of pages, the pages can be
formatted:"

Combined *entry* doesn't really "contain" a sequence of pages. 

Suggest: "The pages referenced by a combined entry can be formatted
as:"


Page: 153

Combining Entries, third and forth items in list:

Should be a sub-list of the current list and indented as such.


Page: 154

Use Keys as Entries

First paragraph, second sentence,

sub-entries -> subentries

Merriam-Webster (http://www.m-w.com) reports that sub-entry is not in
the dictionary.

Page: 159

in Note under Chapter Information

Reads: "This element can only display the chapter number. To display
the chapter name, you must use the <text:index-entry-text> elements."

cf earlier comments on the use of "display" with element. Would not
necessarily pick these up under a scan for the former. 

Suggest:

"This element can only contain the chapter number. To record the
chapter name, you must use the <text:index-entry-text> elements."


Page: 160

7.12.5 Bibliography information

Second paragraph reads:

"Each <text:index-entry-bibliography> element can contain:"

For consistency, suggest:

"The attributes that you can associate with the
<text:index-entry-bibliography> element are:"


Page: 160

7.12.5 Bibliography information

Change: 

A text:style-name attribute specifying a character style for the entry 

A bibliography data field identifier

(as list)

To:

text:style-name attribute

text:bibliography-data-field attribute


Page: 160

After last entry in list, should have a subheader like Bibliography
Data Field Identifier for the text:style-name attribute

Suggest: Bibliography Entry Style

Suggest further text:

"The text:style-name attribute determines the style for display of the
entry."


Page: 160

Bibliography Data Field Identifier

First sentence now reads:

"The text:bibliography-data-field attribute determines which part of
the bibliography data field to display."

Suggest:

"The text:bibliography-data-field attribute determines which part of
the bibliography data field will be displayed."


Page: 164

8 Tables

Now reads:

"This chapter describes the table structure that is used for tables
that are embedded within text documents, but also for spreadsheets."

Suggest:

"This chapter describes the table structure that is used for tables
that are embedded within text documents and for spreadsheets."

Page: 172

Last sentence before first schema fragment appears to be split,
followed by the second half of the sentence with improper
capitalization.

Reads now:

"In addition to this,"
(schema fragment)
The calculated value of the formula is available as well."

Suggest moving the entire sentence to above the schema fragment, thus:

"In addition to this, the calculated value of the formula is available
as well."


Page: 172

Matrix:

Seems completely misplaced. Interrupts flow from attributes on cell to
the discussion of Value Type

Suggest moving it elsewhere in its entirety.


Page: 172-3

Value Type:

Note that the order of values in the list:

float
time
date
percentage
currency
boolean
string

differ from the order in which they are treated on page 173.

Explanation there combines float, percentage and currency plus uses
the order:

Numberic Value (float percentage, currency)
Date
Time
Boolean
String
Current Currency

Suggest that both lists (and treatments should be conformed)


Page: 174

8.2.1 Column Description

Second paragraph, as written, appears to be misplaced:

Currently reads:

"If two or more columns are adjoining and have the same properties,
you can describe them using a single <table:table-column> element."

Actually no, that is done with the number-columns-repeated attribute,
the next item on the page.

If this placement is to be retained, suggest:

"If two or more columns are adjoining and have the same properties,
that can be indicated using the table:number-columns-repeated
attribute of the <table:table-columns> element."

I think this leads more logically to the next section.

Page: 181

8.3.1 Referencing Table Cells

First sentence reads:

"To reference table cells so called cell addressed are used."

addressed -> addresses

Page: 191

Case Sensitive

More of a question than a comment, text reads: 

"The table:case-sensitive attribute specifies whether or not to
distinguish between upper and lower case in text when comparing cell
contents for calculations."

Seems odd to me that case sensitivity would have an impact on a
calculation, at least as I understand the term. Certainly has an
impact on comparison operations for strings. Is that what is meant
here?

Page: 199

Named Range, second paragraph, last sentence:

Now reads:

"Therefore a table name in the address is required, but the dollar
signs that indicate absolute addressed can be omitted."

Suggest:

"Therefore a table name in the address is required, but the dollar
signs that indicate an absolute address can be omitted."


Page: 200

Named Expression:

Second paragraph, final sentence.

Same as problem on page 199, suggest same fix:

"Therefore a table name in the address is required, but the dollar
signs that indicate an absolute address can be omitted."


Page: 202

On Update Keep Styles:

first paragraph, second sentence:

"non label row of the" -> "non-label row of the"

insert hyphen


Page: 202

On Update Keep Styles:

Second paragraph reads:

"Note: This was: If the attribute value is "true", the style of
the new cells in the database range is the same as the other cells in
the column. If the attribute value is "false", the style of the
new cells in the database range is the standard style of the
document."

Comment: If "was" refers to some prior draft, then paragraph should be
striken. If refers to some prior documented behavior that is now
changing, need to put in a reference to the prior document.


Page: 205

Table Name

Now reads:

"A table:table-name attribute specifies the database table that data
is imported from."

But, schema snippet reads:

<attribute name="table:database-table-name">

Suggest:

"A table:database-table-name attribute specifies the database table that data
is imported from."

Page: 205

Query Name

Now reads:

"A query name attribute specifies the query to perform on the database
whose data is being imported."

Inconsistent with prior style for attributes. 

Suggest (with proper formatting):

"A table:query-name attribute specifies the query to perform on the
database whose data is being imported."

Page: 206

Language

Now reads:

"The table:language attribute specifies the language used in
comparisons."

Seems rather vague. Doesn't this refer to the language (in the sense
of that being compared) for string comparisons?

Suggest: 

"The table:language attribute specifies the natural language in which string
comparisons will occur."


Page: 207

Country

Now reads:

"The table:country attribute specifies the country used in
comparisons."

Same problem as on 206.

Suggest:

"The table:country attribute specifies the country specific rules to
be used in string comparisons for a particular natural language."


Page: 213

8.7.3 Filter Of and 8.7.4 Filter Condition, appear to be in the wrong
    order. The sub-elements of 8.7.2 Filter And are listed as follows
    in the schema snippet:

<ref name="table-filter-condition"/>
<ref name="table-filter-or"/>

The prior practice has been to follow the order of the sub-elements in
listing them in the text. 

Suggest: reverse the order of 8.7.3 Filter Of and 8.7.4 Filter
Condition to:

8.7.3 Filter Condition (including its subparts)

8.7.4 Filter Or


Page: 213

Operator (note, part of current 8.7.4 Filter Condition)

First paragraph, first sentence reads:

"The operator attribute table:operator specifies what operator to use
in the filter condition."

A search of the schema reveals no "table:operator".

It is probably my misreading of the schema but I was also unable to
find the various operators listed up to the section Case
Sensitive. (The ones I could easily search for in the schema at any
rate, like >=, top values, etc.) Look like application specific
operators. 

Suspect this section should be the only attribute not covered, that
is:

<define name="table-filter-condition-attlist" combine="interleave">
    <attribute name="table:condition">    
        <ref name="string"/>
    </attribute>
</define>

Of which a schema snippet appears at the end of this section.


Page: 219-220

Target Range Address

Second sentence that crosses to page 220, reads:

"A differentiation between absolute and relative addresses is not
possible, that is, the address is interpreted as an absolute address
even if it contains "$" characters."

In other places, same condition expressed (see Target Range Address,
for example) reads:

"A differentiation between absolute and relative addresses is not
possible. Therefore, a table name has to exist in the address and
dollar signs are ignored."

Really should be consistent on using either "dollar signs" or "$" in
the explanation.

Suggest:

"A differentiation between absolute and relative addresses is not
possible, that is, the address is interpreted as an absolute address
even if it contains dollar signs."


Page: 220

Buttons:

Third sentence (same problem as immediately preceeding entry) reads:

"A differentiation between absolute and relative addresses is not
possible, that is, the addresses are interpreted as absolute addresses
even if they contains "$" characters."

Suggest:

"A differentiation between absolute and relative addresses is not
possible, that is, the addresses are interpreted as absolute addresses
even if they contain dollar signs."

Note: "they contains" -> "they contain"


Page: 223

Order of attribute explanations under 8.8.4 Data Pilot Field
inconsistent with listing on page 222.

List on 222 is:

Source field name
Is data layout field
Function
Orientation
Used hierarchy

Presentation is:

Source field name
Orientation
Is Data Layout Field
Fuction
Used Hierarchy

Suggest reordering to match first listing, that is, move Orientation
to after Function.

Page: 234

8.11.10 Insertion Cut Off

listing of attributes, reads in part:

ID 

In previous listings, shown as:

ID (see section 8.11.18)

Suggest for consistency sake:

ID (see section 8.11.18)


page: 235

8.11.11 Movement Cut Off

listing of ID attribute without cross reference

Suggest:

ID (see section 8.11.18)


Page: 242

First sentence reads:

"This chapter provides the specification for the core elements of
graphic applications like drawing or presentation applications, and
for graphical objects contained in non graphical applications, like
word processor or spreadsheet applications."

Suggest: non graphical -> non-graphical


Page: 242

9.1.2 Layer Sets

First paragraph, third sentence reads:

"Layers virtually group drawing objects."

virtually?

Suggest:

"Layers group drawing objects."


Page: 243

9.1.3 Layer

Name, third sentence reads:

"Layers virtually group the object."

Suggest:

"Layers group drawing objects."


Page: 244

List of elements inside <draw:page>:

Suggest adding (see section ***) to be consistent with other parts of
the specification, thus:

Shapes (see section 9.2)

Frames (see section 9.3)

Presentation notes (see section 9.1.5)

Forms (see section 11)

Animations (see section 9.6)


Page: 258

9.2.11 Control

list, third item

Control ID

Suggest: Control


Page: 267

Escape Direction

Last sentence reads:

"The value auto means that the connection line may escape in all four
directions."

The listing of attribute values, which included horizonal and
vertical, suggest six directions. (?)

Suggest: "The value auto means that the connection line may escape in
any of the six directions that are possible values for this attribute.


Page: 269

first list, first item reads:

"Position, Size (including relative sizes), Style, Layer, Z-Index, ID,
and Transformation -  see section 9.2.14."

As written, makes it sound like relative sizes are described at
9.2.14, which they are not, appear further down on this page.

Suggest:

"Position, Size (relative sizes, see below), Style, Layer, Z-Index, ID,
and Transformation - see section 9.2.14."


Page: 270

9.3.1 Text Box

third item in list reads:

Minimum Height

But, listed on next page as: Minimum Height and Width

Suggest:

Minimum Height and Width (third item in list)

Add:

Maximum Height and Width


Page: 271

Maximum Width and Height

Should have the same order as Minimum Height and Width.

Suggest: Maximum Height and Width


Page: 276

Codebase, third sentence reads:

"The codebase is represented be the [XLink] attributes xlink:href,
xlink:type, xlink:show, and xlink:actuate. See also section 9.3.2."

Shouldn't the third sentence read:

"The codebase is represented be the [XLink] attribute xlink:href." (?) 

Also, don't understand the reference:

"See also section 9.3.2."

<draw:image>?


Page: 277

9.3.5 Plugins

listing of Parameter in second list.

To be consistent, shouldn't that read:

Parameter (see section ???)


Page: 277

9.3.6 Applet and Plugin Parameters

Shouldn't that be:

9.3.6 Parameter

to follow practice element names being section heads?


Page: 278

Source reads:

"The [XLink] attributes xlink:href, xlink:type, xlink:show, and
xlink:actuate specify the source of the floating frame. See also
section 9.3.2."

Shouldn't that read:

"The [XLink] attribute xlink:href specifies the source of the floating
 frame."

"See also section 9.3.2." (?) <draw:object>


Page: 289

9.4.2 Light

Second paragraph, the last two sentences read:

"There may be several lights, but applications may only supports a
limited number per scene. A typical limitation are 8 light per scene."

Suggest:

"There may be several lights, but applications may only support a
limited number per scene. A typical limitation are 8 lights per scene."

supports -> support (1st sentence)

light -> lights (2nd sentence)


Page: 292

9.5 Presentation Shapes

Second paragraph, last sentence reads:

"Unlike presentation shapes standard drawing are not adapted if the
presentation page layout is changed."

Suggest:

"Unlike presentation shapes, standard drawing shapes are not adapted if the
presentation page layout is changed."

Note addition of "," and "shapes" to follow "standard drawing"

Begin with Chapter 10, page 308


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]