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: [OASIS Issue Tracker] Commented: (OFFICE-1599) Editor Note: Section17.224 draw:text-areas



    [ http://tools.oasis-open.org/issues/browse/OFFICE-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12052#action_12052 ] 

Dennis Hamilton commented on OFFICE-1599:
-----------------------------------------

1. I notice that you are using regexp when what is being provided is a form of BNF.  

Is it meant that we are providing some agreed form of BNF for some of these structures, and not regexp forms.  It makes sense to me that it be BNF or somebodies EBNF.

Shouldn't we get clear about that?

2. With regard to the definition of only one or two text areas, that can certainly be done in the the BNF that is provided.   Just change the sequence to an at-most two textarea structure.

3. Also, is it really meant that the value of a draw:text-areas can be empty?  Why doesn't omission of the attribute handle that case.  (I have no objection to draw:text-areas="" but I wouldn't do that unless it is a convention for other attributes as wells.)

4. Of course, the major question is where does the text for the text area come from and do we know how to tell when it will use the second area, if present?  It would appear that the entire (possibly-empty) sequence of <text:p> and <text:list> elements that occurs in the <draw:custom-shape> element is a single text content.  So it seems like there can only be one and the question is, now, how do we know which text area applies for it.

5. The problems with this, with or without the BNF, arise in ODF 1.0/IS 26300/ODF 1.1 as well.  There are also some typos/wrong-wordings in the ODF 1.0 version.  These defects do not appear in ODF 1.2 Part 1 cd02 section 17.224.  The corrections should be captured as possible errata for ODF 1.0/IS 26300/ODF 1.1.

6. The clarification of this attribute should be identified in the CHANGES MADE section of ODF 1.2.
 
 

> Editor Note: Section 17.224 draw:text-areas

> --------------------------------------------
>
>                 Key: OFFICE-1599
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-1599
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>    Affects Versions: ODF 1.2
>            Reporter: Robert Weir 
>            Assignee: Patrick Durusau
>             Fix For: ODF 1.2
>
>
> Transcribed from ODF_Revised_Editorial_Notes_27May2009.odt
> Original author: Patrick Durusau
> Section 17.224 draw:text-areas
> Ed. Note As defined, the attribute is inconsistent and incomplete. It starts by saying we define a list of text areas. Then it says what happens if a second text area is present. Then we define how to define a text area. As a string? So, we don't have a list, or at least no mechanism for one, possibly assume up to two text areas, and don't define what values define a text area. 
> Sven Jacobi says:
> textareas::= textareasequence? 
> textareasequence ::= textarea ( ' '+ textareasequence )* 
> textarea::= position ' '+ position ' '+ position ' '+ position 
> position::= formula | modifier | number 
> formula::= '?' name 
> modifier::= '$' integer 
> number::= sign? float | sign? integer 
> float::= fractional exponent? | integer exponent 
> fractional::= integer? '.' integer | integer '.' 
> exponent::= ( 'e' | 'E' ) sign? integer 
> sign::= '+'| '-' 
> integer::= [0-9]+ 
> name ::= [^ ]+ 
> Patrick: Yes, but the prose requires:
> "If a second text area is available it is used for vertical text." 
> Noting that the first text area being for horizontal text is only by implication. 
> Nor it is clear how more than two areas (assuming the regex were extended to include what is said in the prose) are to be positioned. 
> If this is meant to simply specify the position of one or more text areas in some defined coordinate space (represented by a <draw:enhanced-geometry> element) then why don't we simply say that? 
> Sven Jacobi further replies: 
> "If text in a shape is drawn and there is no draw:text-areas element, then entire area of the shape is used. 
> If the draw:text-areas element is available, then with one exception the first text area is used. And this is the 
> exception, if the text is verical and if a second text area is available, the second text area is used. 
> I am not sure if it is sensible do to specify a limitation of 2 rectangles, I thought it is sufficient without." 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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