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: Re: [office] ODF-Next proposal: Phonetic properties in table cell


Hi Kohei,

Could you add this (and the sheet tab proposal and any others you have) 
into JIRA as new issues?  It will be far easier to track them that way,

And the TC should starting thinking about revising our new proposal 
standing rule.  The old one was wiki-oriented.  I think we agree, now that 
we've gained some familiarity with JIRA, that it will be easier to track 
these in JIRA going forward.

Regards,

Kohei Yoshida <kyoshida@novell.com> wrote on 10/28/2009 03:23:30 PM:
> 
> [office] ODF-Next proposal: Phonetic properties in table cell
> 
> = Summary =
> 
> Proposal owner: Kohei Yoshida
> 
> Proposal short name: Phonetic properties in table cell
> 
> = Rationale =
> 
> Use cases: 
> 
> Japanese spreadsheet users frequently need to display phonetic
> information of Chinese characters (or Kanji) associated with text inside
> cells.  For this reason, we need a way to store such information along
> with the base text.  In addition, such storage must be backward
> compatible and be designed such that applications that don't support
> phonetic information display can simply ignore the data, without need
> for special handling.
> 
> Alternatives considered: 
> 
> I had considered using the existing ruby structure (<text:ruby> and its
> child elements) used in the word processor portion of the ODF
> specification.  However, that structure doesn't support backward
> compatibility since it embeds the ruby information deep inside the base
> text, and the application must be written to specifically handle that
> structure.  In addition, it did not work well with cells with rich-text
> content due to overlapping with format spans; when the format spans and
> the ruby spans are not perfected nested, the overall structure becomes
> quite chaotic and hard to process. For these reasons, I have decided
> it's best to keep the ruby structure separate from the base text
> structure.
> 
> = Requested changes to the ODF Standard =
> 
> Text changes/additions (please state section numbers): 
> 
> Section 5.x: <text:ruby-properties> (new section)
> 
> The <text:ruby-properties> element stores a collection of ruby texts
> associated with a text paragraph.  Each ruby text item is represented by
> the <text:ruby-span> element as a child element.  The <text:ruby-span>
> elements stored within the <text:ruby-properties> element must be sorted
> by their starting positions in the base text to which they are applied.
> 
> Note that this structure should not be used in conjunction with the
> <text:ruby> structure, which embeds ruby text information in the bast
> text structure.  In case both structures are used in the same text
> paragraph, the processor may choose to ignore the <text:ruby-properties>
> structure.
> 
> Section 5.x.1: <text:ruby-span> (new section)
> 
> The <text:ruby-span> element represents a ruby text applied to an
> individual segment of the base text.  It stores the ruby text itself, as
> well as the position and the length of the base text where the ruby text
> should be applied to.
> 
> Schema changes/additions: 
> 
> <define name="paragraph-content" combine="choice">
>     <ref name="text-ruby-properties"/>
> </define>
> 
> <define name="text-ruby-properties">
>     <element name="text:ruby-properties">
>         <ref name="text-ruby-properties-attlist"/>
>         <ref name="text-ruby-properties-content"/>
>     </element>
> </define>
> 
> <define name="text-ruby-properties-attlist">
>     <empty/>
> </define>
> 
> <define name="text-ruby-properties-content">
>     <zeroOrMore>
>         <ref name="text-ruby-span"/>
>     </zeroOrMore>
> </define>
> 
> <define name="text-ruby-span">
>     <element name="text:ruby-span">
>         <ref name="text-ruby-span-attlist"/>
>         <ref name="text-ruby-span-content"/>
>     </element>
> </define>
> 
> <define name="text-ruby-span-attlist">
>     <attribute name="text:base-position">
>         <ref name="nonNegativeInteger"/>
>     </attribute>
>     <attribute name="text:base-length">
>         <ref name="nonNegativeInteger"/>
>     </attribute>
> </define>
> 
> <define name="text-ruby-span-content">
>     <text/>
> </define>
> 
> Example (unformatted text) 
> 
> <table:table-cell office:value-type="string">
>     <text:p>
>         <text:ruby-properties>
>             <text:ruby-span text:base-position="0" text:base-
> length="2">カンジ</text:ruby-span>
>             <text:ruby-span text:base-position="8" text:base-
> length="2">コンゴウ</text:ruby-span>
>         </text:ruby-properties>
>         漢字とひらがなの混合です。
>     </text:p>
> </table:table-cell>
> 
> Example (formatted text) 
> 
> <table:table-cell office:value-type="string">
>     <text:p>
>         <text:ruby-properties>
>             <text:ruby-span text:base-position="7" text:base-
> length="2">カンジ</text:ruby-span>
>             <text:ruby-span text:base-position="10" text:base-
> length="1">マ</text:ruby-span>
>             <text:ruby-span text:base-position="20" text:base-
> length="2">ブブン</text:ruby-span>
>             <text:ruby-span text:base-position="22" text:base-
> length="2">ブブン</text:ruby-span>
>         </text:ruby-properties>
>         もしひらがなと<text:span text:style-name="T1">漢字</
> text:span><text:span text:style-name="T2">が混ざっていて、しかも</
> text:span><text:span text:style-name="T3">部分部分のテキスト</
> text:span><text:span text:style-name="T2">に</text:span><text:span 
> text:style-name="T4">フォーマットがかかっていたら</text:span><text:span 
> text:style-name="T2">どうだろうか。</text:span>
>     </text:p>
> </table:table-cell>
> 
> = Impacts =
> 
> Conformance: 
> 
> This proposal will not add any mandatory features or behaviors to ODF
> documents or applications, since non-supporting applications can simply
> ignore the new element structure.
> 
> Backwards compatibility: 
> 
> The proposed change will be backward compatible since the new element
> will be treated as a foreign element to the existing processors.
> 
> Accessibility impact: 
> 
> The proposed change will introduce storage of user-viewable string.  So,
> by definition it may impact accessibility.
> 
> Original content from:
> http://wiki.oasis-open.org/office/phonetic_properties_in_table_cell
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 


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