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=21849#action_21849 ] 

Dennis Hamilton commented on OFFICE-3356:


Oh, I misunderstood what you were objecting to.

For strings, as in a literal in a formula, I assume that the string is used as given.  I assume there is nothing in an user-created string that the user didn't put there.

For strings found as the value of spreadsheet *table* cells holding a value of type string, I assume that the string is used as given.

With regard to rules about layout information (which *might* be in the <text:p> of a <table:table-cell> element, I have no idea whether those characters would appear, but they should not involve OpenFormula in any case.

In the case of <text:p> and similar mixed-content places where the RNG <text /> pattern holds, I was making reference to what input-methods might do and/or allow users to specify, however that is specified.  It would be conveyed in the strings of the markup and a subsequent consumer would automatically be passed those constrainted forms.  

It would be interesting to know what consumers do with such codes now.

A consumer that allows subsequent editing of the mixed content might or might not preserve such Unicode-level layout control and it might or might not introduce some of its own.  But this is in material where the user is attempting to obtain a desired layout, not in trying to create an exact string.  I don't know what particular control the implementation might provide since it is not in the scope of ODF.

The "I" referred to me as an user introducing such a Unicode code point into a string.  E.g., table:formula=' "&#xFEFF;" '

Also, please, I was pointing out that this is something that MAY ALREADY BE DONE by a conforming producer and while it might be controlled by implementation settings, a Consumer doesn't have to know what they were to consume the resulting OpenDocument Document appropriately.  

This seemed preferable to completely blowing off the public comment.  I am not suggesting that OO.o or anyone else do anything different about config: items they pass around to themselves.  That config: material is all about layout behavior and not about inserting anything into the document markup and I see no reason that there has to be a conflict.

I also didn't say this was a great way to get the result.   I am saying there is a way to get the result simply using provisions that already exist in Unicode.

> 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]