Re: [office-comment] Some more comments from Enomoto-san

[Patrick Durusau <patrick@durusau.net>]

Dear Makoto,

Thanks for the additional comments!

I use SVG but have never really gotten fully into its depths.

I will add these to the list and hopefully we will be able to start 
generating useful answers even prior to composition of the entire errata 
list.

Hope you are having a great weekend!

Patrick

MURATA Makoto (FAMILY Given) wrote:

>Here are some more comments from Enomoto-san.   (I slightly revised them.)
>
>1) Section 9.2.6, 4th line on page 279
>
>Current description:
>Some implementations may only supports a subset of the SVG path 
>specification, for instance no mixtures of open and closed curves for one 
>shape, or no elliptical arc command.
>Proposal:
>"supports" should be "support" after the modal verb "may" as follows:
>Some implementations may only support a subset of the SVG path 
>specification, for instance no mixtures of open and closed curves for one 
>shape, or no elliptical arc command.
>
>2) Section 9.2.7, 8th line on page 280
>Current description:
>If this optional attribute are not set, the position and size attributes 
>are used to create circle.
>Proposal:
>The first "are" should be "is" as the subjective has a singular form:
>If this optional attribute is not set, the position and size attributes 
>are used to create circle.
>
>3) Section 9.2.12, 17th line on page 287
>Current description:
>The attributes draw:control attribute specifies the control within a form 
>(see section 11.5.2) that is linked to the control shape.
>Proposal:
>"attributes" should be removed from the current sentence as follows:
>The draw:control attribute specifies the control within a form (see 
>section 11.5.2) that is linked to the control shape.
>
>4) Section 9.2.18, 29th line on page 295
>Current description:
>The following defined attributes are common for all shapes that supports 
>styles and no text.
>Proposal:
>"supports" should be "support" as follows:
>The following defined attributes are common for all shapes that support 
>styles and no text.
>
>5) Section 9.2.18, 38th line on page 295
>Current description:
>The following defined attributes are common for all shapes that supports 
>styles and text.
>Proposal:
>"supports" should be "support" as follows:
>The following defined attributes are common for all shapes that support 
>styles and text. 
>
>6) Section 9.2.19, 21st line on page 296
>Current description:
>The svg:x and svg:y attributes specifies the position of the glue point.
>Proposal:
>"specifies" should be "specify" as follows:
>The svg:x and svg:y attributes specify the position of the glue point.
>
>7) Section 9.2.19, 39th line on page 296
>Current description:
>The attribute draw:align specifies the alignment behavior of the glue 
>point if the drawing object is resized and the shape edge to which the 
>glue point's position relates.
>Proposal:
>The description in "if" clause should be paraphrased. For example, please 
>advise whether the following understanding is correct or not. It it is the 
>case, please correct the description accordingly: 
>The attribute draw:align specifies the alignment behavior of the glue 
>point if the drawing object is resized and aligned to the shape edge to 
>which the glue point's position relates.
>
>8) Section 9.2.19, 12th line on page 297
>Current description:
>The value horizontal means the the connection line may escape to the left 
>or to the right, the value vertical means that the connection line may 
>escape up or down.
>Proposal:
>The first "the" in "the the" should be "that." The words "left" and
>"right" are in a different font, while "up" and down" are not.  Since
>all of them are values of the draw:escape-direction attribute, 
>the same font should be used.
>
>9) Section 9.3, 24th line on page 297
>Current description:
>A frame is a rectangular container where that contains enhanced content 
>like text boxes, images or objects.
>Proposal:
>"where" should be removed as follows:
>A frame is a rectangular container that contains enhanced content like 
>text boxes, images or objects.
>
>10) Section 9.3, 8th line on page 298
>Current description:
>Like the formatting properties of drawing shapes, frame formatting 
>properties are stored in styles belonging to the graphic family.
>Proposal:
>A different font is used for the word "graphic", but 
>it shouldn't.
>
>
>11) Section 9.3, 21st line on page 299
>Current description:
>The value scale-min equals the value scale, except that the calculated 
>width or height is a minimum height rather than an absolute one.
>Proposal:
>Different fonts are used for the word "scale" and "scale-min".  
>
>12) Section 9.3, 25th line on page 299
>Current description:
>To support application that don't support relative with and heights, 
>applications that save the attributes style:rel-width or style:rel-height 
>should also provide the real width and heights in the svg:width and 
>svg:height/fo:min-height attributes.
>
>Proposal:
>"/" should be "or".
>
>13) Section 9.3, 5th line on page 300
>Current description:
>This does not effect style and position information.
>Proposal:
>"effect" should be "affect" considering the semantics as follows:
>This does not affect style and position information. 
>
>14) Section 9.3, 5th line on page 300
>Current description:
>This is, the frame that has the draw:copy-of attribute has its own style 
>and position information and does not use the one of the referenced frame.
>Proposal:
>"This" should be "That" as follows:
>That is, the frame that has the draw:copy-of attribute has its own style 
>and position information and does not use the one of the referenced frame.
>
>15) Section 9.3.1, 12th line on page 301
>Current description:
>The fo:min-height and fo:min-width attributes specify a minimum height or 
>width for a text box.
>Proposal:
>"or" should be "and" to synchronize with two attributes connected with 
>"and" as follows:
>The fo:min-height and fo:min-width attributes specify a minimum height and 
>width for a text box.
>
>16) Section 9.3.1, 14th line on page 301
>Current description:
>If they are existing, they overwrite the height or width of a text box 
>specified by the svg:height and svg:width attributes of the surrounding 
>draw:frame element.
>Proposal:
>"or" should be "and" as follows:
>If they are existing, they overwrite the height and width of a text box 
>specified by the svg:height and svg:width attributes of the surrounding 
>draw:frame element.
>
>17) Section 9.3.3, 5th line on page 304
>Current description:
>These objects only have a binary representation, An example for this kind 
>of objects OLE objects (see [OLE]).
>Proposal:
>The first sentence should end with a period "." and the second sentence 
>should have "is" as follows:
>These objects only have a binary representation. An example for this kind 
>of objects is OLE objects (see [OLE]).
>
>18) Section 9.3.3, 6th line on page 304
>Current description:
>The <draw:object> element represents objects that have a XML 
>representation.
>Proposal:
>"a" should be "an" as follows:
>The <draw:object> element represents objects that have an XML 
>representation.
>
>19) Section 9.3.3, 37th line on page 304
>Current description:
>The object is contained within this sub page exactly as it would as it is 
>a document of its own.
>Proposal:
>The current sentence should be paraphrased in a different way. Please 
>explain what "sub page" means and what the whole sentence means.
>The whole sentence sounds to me as follows: 
>The object is contained in the document on the target page referenced by 
>the xlink:href attribute although the source page does not actually 
>contain the object. For end users, it exactly looks like that the source 
>page contains the object. 
>Is my understanding correct? 
>
>
>  
>

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!