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-3356) Public Comment:Please standardize "Line Start Prohibition Rule"

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

Dennis Hamilton commented on OFFICE-3356:

Andreas, please look at how I could be saying what I am saying without saying that a producer is doing something stupid.  And please stop reading this as something about OpenFormula. OK?

If I manage, as an user, to produce a <text:p> that has a Unicode ZERO WIDTH NO-BREAK SPACE in a string child, that is still a completely valid <text:p> element.  There is nothing to prevent my doing that.  Whether a consumer honors it or not, I won't predict, but I do claim that it is a valid <text:p> element and it will possibly be ignored and it may possibly be honored in conducting layout.  

Now, if I as an user employ a producer that does that for me (perhaps by virtue of configuration options or options available to me during text entry, such as a button to insert a non-breaking condition) in certain places, I get to have that happen.  If it is even the case that this will be done automatically in certain predetermined character combinations that are part of the rules of the language I am entering, I can have a product that does that.  Whether there is interoperability among products or only with the consumer that goes with the producer I am using, I can't say.  But this is a completely legitimate use of Unicode layout-effecting code points in formattable text.

There is nothing in ODF about white space or anything else that says this is not permissible in a well-formed <text:p> or anywhre else that the ODF schema paragraph-content pattern applies .  If there is such a place, please tell me where to look.

Now, with all of that provided, this has *nothing* to do with how strngs and string-values of spreadsheet cells are entered and encoded.  Where I to enter text directly into a table cell (nothing to do with OpenFormula at this point), there will be a <text:p> produced and I might well want the same functionality for entering such text, including automatic features.  I know of no OpenFormula function that can access that <text:p> markup as string data, but if there is one, it gets to deal with what is possible in such markup.  

In general, of course, when we use the data-entry function of a spreadsheet function, it just enters the text and any layout controls (like hard NL entries) that we use to control wrapping of text in how the cell is presented.  Of course, font styling seems t be available too. If arbitrary text is allowed, including entering Unicode code points that are not on my keyboard, it might get more exciting.  I'd be surprised if ZERO WIDTH NO-BREAK SPACE actually ended up in that string, even if I was able to paste one into the entry string.  And what is in that string, and what is the <text:p> markup that ODF 1.2 creates to represent the presentation of the <table:tabl-cell> "content" is still something that OpenFormula is unlikely to ever see directly.  The extraction into a simple text string, if available at all to a formula, is an implementation-dependent operation and I have no idea what kind of filtering might be done.

I am not offering the use of these Unicode layout-effecting code points as a solution to the request in the pubic comment.  I am simply pointing out that some of the provisions are already available as part of handling Unicode in a <text:p> if a consumer recognizes and honors their functions.  I don't think there is anything to tell someone not implement a conforming OpenDocument Consumer that does that, with a Producer to match in some manner.

> Public Comment: Please standardize "Line Start Prohibition Rule"
> ----------------------------------------------------------------
>                 Key: OFFICE-3356
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3356
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Needs Discussion, Public Review, Text
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Robert Weir 
>            Priority: Blocker
>             Fix For: ODF 1.2 CD 06
> Copied from office-comment list
> Original author: "MURATA Makoto (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp> 
> Original date: 16 Aug 2010 09:49:25 -0000
> Original URL: http://lists.oasis-open.org/archives/office-comment/201008/msg00004.html
> Text copied for convenience in searching JIRA (note that Unicode may be garbled):
> """
> Open Office appear to support "line-start prohibition rule", and even
> allows document authors to specify which character is prohibited.
> This rule is considered very important in Japan, China, Taiwan, and
> Korea.
> http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_1_7
> If you explicitly specify which character is prohibited, the following
> is generated by OO.o as part of setting.xml.
>       <config:config-item-map-indexed config:name="ForbiddenCharacters">
>         <config:config-item-map-entry>
>           <config:config-item config:name="Language" config:type="string">ja</config:config-item>
>           <config:config-item config:name="Country" config:type="string">JP</config:config-item>
>           <config:config-item config:name="Variant" config:type="string"/>
>           <config:config-item config:name="BeginLine" config:type="string"
>             >!%),.:;?]}¢°’”‰′″℃、。ã€...〉》」』ã€'〕ぁぃã...ぇぉっゃã‚...ょゎ゛゜ゝゞァィゥェォッャュョヮヵヶ・ーヽヾ!ï¼...),.:;?]}。」、・ァィゥェォャュョッー゙゚¢</config:config-item>
>           <config:config-item config:name="EndLine" config:type="string"
>             >$([Â¥{£¥‘“〈《「『【ã€"$([{「£¥</config:config-item>
>         </config:config-item-map-entry>
> However, their semantics is not at all described in ODF 1.0.  It is not 
> described in the current draft of ODF 1.2 either.  Please standardize
> them.  Otherwise, ODF 1.2 does not contribute to interoperability 
> of Japanese text.
> """

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]